Auto Layout
I just can't quit you
I've learned to love Auto Layout, but it wasn't always so.
In the beginning I tried to use it. Really, I did. Despite my best efforts, I ran into a huge wall of failure. Then I went back to springs and struts.
The second time, I read the tutorials, watched the WWDC videos, tried to achieve Zen, and became familiar with the documentation. This time I would put in the effort and succeed. Then I went back to springs and struts.
The third time, it finally clicked. I was able to make sense of it (Xcode 5's much improved Auto Layout support helped). I'm not an expert just yet, but I'm comfortable with it and can make it do what I want.
The first key for me was understanding that Auto Layout is a linear equation solver. Your constraints are simply the rules fed in to the solver. Screen sizes, layout guides, and constants are numerical inputs. The solver attempts to find the best solution it can given the rules.
Second, don't get lost in the minutia of exactly how the constraints work. Instead, ask yourself these questions: Where should this control be and in relation to what? What size should it have?
Break your manual design process down into steps: I want this button to be in-between this label and the edge of the view; I want it to be centered horizontally and expand to fill the space. It should have the default touch target height of 44 points and be centered vertically with the label's text.
Now translate those steps into constraints:
in-between label | Horizontal Space Constraint: |
(button leading edge == label trailing edge) | |
* constant 20 pt | |
and edge of view | Horizontal Space Constraint: |
(button trailing edge == superview trailing edge) | |
* constant 20 pt | |
centered horizontally | side-effect of first two rules |
expand to fill space | side-effect of first two rules |
height of 44 points | Height Constraint: == 44 |
centered vertically | Center Y Alignment Constraint: |
label.center.Y == button.center.Y |
One thing to notice is that if we assume the label has a fixed size and position, the button will expand to fill the available space horizontally because that's the only degree of freedom left. When the solver attempts to find a solution, it will be the one where the button's width increases to fill the space, preserving the leading and trailing edge constraints.
*That's the essence of Auto Layout. Using the rules, it attempts to adjust within the degrees of freedom you leave it until it finds a solution that satisfies the constraints. *
When there is a conflict (i.e. if we gave the button a fixed width), it will use priorities to resolve it. If the button's fixed width had a lower priority, we'd get the previous behavior. If it had a higher priority, we'd get a fixed width button that was near the label or superview, depending on the relative priorities of those constraints.
If the label did not have a fixed width or position, then the label would also expand to fill the space and again it would use priorities to determine the winner. We could get fancy and use proportional constraints as well, i.e. the button's width must be at least 3x the label's width.
Learn to love Auto Layout. Yes, it is daunting when you first begin. Yes, you may well make a few aborted attempts. But once it clicks, you'll find it makes creating user interfaces that scale across screen sizes and orientations cleaner and easier.
This could be another another "Intel Transition" moment: Apple told everyone they should be moving to Xcode and those that didn't were far behind on getting Universal Binaries out there. If Apple does end up releasing additional iPhone or iPad screen sizes with varying resolutions, my guess is they will be happy to remind you that Auto Layout was the future two years ago and you've had plenty of time to get ready.
This blog represents my own personal opinion and is not endorsed by my employer.