The Ins and Outs Of AutoLayout

Interface Builder Is A Bad Guesser

Interface Builder attempts to guess which constraints you “meant” to install whenever you move anything around in IB. 60% of the time, XCode guesses wrong….enough to make it cumbersome.

An equally painful problem is attempting to arrange sub-views on top of backing views. For example, in some cases I want a label to be on top of a view but not *in* that view. Interface Builder defaults to automatically sticking your sub-view into the view below it when dragging and dropping things.

Dynamic Layouts Are A Major Pain

Simple struts and springs are vastly easier for laying out interfaces containing many views which can change in size dynamically. Autolayout structures interfere with the process of dynamic layouts in bizarre, often unpredictable ways. Recently I had to put together a table view containing many different labels which could have many lines and needed to update the height of the table cell as well as the contained labels. It was a massive nightmare to do this.

The best you can really do is remove all the height constraints of the individual views in your dynamic layout and then add horizontal width or height distance spacers and then pray that, if the sizes of these views change, the layout will be smart enough to adjust itself.

Hiding Bad Autolayout Constraint Placements

Many times I will hit an Autolayout crash which is directly caused by constraints which don’t actually show up visually in Interface Builder unless I select the parent view and manually examine every constraint until I find the bad one. These hidden ones are often automatically inserted while shifting views around.

Forcing Irritating Constraint Requirements

Massive annoyance I encountered today was that Interface Builder demanded that a “bottom” spacer be inserted below a button. This bottom spacer was ruining the entire layout (inside a scroll view) and causing havoc when attempting to properly size the scroll view. There was no way to get rid of it unfortunately. I wound up scrapping the view controller design and putting it into a custom table view instead.

Adjusting Existing Constraints Is A Huge Pain

Sometimes you might want to adjust a constraint manually. This is generally discouraged, but possible. If Autolayout were a perfect solution, it might be less common. However, in order to manually tweak a constraint, there is no way to simply extract a specific constraint associated with a view….you have to iterate through a flat array of them and then try to scan for the one that interests you. If you want to modify the constraint, in many cases you must destroy it and then replace it in order to change the value.

Useless Crash Messages

Autolayout crashes essentially consist of a large list of constraints which might be the problem ending with one of them being arbitrarily broken in order to stop the application from crashing outright. To me, this is a sign of a fundamentally broken system – it is almost as though the XCode designers / developers threw their hands up in dispair after discovering how AutoLayout was leading to non-stop, impossible to detect in advance crashes and their best solution was to just arbitrarily guess and then snap a given constraint just to make it work.

Finally

In summation: The promise of AutoLayout was a lofty one, but it’s current existing implementation leaves a lot to be desired. I seriously hope this topic is revisited during WWDC and iOS 7.