iOS Developer Tips Giveaway: iOS Auto Layout Demystified

The winner of iOS Auto Layout Demystified is…Riley Testut.

Congrats Riley! Contact me by email to claim your prize.

Next week will be giving away a copy of iOS Core Animation: Advanced Techniques, by Nick Lockwood.

Erica Sadun has kindly offered to donate a copy of iOS Auto Layout Demystified for this weeks iOS Developer Tips Giveaway.

The book is now in its second edition, with updates for iOS 7 and Xcode 5.

I purchased the first edition of iOS Auto Layout, and I can say, the style mirrors Erica’s other books: easy to follow, in-depth explanations and well thought out code examples. I’m confident this second edition builds upon the first, providing an excellent resource for mastering iOS Auto Layout.

In her own words, Erica provides some background on iOS Auto Layout Demystified:

When Auto Layout debuted, a lot of developers gave it a try — primarily through Interface Builder — and encountered stumbling block after stumbling block . Many eventually figured out how to disable the technology in their projects, returning to struts and springs layout.

Auto Layout is simultaneously one of the most frustratingly hair-pulling-out technologies ever as well as one of the coolest most powerfully enabling. That’s because the learning curve has been so high. So I wrote a book — one that explains Auto Layout so you don’t have struggle through learning how to use it.

So much of Auto Layout involves simple, repeating tasks that if you figure out how to apply the basics everything else falls into place. In Auto Layout Demystified, I ended up covering the technology from basic tasks to the esoteric, enabling you to take advantage of this new UI system without all the frustration.

iOS Auto Layout Questions?

During the week of the giveaway, Erica will stop by periodically to check in. Here’s your chance to ask those nagging Auto Layout questions.

Enter the Giveaway

Here’s how to enter the giveaway for a copy of iOS Auto Layout Demystified:

  • Read the iOS Developer Tips Giveaway Rules.
  • Post a relevant question about Auto Layout, share your experience with Auto Layout or contribute to an ongoing discussion (posting “hope I win” or something similar does not qualify).
  • The deadline to enter the giveaway will be Friday, 2/21/14 at 12:00PM EST.

The winner be selected sometime on Friday 2/21/14 via random number selection from eligible entries. The winner will be announced here.

Good luck!


  1. I’ve done both Android and iOS development. For me, Android autolayout seems simpler. You have min and max width, and a weight of who gets the extra, so two components with weights of 2 and 1 (or .66 and .33, or 700 and 350….) would have the first one be twice as big.

    What would really help me understand Autolayout is to have a project where the Storyboard contains the various examples (with maybe the first one containing just buttons to go to the various examples). This would give people a starting base they can pull into XCode and see real working examples and tweak them to see what happens.

  2. I have not worked with auto layout as of yet. Is there any difference using auto layout with or without storyboards?

    • Before Xcode got a boost this summer, Auto Layout in IB was nigh-on unusable. So if you go back to the first edition of my book, a major part of the first chapter was “Here’s how you disable Auto Layout for Storyboards.” Most of my 2012-2013 projects used code based interfaces or Autosizing IB elements integrated through code.

      After this past summer, Interface Builder Auto Layout became far better implemented which is a great thing when working visually. I do think that most developers will benefit from learning how to create interfaces using *both* paradigms.

      There are some examples, such as settings panes, where I never use IB these days. Take this screen ( for example. It’s tremendously easy to build in code using Auto Layout because it’s essentially two columns with three groups (email, the deadline stuff, and app badging).

      The items in each column share a lot of layout features, specifically maximum width, alignment, and so forth, so I just apply those in for-loops. At the same time, I can load up their values from user defaults and initialize their presentation as well as their placement.

      The same job would take a lot more effort in IB. In code it’s super simple.

      // Every pair forms a center-aligned row
      for (int i = 0; i < labels.count; i++)
      UIView *left = labels[i];
      UIView *right = actions[i];
      ALIGN_PAIR_CENTERY(left, right);

      I do use IB quite a lot as well. In fact, although I do build some elements in code, my OS X projects are almost exclusively IB-based. Once you muscle train yourself, it become really easy to select items to co-align or to stretch to their parent.

      You ask is there a difference with or without storyboards. The brain-dead answer is "No" because both systems use the same layout language and features. The more nuanced answer is "Yes" because the way you apply (and more importantly inspect) those rules is dramatically different. Both approaches are valid however and each has their strengths and weaknesses.

  3. I’ve used AutoLayout with iOS6 and there are times where my labels seem like they have all constraints but are actually missing something. Seeing how Xcode5 handles this now, is advantageous because it means that there are less mistakes before I release an app.

    I’m still discovering features out of auto-layout, but my new rule and maybe a tip for all of you out there, is in xcode5, remove constraints then add all missing constraints so that your display looks and behaves how you intend.

    • Letting IB add constraints on your behalf is a wonderful way to ensure that your layouts won’t surprise you. (It’s basically the “principle of least astonishment”.) As you gain confidence and mastery of Auto Layout, you can start adding fun and powerful layout rules to express more interesting conditions.

      Apple definitely wanted to ensure that the IB/Auto Layout experience would work for devs with the least investment of effort. Unfortunately, the first IB AL toolset release was too controlling if you remember back to that. With the latest release, IB stops trying to second guess you and will only step in when you ask it to.

      There are also some really great features for this that you might not have yet encountered. The “Update Frames”/”Update Constraints” options allow you to adjust the layout rules based on the way you’ve tweaked onscreen views since applying those constraints or revert to your existing set of rules. They’re some of my favorite IB-based features.

  4. I’ve done some Auto Layout but all in code. I’ve found code to be MUCH easier than in IB. Hopefully I can get some good tricks to help from the book.

    • If you like code-based solutions, I can more or less guarantee that you’ll find some nice tricks in the book. *fistbump*

  5. I am still using pre-iOS 6 springs & struts in my code. Works fine for me, so I really need the book to realise what exactly I am missing by not using Auto Layout.

  6. I really like auto layout and use it for all new work. I feel like it’s very powerful and I’m probably not using it to its full potential yet.

  7. Still haven’t taken the plunge to AutoLayout in any of my projects for backward compatibility but plan on going full AL in my next project. With the current state, assuming I go ios7+ only – should I go for IB only or is in code still preferred?

    • You can totally move to IB with Auto Layout. Xcode’s new IB editor makes that transition substantially less painful than last year’s was. Many people have invested a lot in their existing Autosized XIBs and Storyboards and Auto Layout allows you to integrate those into your projects with a mix-and-match hybrid approach for incremental adoption.

  8. I’ve always had trouble getting auto layouts to work correctly on iOS 6. Maybe it’s time to give it another go in iOS 7?

  9. Does the book contain sample codes from auto layout frameworks like Masonry? I avoid doing things in IB as much as possible, also because I use a lot of UIBezierPath in drawing stuff.

    • The secret to Auto Layout is recognizing that once you’ve solved anything, you can re-use that solution over and over and over.

      I use a library (it’s in the git repository — caution it is *not* namespaced for production use) so if I need to left-align two views or whatever, it’s down to a single call. I never have to worry about the details again. I prefer a simpler approach but there are currently many good libraries like Masonry as well as the solutions I include in the book.

      The key is to move away from the low-level implementation details towards creating a declarative description of your interface. No matter how you accomplish this, so long as the result can be inspected, debugged, and documented, you’re probably in a good place.

      There’s an example in the reply to Mike R. where I align pairs of views. If you have a dependable macro, the focus in the code shifts to readability. You can then go back and focus on matching design intent to the code created to produce the interface.

  10. Sounds like a book I could really use, doing layouts is what takes me the most time.

  11. AutoLayout is one of these things that sounds like a really good idea, as much as the original interface builder for NeXTSTEP sounded like a really good idea. In practice, I’ve been looking for the book that makes it easier to understand. This might be it?

  12. I still use springs and struts in my apps, I know I should switch but I’ve never been successful with IB, sounds like I should read this book!

  13. One thing autolayout helped me solved is removing my view from under the status bar and TabBar in iOS7 and keep iOS6/iOS7 design the same. Lots still to learn!

  14. I love springs and struts (code and nib). I have utilized these features since iOS 3.0. Its been surprising for me that many iOS developers I know have a tough time understanding how springs and struts work, let alone use it. But I feel once a dev understands the concept, its something one cannot live (an iOS dev life) without.

    With that said, I am still having a tough time understanding the zillion warnings thrown on some Auto Layout heavy views, especially when using views with constraints as subviews of other views with constraints. does this book cover such use cases too?

    (I hope this book will also help demystify those warnings!)

  15. Have used it sometimes turned off others, most useful when needing to go between landscape and portrait. Sometimes it just does not do what it’s suppose to and turn it off

  16. “When Auto Layout debuted, a lot of developers gave it a try — primarily through Interface Builder — and encountered stumbling block after stumbling block . Many eventually figured out how to disable the technology in their projects, returning to struts and springs layout.” <– That's me alright :-)

    Untill now I've used the excuse that our project still has to support iOS 5, but we're talking about bumping the minimum target to iOS 6, and then that excuse is gone.

    Furthermore, I've got a theory that if/when Apple releases an iPhone with a different screen size/resolution, projects using Autolayout will have a much easier job getting things to look pretty than projects with lots of UIViews with a fixed width of 320.

    All in all, Autolayout is ranking highly on the "what to look into next" list, so a book on that topic might come in handy.

  17. I tried using auto layout and got frustrated and went back to what I already knew. I know auto layout is supposed to be great but the old system still seems to do everything I need. I’d love to understand auto layout better and give it a try next time.

  18. A short time ago I had a task to create a scrollable entry form (should handle scrolling insets for keyboard) for portrait and landscape orientation. The form could be of couple of entries and should not scroll, or be longer and do scroll. Discussing this on SO gave a mixed solution of declaring autolayout in IB, and patching in code. Any suggestion for a better solution would be welcome. See details here

  19. I like auto layout over springs and struts but there are some occasional times where I run into issues in my auto layout and it does take me some time to figure out what went wrong.

  20. I’ve been struggling with storyboarding and auto-layout since the system first became public. My experience with NIBs since iPhone OS 2.0 almost completely eradicated by the insanity driven by auto-layout and it’s implications.

  21. I have worked on non-autolayout iOS projects before, and I also had projects which involved autolayout. If I may say, you cannot really master autolayout through reading documentation and references alone. Actual experience in using autolayout through projects or sample applications is needed.

  22. I know about the TN2154 on how to use Auto Layout with UIscrollView, but I’m still wondering why it is not possible to do it from within IB directly. I’d be really interested to have a UI only solution.

  23. With Xcode 5, I’ve been using Autolayout far more than ever before. However, I can still only build basic layouts with it, and even then only through Interface Builder. I’d love to learn how to better have fluid layouts and update them via code, since it’s very important with the shift to more interactive UIs. This book would help me tremendously!

  24. I’ve got a static layout that I transform via Core Animation when the device is rotated. Is there any hope I can use auto-layout and get the same nice “everything scoots to the right place” that I have now? – I have seen parts of the screen cut off when e.g., a call’s active, or some other background process is running.

  25. I haven’t use Auto Layout so far because of (perceived) high learning curve and I’m quite comfortable with manual layout. But the question is: since Auto Layout solves sets of linear equations at runtime, I assume that performance is the trade-off of using Auto Layout – is it right? Following that path of reasoning: is manual layout faster but syntactically harder than Auto Layout, or they’re similar when it comes to amount and complexity of boilerplate code?

    • The performance degradation is minimal. It may be a series of linear equations but it’s not a *hard* system of linear equations. I doubt you’d ever notice a difference. Most people don’t work with more than a few dozen views at a time.

      • If performance trade-off is negligible, it makes me want to try Auto Layout.
        Thank you, Erica.

  26. I almost got used to use Autolayout in IB for things like dynamic table view cells, depending on the content. But when I think about how to make animations using not frames but constraints.. Things get scary :)

    • The animation language with constraints is generally either “change this view’s position” or “change this view’s size”. It’s really pretty easy.

  27. I’ve begun to use auto layout although I’m sure I’m missing some of the finer points. One case I ran into was using a collection view and attempting to update constraints on contents as the user scrolls through. I have yet to get the views to organize properly after having changed the constraints on the subviews of a collection item.

  28. Another question. Is it possible to specify the height of a container view to be “Just contain all the stuff in here” instead of having to place stuff and then set the height statically? I had to do that when putting stuff into a subview so that could be in a scrollview.

    Also, are there any “gotchas” people need to look out for when the keyboard pops up? It seems like there’s hundreds of various solutions out there for that situation.

  29. Do animations and autolayout works well? I tried but for me it’s hard to achieve. Have you some suggestion? Maybe a little example can help

    • I’ve included several animation examples in the book. The secret in terms of auto layout is that the only item that can be animated is a constraint’s “constant”. So you mostly end up animating a view’s size or position.

  30. Just started learning about auto layout. I’ve been doing a lot of my learning from ebooks. What level does the book fall in? Intermediate or Advance?

    • I’d say “Intermediate”. You need to know the basics of iOS development.

  31. I’m just starting to take classes learning about Xcode, IB, and AL. I pitched an idea for an app to my professor and he shot it down saying that it would require too much work because I’ll have to create different XIB files for each language that reads different (i.e. right to left such as Arabic and Hebrew). I’ve researched some and found that AL helps with internationalization. Is this true? I told my prof. that and was told that AL was a waste of time and energy to learn. Can AL adjust for languages read in different directions?

    • Auto Layout is built to support internationalization. Instead of “left and right”, you describe items in terms of their “leading and trailing” edges, so you can go left-to-right or right-to-left depending on the language.

      What’s more, AL also enables you to decide the relative priorities of which text to clip when language length changes. German, for example, has far longer words as a rule than Arabic. Tweaking the layout priorities for buttons, labels, text fields, and so forth lets you control which items must always be shown fully and which text can squeeze down.

  32. I’ve always had problems with Auto Layout and Scroll Views. On the other hand, I really like the way Auto Layout makes it easier to adjust the appearance for all display sizes and orientations.

  33. Sadly I’m still using springs & struts, and from time to time I try with autolayout.

    I think it takes time to be fully usable, and I’m easing it using a library, , it has nicer syntax for sure, and it helps a lot! I hope this book could help me get full speed :-)

  34. What is the best way to evenly space items vertically using Autolayout, so they look balance on both 4 and 3.5-inch screens?

    I’ve not found an elegant way to do this, yet it seems to be the sort of thing Autolayout (with all the complexity it has brought us) should be good at.

    • It’s a bit of an ugly solution, I’m afraid. You use invisible spacer views and constrain them all to have the same size.

  35. I’d like to start switching to Autolayout in small steps as I refactor particular views in my legacy codebase. Does anyone have any tips/gotchas/otherwise for the best way to go about such an incremental changeover on an iOS app?

  36. While I’ve had my fair share of growing pains, I’ve enjoyed AL.

    One of the biggest hurdles I’ve run into is managing scroll views (+ content) in portrait & landscape. Has anyone put together a good resource for this?

    Beyond that, understand the visual language has been a challenge. Hoping that the book gives a lot of good examples here!

  37. Is there a good way to use IA with either an IBOutletCollection (using Storyboards), of simply an array of UIViews created in code? The IA requirement would then to be layout the views equidistantly across the parent view.

  38. Wonder how AutoLayout magic works along with view animations.

  39. I try to use AL with storyboard couple of times but I never get the result I want.. guess I’m not covering all the possible inconsistencies

  40. Every time I’ve attempted AL, I came away feeling that I’m missing something. I’d love to read this book.

Comments are closed.