Using Auto Layout with Interface Builder

 ·  iOS, Development, Tutorials  ·  Tagged Interface Builder, Xcode, Auto Layout and Developer Workflows

I'll admit it, I was an Interface Builder hater. In the past everything I did was in code: Auto Layout, custom views, custom cells, everything. The frustrations of Xcode 4's implicit constraint generation made using Auto Layout difficult. Going to code was far simpler.

Of course there are downsides to code. More code means more maintenance, more opportunity for errors and the seemingly endless Build, Run, Crash, Fix Constraints development cycle.

Apple made huge improvements to Interface Builder in Xcode 5 that make using it with Auto Layout a lot better. First and formost, it no longer implicitly adds constraints which results in more predictable layouts. More importantly, it warns you if your layout is ambiguous or broken, which basically eliminates the Build, Run, Crash, Fix cycle.

Using Interface Builder has been an adjustment, and there are definitely times that I want to delete a non-cooperative XIB and just do it in code. However I’m finding myself much more productive when it comes to Auto Layout. Here are a few techniques that have really helped me integrate Interface Builder into my workflow.

Renaming Constraints

As you create constraints in Interface Builder, they appear in the View Hierarchy list. Unfortunately, Xcode 5 doesn’t allow you to reorder the items in this view, and it maddeningly limits how wide the list can be expanded. This makes it difficult to distinguish between constraints at a glance.

Renaming Constraints

Fortunately, you can rename your constraints. These names are only used for the View Hierarchy list, so they have no effect on the way your app works. It doesn’t solve all my problems with the View Hierarchy list, but it helps.

Intrinsic Sizes & Placeholders

In most cases, the intrinsic content size of a view is not known until runtime. Leaving the view without any constraints will cause Interface Builder to complain about an ambiguous or broken layout. To squelch these warning messages, use placeholder constraints and mark them to be removed at runtime.

Configuring Placeholder Constraints

  1. Select a view
  2. Open the Size inspector
  3. Change the Intrinsic Size drop-down menu from Default (System Defined) to Placeholder.
  4. Define the Width and/or Height.


Defining a Constraint to be Removed at Runtime

  1. Select a view
  2. Open the Size inspector
  3. Select the down-arrow next to the gear icon and click on Select & Edit.
  4. At the bottom of the constraint configuration window check the box next to Placeholder for Remove at build time.


In this situation you will obviously need to to build and run to validate your constraints.

Control-dragging in the View Hierarchy

Within the View Hierarchy it is possible to set constraints by Control-dragging from one object to another. I find this to be the easiest way to add constraints. To do this, hold down the Control key and drag from one view to another the way you would when connecting an IBOutlet. Upon release you are presented with a popup menu of options for setting constraints.



IBOutlets are basically just object properties that bridge your XIBs to your code. Like other properties, they’re not just limited to UI elements. You can have IBOutlets to anything, including Auto Layout constraints that you’ve created in Interface Builder. This is great for situations where your layout changes at runtime by modifying a constraint’s constant. Connect an outlet to the constraint in Interface Builder, and modify its constant in code at runtime.


Apple has made a lot of great strides with Interface Builder, with Auto Layout seeing some of the best improvements as far as I’m concerned. The tips and techniques above made adopting Interface Builder a lot easier for me, and I hope they help you too. If you have any questions or cool Interface Builder tips of your own, share them with me on Twitter @flightblog.