And yes, autolayout is a shitshow, hence the countless utilities and frameworks built on top of it to make it more palatable.
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 ¯\_(ツ)_/¯
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.
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).
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.