AutoLayout: Interface Builder vs code

I haven’t blogged here for 10 years but now I return … to blog mainly about iOS programming! Or so the plan is.

I’ve been an iOS developer on and off for about 5 years now and when AutoLayout first appeared I avoided it as long as I could. My first memory of trying AutoLayout with IB is getting quickly frustrated trying to add constraints that didn’t do what I wanted and the default ones doing the opposite of what I wanted. So back to code it was.

Time has passed and I’ve become not quite an expert in AutoLayout but certainly proficient in it. Every so often I read a blog post or article about the wonders of IB + AutoLayout and how it halves your time creating layouts, gives you flexibility, cooks dinner for you, does the dishes afterwards and so on. Finally I found a bit of time to kill but with no one to kill at hand, I thought I’d give the IB side of things another go.

Everyone agrees there are downsides to IB, for example with source control and merging, but do the pros outweigh the cons?

In short, no. Why? Read on dear sir and all will be revealed!

There are a number of strange quirks in the IB interface that make things unintuitive, such as:

– The first thing you notice is that all the constraints get lumped together in a haphazard order making them hard to read.

– You can click a view to reveal only the constraints applying to it but you can’t delete them here; it is necessary to do this in the massive clumped list noted prior.

– By default views don’t have meaningful labels. In my view, once they are connected the label in IB should match the property name. Instead you have to manually name everything twice.

Views named view – that’s intuitive!

– For some reason the Pin button doesn’t allow you to pin to a superview; you must use the menus for that. Why?

Another problem is conceptual: in code, you soon learn to ignore frames entirely when constructing layouts. In IB however, it tries to honour the initial frames you place your views in, and defaults the constants in your constraints to suit. This seems bizarre to me. I thought the idea of AutoLayout was to not concern yourself with frames?

But for me, the real IB killer is building constraints with visual format language. If you want to have several views in a vertical list, in code you can do so with one formatting string:

@V:"|[view1][view2][view3][view4][view5]||"

and done!

In IB you manually have to create each constraint and then edit each of them because again the Pin button doesn’t provide enough options.

For a layout of any complexity I’d bet on coding to outrace IB hands down.

I know some prefer IB because there’s less code, but come on: we are programmers. Afraid of code we should not be.

So what do you think? Is coding layouts better or is there a magic feature in IB that I’ve overlooked?