The Nib-lunged Saga

We’ve historically been big fans of Interface Builder for slapping stuff out there in a hurry mostly by ourselves, but these days working on a pretty big app (200+ nib files) that’s expeditiously transitioning to modernity under the tender care of a rapidly expanding team (join now!) the downsides of visual tools for maintainability, code review, and merge conflicts become … substantial. Soooo, we’re considering that as it comes up to refactor in The Great Swiftening, we drop the whole nib/storyboard concept and go code only. If that situation is on your radar as well, take a look at the roundup here from last fall:

Working Without a Nib

My goal is to make all my projects nibless. Nib and xib files have caused me no end of problems. Even files that haven’t been edited in years spontaneously stop working when Xcode is updated and its xib compiler changes. (Most of the problems manifested on previous OS versions, where it was harder to detect them and to test fixes.) And that’s to say nothing of the advantages that doing interfaces with code offers. I’m convinced that with current technology (e.g. Auto Layout, Swift), using Interface Builder is a poor time investment for non-temporary projects…

Particularly like this addenda:

I use xib’s for everything in Keyboard Maestro. And have special Lint code to detect inconsistencies. Coming to the conclusion I’m an idiot.

Heh. For a deep dive into the code only alternative, check out

IB Free: Living Without Interface Builder and Loving It

However, once my projects increased in complexity, I found myself becoming more and more frustrated: when designs evolved, I would often just have to start the layout over by clearing all constraints. I often couldn’t get complex layouts to work in IB and I did not understand UIKit well enough to implement anything that IB didn’t allow out of the box. This frustration was compounded immensely when I began to work on projects with multiple team members and source control: I couldn’t understand what other team members had done by looking at a diff of xibs or Storyboards, let alone untangle a merge conflict…

Nodding along there, are you? Yeah, us too.

In this blog post, I’m going to describe the benefits of being IB-free, and will show you how to build a project and control a view’s layout using Anchorage.

That last library, that’s what tipped us all the way. Check it out:

Anchorage: “A collection of operators and utilities that simplify iOS layout code.”

A lightweight collection of intuitive operators and utilities that simplify iOS layout code. Anchorage is built directly on top of the NSLayoutAnchor API, so fully supports UILayoutGuide. Each expression acts on one or more NSLayoutAnchors, and returns active NSLayoutConstraints.

Seriously, they’re not kidding about the “lightweight”. iOS 9 layout API is already pretty darn good, and Anchorage makes it look downright fluent. Definitely going to give that a shot at our current Swiftification and see how it works out!


A Case For Using Storyboards on iOS

Eject from Interface Builder — on the web

Easier Swift Layout Priorities

A view construction syntax

Creating Views in Code

Why The Failure, Auto Layout? and Swift Vapor source code

Stack Views And Multi-Line Labels

Stop Using Storyboard, Start Building UI 100% Programmatically

UILayoutGuide: User Interface Creation Made Responsible

Using Advanced Auto Layout Techniques to Adapt Interfaces to Screen and Content

Alex | February 3, 2017

Leave a Reply