Common Pitfalls with Autolayout and Masonry

Introduction I recently encountered a complex view hierarchy: a root controller containing two child controllers (top and bottom), each implementing a PageView-like layout where every page is a WebView, with a draggable control in between that allows resizing the two child controller views. The reason for using child controllers was to avoid mixing all the logic into the root controller. So instead of using 's or , I used , which I had been using for a while. Here I document a few pitfalls I encountered with Auto Layout. About Because the view hierarchy was so complex, I ran into issues several times where I forgot to set to . defaults to , which means layout is computed based on the default . Setting it to allows you to use the more flexible Auto Layout (or Masonry) for constraint-based layout. Debugging Autolayout When you first start using Auto Layout, encountering the following warning can be quite discouraging. Many developers give up on Auto Layout because they don't know how to deal with it. As the output suggests: . Here's how to use the symbolic breakpoint for debugging. Add a at : 1. Open the Breakpoint Navigator () 2. Click the button in the lower left corner 3. Select 4. In the field, enter Once this breakpoint is set, you can debug through LLDB — though it's not very helpful if you don't know LLDB commands. Here's a handy tip: add (for Objective-C projects) or (for Swift projects). This gives you output like: Views marked with have constraint issues. is the memory address of the problematic view. Further debugging requires LLDB commands. For example: Print the view object: Change the color: Then find the view in your code and fix its constraints. References: Debugging iOS AutoLayout Issues Autolayout Breakpoints Using Masonry Understand the Difference Between Auto Layout Update Methods - : Marks the page as needing an update but doesn't start immediately. will be called shortly after. - : Forces an immediate layout update. It is generally used alongside . If you need a new frame to take effect immediately, call this method. It's also commonly used to trigger layout animations. - : System method — override to customize layout. - : Marks constraints as needing an update but doesn't start immediately. - : Forces an immediate constraint update. - : System method for updating constraints. Basic Usage - : Add constraints. - : Update constraints; can also add new ones. - : Replace all previous constraints. Notes - Always add a view to the hierarchy before adding constraints to it. - To use animation effects, do the following: - Through testing, I found another approach: after calling , you can animate directly using . Auto Layout with UIScrollView The view I mentioned above involved multiple nested s, and using Auto Layout with them can be quite painful. For detailed techniques, refer to Masonry Auto Layout Part 9: Complex ScrollView Layout, Using Autolayout in UIScrollView, and iOSautoLayoutMasonry. The main points to keep in mind are: 1. The itself should have its constraints set like any other normal view. 2. Constraints for the inner subviews must not be set relative to , and they must be complete, otherwise they won't properly expand the . 3. Given the above two points, it ends up being roughly equivalent to calculating layout manually. You can use a helper for this approach. The rough idea is: For my project specifically, calculating everything was too painful, so I took a shortcut: since every view from the page view inward fills its parent, I could just use the default for adaptive layout. SizeClass Diagrams Generally, if your layout needs to support iPad, using SizeClass is more convenient. Constraint annotation: SizeClass annotation: