Storyboards and NIBs: A Rebuttal

Beneath the relatively placid surface, a battle is raging among iOS developers.

On one side, we have developers who use the built-in visual interface development tools for constructing their screens. On the other, we have the code purists, who insist on entirely generating their interfaces from code.

Storyboards have a number of important advantages:

• Seeing your design means thinking visually
• Storyboards let you see how apps flow together
• Storyboards are the only way to use segues, which are a marvellous way to handle the transitions from screen to screen.

Apple vigorously promotes the Interface Builder and the use of Storyboards, but there's a surprisingly large number of developers who insist on not using them. One famous example is Google, who, as of 2012, apparently forbade the use of storyboards and XIB files, as well as checking in .pbxproj files (that is, the actual project files used by Xcode to organise where files go.) The reasoning provided is that merging these files is too much of a challenge.

Google aren't the only ones insisting that storyboards aren't a good idea. There are dozens of examples of developers promoting this viewpoint, and here are the most common arguments we see.

"Programmers should code, and not do visual design. You should know how views work from the ground-up, and being able to code your interface is more extensible."

A good programmer knows more than just than their specialty. The argument that programmers should only focus on the written component of their apps implies a separation of skills that simply isn't workable in mobile apps: if you're making an application that relies on the user holding a screen in their hand, deliberately not thinking visually means that you'll be more likely to not catch small visual problems in your app's design.

There's a lot to be said for understanding views and view controllers from the ground up, for the same reasons as understanding any other topic in programming: knowing as much as possible about what's going on behind the scenes makes it easier for developers to make more advanced use of the technology. However, this isn't an argument for avoiding the Interface Builder - understanding how views work doesn't require that you manually create them in your code.

"Creating re-usable views is harder. Also, custom views are hard to see in IB, they're just white boxes."

Another common argument against using storyboards is that using custom views is harder. For example, if you've got a view controller that needs to use a custom selector view of some kind, embedding a view that you've designed in a XIB can be a pain.

However:

• Using the Interface Builder doesn't mean that you have to use the Interface Builder for everything. You're still free to embed a custom view, set its class, and then provide a loadView method for that class to manually create the view hierarchy for that class.
• Embedding view controllers using container objects is straightforward. If you need to embed a collection of views elsewhere, or if you want to break out the logic of a screen into multiple sub-units, use the Container View object to break out a collection of views into a separate view controller.

A related argument that we see is that custom views just look like empty white boxes in your view controller's designs. Technically, that's true - if you drag in a generic UIView, and set the view's class to your own, it'll still appear as a generic white box. However, this argument against storyboards ignores some important facts:

• Unless you care about the contents of your custom view, seeing a preview of your view isn't a requirement for constructing the rest of the screen. Positioning and sizing the view on the screen is the most useful feature, and that's what you get.
• A number of important, Apple-provided views also appear as empty boxes. The point isn't that you get to see the content, but rather that positioning and arranging the view in the screen is significantly more straightforward.

"Auto-Layout sucks, and doing the layout yourself is easier to understand."

Auto-Layout has received a significant amount of criticism since it was introduced, and many developers argue that the older method of struts and springs (as well as defining frame rectangles for each view) is easier to understand.

This was a fair criticism - in Xcode 4, constraints were a huge mess, and it was very difficult to understand how re-repositioning a view in the Interface Builder would affect the constraints.

However, Xcode 5 and iOS 7 has simplified this considerably. You no longer receive a soup of vertical and horizontal blue lines, and controlling the position and size of views using constraints that you design in the Interface Builder is simple and straightforward.

"Using storyboards means designing your interfaces in Xcode, which is slow and crashy."

Xcode doesn't have a great reputation for stability, it's true. However, the time lost to re-launching Xcode after a crash is miniscule compared to the amount of additional time you'll take designing, testing and debugging your layout code.

(Xcode's still the worst IDE ever built, but that makes it no different to every other IDE.)

"Dealing with lingering outlets leads to crashes."

It's a common situation: you link a view to a class using an outlet; later, you decide you don't need the outlet, so you delete it from your code. You run the app, but the view still wants to connect to the now-deleted outlet. Your code crashes. You scream with rage.

This is a reasonable criticism - Xcode should at least provide a more visible warning that the property is missing. However, it's nowhere near enough of a reason to forswear ever using it.

"Merging sucks."

This is the only valid major criticism, and is the major one that causes organisations to ban the use of storyboards and XIBs in their codebases.

However, starting with Xcode 5, the Interface Builder is getting better and better at detecting merge conflicts. When a merge results in structurally valid XML but an invalid storyboard, Xcode will attempt to repair what it can: for example, if merging two versions results in an object connecting to an outlet that was removed, Xcode will notice it, and correct it.

Part of the problem, from a human perspective, is that dealing with merging two versions of a storyboard means working with XML, which is text; normally, working with storyboards is a visual task, but when there's a problem, you have to jump down to text and interpret what the XML actually means.

The XML used by storyboards, however, is actually pretty straightforward. Each view controller is an element that contains its subviews and other components (such as gesture recognizers or segues), and references to other objects are done with short alphanumeric strings. If there's a conflict, it's generally because two developers both inserted views into the same view controller - in which case, it's about as straight to recognize and fix as it is to fix a merge conflict in code.

Parting notes

Storyboards and XIBs are one of the most powerful and flexible tools that you get as part of the iOS developer tools, and shunning them means you lose both flexibility and features. If you're avoiding storyboards for personal reasons, we strongly recommend that you give them a try. If you're avoiding storyboards in your team because of the risk of merge conflicts, get some practice in fixing merge conflicts - they're easier than you think.

If you have any comments, email us!