Since you seem to be catching some flak for your post, I'll elaborate a bit further. AutoLayout is a constraint solver, and as such it's very easy to either ov

Since you seem to be catching some flak for your post, I'll elaborate a bit further. AutoLayout is a constraint solver, and as such it's very easy to either over-specify or under-specify your constraints in a way where it no longer evaluates. On top of this, AutoLayout also has a priority for each constraint such that if/when such a conflict occurs AutoLayout has some ordering as to which constraints get abandoned first. When you run into cases where AutoLayout breaks, debugging is a chore. You have to go through your entire view hierarchy and query each view for its hasAmbiguousLayout flag, which will give you some pointers as to what views are breaking your whole layout. Interface Builder makes this somewhat worse because it doesn't give you an easily understood 1:1 match between what you do in the UI vs. the code that gets generated out of the other end. The opacity makes it hard to triage AutoLayout failures. We use AutoLayout in small parts of the app, and we've found that doing it in code has been preferable - for a system that is as easy to break as AutoLayout you really don't want to be poking buttons on the top of a black box in the hopes that whatever comes out the bottom is sane. If there was a more transparent mapping of Interface Builder -> NSLayoutConstraint this would be less of an issue. Also, yes, XIB merges are one of the Prime Evils of Hell, second only to pbxproj merges.