How I Use Storyboards

Acknowledging that storyboards exist, and that any given iOS/OS X developer will have to touch them at some point, let’s look at how to minimize the pain they can cause.

Most storyboards I see on a day-to-day basis boil down to this:

Storyboard Full

Which is to say; the view controller instance in the storyboard contains its view—which means that, in order to be useful, the storyboard must contain some subset (or all) of the GUI elements for the app. Down this road is pain, anguish and merge conflict hell. The drawbacks of this method are well documented and touted in every “Interface Builder considered harmful” argument on the internet.

What I do is this:

Storyboard Empty

By deleting the view controller’s view it behaves like any other built-in view controller container: the view controller class is responsible for its view’s presentation, whether specified in .xibs, sub-storyboards, or code. This allows for an extremely crisp separation of concerns: the main storyboard encapsulates the application flow and the view controllers, well, control views. (This stripped-down storyboard is also an easily digestable 10,000 foot view for newcomers to the project.)

Without views to manage, manipulating the storyboard becomes a cakewalk: literally the only things to do are to add/remove view controllers, and draw segues between them. Because of this the opportunities for merge conflicts are drastically reduced. Additionally, there is rarely a reason for more that one person to be editing the storyboard at the same time. In the worst case the limited scope means that, even after a catastrophic merge conflict, reproducing lost content is only a few minutes work.

One caveat: in Xcode 4 it is impossible to create a segue from one of these “empty” view controllers to itself. To work around this you can create a second instance of the the view controller, but this requires duplicating all of the out-bound segues from the initial instance, which can quickly become a mess.