3 ms·

To be honest, storyboards are either a rookie tool, or usable for small to medium apps. Most large apps don't use them at all. And yes, autolayout is a shitsh

To be honest, storyboards are either a rookie tool, or usable for small to medium apps. Most large apps don't use them at all. And yes, autolayout is a shitshow, hence the countless utilities and frameworks built on top of it to make it more palatable.

bunnycorn 8y ago
> Most large apps don't use them at all. Source for that? The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React) > hence the countless utilities and frameworks built on top of it to make it more palatable So, having layers of abstraction, now means it sucks? No, people make layers of abstraction because the underlying layer is useful, powerful, configurable. People do encapsulate AutoLayout because it works, and is good, or else, they would be doing their own code programatically.
- Aqua_Geek 8y ago
  > The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React) Anecdote: I’ve worked on a few large iOS teams at well-known companies. At all of them, we have moved toward building UI in code and specifically banning the use of XIBs and Storyboards (we still use all of Apple’s frameworks — e.g. UIKit). Part of the reason is merge conflicts — in much the same way that merging Xcode project files requires every engineer to understand and be able to parse the syntax when looking at a diff, merging changes in XIBs and Storyboards is fraught with danger (at best).
  - bunnycorn 8y ago
    We don't have that problem, we have CI with UI tests.
    - mpweiher 8y ago
      Wow, your CI automagically fixes merge conflicts?
  - jchb 8y ago
    We use storyboards and xibs extensively for a pretty large app (50+ unique view controllers, hundreds of use-cases). Although I grant that our team size is pretty small (< 10). But even with a much larger organisation, I would expect different teams to be assigned to different features, so there shouldn't be more UI-related merge conflicts. Interface builder is very useful for previewing constraints with different size classes and device models, and also for previewing localisations (app localized to 20+ languages). With some exceptions, we only have a single view controller in a storyboard file. This, and managing UI tasks so that just one or two developers work in the same part of the UI makes us have very few xib and storyboard merge conflicts.
aaaaaaaaaab 8y ago
A testiment for AutoLayout’s power is that the web has 2 separate layout APIs (grid and flexbox) both which are just limited special cases of AutoLayout’s functionality. However, if you don’t take your time to understand linear constraint systems, then you’re entering a world of pain. To work effectively (and correctly) with SQL, you have to learn to think in terms of relations. To work effectively (and correctly) with AutoLayout, you have to learn to think in terms of linear constraint systems. Sorry webdevs ¯\_(ツ)_/¯

bunnycorn 8y ago

> Most large apps don't use them at all. Source for that? The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React) > hence the countless utilities and frameworks built on top of it to make it more palatable So, having layers of abstraction, now means it sucks? No, people make layers of abstraction because the underlying layer is useful, powerful, configurable. People do encapsulate AutoLayout because it works, and is good, or else, they would be doing their own code programatically.

Aqua_Geek 8y ago
> The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React) Anecdote: I’ve worked on a few large iOS teams at well-known companies. At all of them, we have moved toward building UI in code and specifically banning the use of XIBs and Storyboards (we still use all of Apple’s frameworks — e.g. UIKit). Part of the reason is merge conflicts — in much the same way that merging Xcode project files requires every engineer to understand and be able to parse the syntax when looking at a diff, merging changes in XIBs and Storyboards is fraught with danger (at best).
- bunnycorn 8y ago
  We don't have that problem, we have CI with UI tests.
  - mpweiher 8y ago
    Wow, your CI automagically fixes merge conflicts?
- jchb 8y ago
  We use storyboards and xibs extensively for a pretty large app (50+ unique view controllers, hundreds of use-cases). Although I grant that our team size is pretty small (< 10). But even with a much larger organisation, I would expect different teams to be assigned to different features, so there shouldn't be more UI-related merge conflicts. Interface builder is very useful for previewing constraints with different size classes and device models, and also for previewing localisations (app localized to 20+ languages). With some exceptions, we only have a single view controller in a storyboard file. This, and managing UI tasks so that just one or two developers work in the same part of the UI makes us have very few xib and storyboard merge conflicts.

aaaaaaaaaab 8y ago

A testiment for AutoLayout’s power is that the web has 2 separate layout APIs (grid and flexbox) both which are just limited special cases of AutoLayout’s functionality. However, if you don’t take your time to understand linear constraint systems, then you’re entering a world of pain. To work effectively (and correctly) with SQL, you have to learn to think in terms of relations. To work effectively (and correctly) with AutoLayout, you have to learn to think in terms of linear constraint systems. Sorry webdevs ¯\_(ツ)_/¯