Redesigning IB Auto Layout: A wee rant



Yo, I’ll tell you what I want, what I really really want, So tell me what you want, what you really really want, I’ll tell you what I want, what I really really want, So tell me what you want, what you really really want, I wanna, I wanna, I wanna, I wanna, I wanna really really really wanna zigazig ha.” – Spice Girls

While I applaud IB’s efforts at Auto Layout, many areas remain that deserve improvement. Here’s an unfocused rant about some of those deficits.

While IB’s latest incarnations enable you to build nearly any constraint you need, its support for organizing, annotating, and sharing  constraint decisions with others (and “future you”) approach zero.

You cannot group related constraints together. They’re clumped into whatever view owns them or into a view’s overview in the size inspector.

When I design constraints in code, they’re grouped and commented so I can review all related items at once. Reviewing someone else’s constraints in IB is an impossibly hard task except for extremely simple layouts.

In code, it’s easy to formalize design intent (“These are the defaults and then this constraint provides a low-priority backup for when the defaults are lifted”). IB? Not so much.

In code, you can easily build constraint groups meant for different orientations and size traits. You add these to updateConstraints or updateViewConstraints, and adjust layout with animation on orientation events. IB? Nope.

You can’t import constraints from code or express IB constraints as code and it’s like 10 minutes work max to make that happen. (I’ve implemented it in both directions.)

All the interactive tools in IB focus on building “constraints” not interfaces, so they don’t really talk in the same language that designers do. While Auto Layout is incredibly powerful and versatile, the fact remains that most people perform the same tasks over and over and over again.

Auto Layout hasn’t picked up on many of these really simple redundant tasks and added them to menus and inspectors. For example, take constraining view size. Why not just throw that into the Size inspector? Why not add simple “constrain to superview” and “stretch horizontally/vertically to superview” checkboxes.

You can’t select a bunch of buttons, distribute them with equal spaces, and then center the group in the superview. I mean, yes, you can do this, but it involves creating interleaved spacer views, with dimension constraints between them, placing them onto a subview and centering that subview or adding further spacer views at the margins to float the group into the middle.

Doing this isn’t unachievable. In code you just write a function once that floats a group of views, and then re-use that function over and over, especially as you add and remove views from that group. Everything just works.

In IB, it’s ridiculous and it doesn’t really have to be. Apple-supplied solutions would of course be best but if you don’t have those, then code-supplied IB-Designable layout behavior available from menus or palettes would serve.

One Comment

  • Well Apple doesn’t *have* to be the one to implement this kind of thing. So many people have these issues, the community could try and work together to make an open source interface builder, in the end it’s just XML or similar (albeit much much easier said than done…). Some people have no ideas and plenty of time, others have no time and plenty of ideas, the community needs to get better at mixing these groups up to progress.