Since the release of iOS 5 and Xcode 4.2 in 2011, developers have had a choice when making an iOS project: should I build my interface using a storyboard or just entirely in code? Programmers, of course, when faced with a choice, tend to form very strong opinions about what’s the right choice, and this one is no different. Since then, this has been one of iOS’s holy wars, akin to “tabs or spaces?” or “Objective-C or Swift?”. If you’re just reading through comments on social media or blog posts, you’ll find that a common sentiment is that pure code is the right way to go, but I beg to differ. Storyboards definitely have their use cases and are often downright nice to work with.
Why I like storyboards
Personally, I’m a huge fan of storyboards. I think that building visuals should be an inherently visual experience, and using Interface Builder allows that to be so. It saves me from having to struggle and think about what each of my changes will look like while I design a view using a text file full of code. I don’t have to guess what each line will look like, and then compile everything and wait for it to install and launch on my device because I can see it right in front of me while I work and interact with it. Do I wanna make something red? Cool, I can pick out the specific color of red I want and save it for later. Do I want something to stay centered? It’s just a couple clicks away, instead of having to learn some domain-specific language of which I have no current understanding (there are, of course, frameworks out there like SnapKit or PureLayout to help with your AutoLayout code, however).
Done well, using a storyboard can make it easier to understand and work with your UI code. Without a storyboard, you’d be responsible for setting up and positioning every single view yourself in your code, even if all it would do is sit in one place and never need to change or be manipulated. That’s potentially 100+ lines of code used just to set something up and never touch it again. With Interface Builder, however, you don’t need to worry about that code. You can drag that view into place, add the AutoLayout constraints it needs, and then never worry about it again. Interface Builder takes often hundreds of lines of UI code and handles it for you automatically, which leads to clearer code, fewer bugs, and less work for you.
We’ve come a long way
One of the most common gripes I see with storyboards is that they make reuse and common organization tactics difficult. Don’t get me wrong, I’ve spent far too much time debugging crashes caused by a broken IBOutlet, but this is one area where Interface Builder has improved greatly in recent years. In the olden days, when you created a view controller in a storyboard, that was the only place it could exist. In many cases, not even copy/paste can help you, and that wouldn’t even be true reuse. Sure, you could create a view in a .xib file (a storyboard is basically just a symphony of .xibs, after all) and reference that wherever you want, but that is by no means perfect.
This is one area that Apple has really worked on improving in recent years, though. iOS 9 and Xcode 7 introduced the concept of a “storyboard reference”. You can think of these almost as variables for Interface Builder view controllers. They allow you to create a view controller (or entire series of them) in a separate storyboard file and reference it in any other storyboard. This solves a multitude of issues that developers had with storyboards before. Instead of having a huge tree of every view controller in your app in a single file, now you can split them up into more digestible bites. Not only can you reuse Interface Builder flows now, but with a way to significantly reduce their complexity, you can more easily understand and reason about them now, too.
You’ll also hear a lot of storyboard haters talk about how difficult it is to even use a common color scheme in Interface Builder, nonetheless share it with your code. However, this is also an area that has been recently improved. Since iOS 11/Xcode 9, you can now save a color and give it a name in your asset bundle, just like you would an image. These named colors automatically appear in any color picker in your Interface Builder files, and you can use them in your code by calling UIColor?(named:), just like you would a UIImage. While this also isn’t a perfect way to keep a color scheme, it’s at least a lot better than the old way of just manually setting each color everywhere you needed to.
It’s not a choice
Of course, storyboards still have issues I can’t rebut. For example, they’re actually an undocumented XML format, which makes it really hard to have multiple developers work on the same storyboard and then try to merge their changes. Source control merge conflicts are practically inevitable (though far more avoidable with storyboard references), and when you run into one, resolving it is pretty much semi-educated guesswork that almost never turns out well. On large teams, this can turn into a real problem. Storyboards also can’t represent every possible thing you might want to draw to the screen, and you might have to use code to implement some interfaces. In my opinion, they could also improve more in the future by adding mechanisms to allow developers to reuse layout logic instead of just specific values.
The good news, however, is that the idea that you can either use a storyboard or code is a false dichotomy. Both code-based interfaces and storyboards have their own use cases, and they can live together side-by-side. If you need to just show a few views and controls to the user, that’s a case where a storyboard will serve your needs just fine. If you need to draw some complicated interactive graphics, that’ll be way easier with code. Interface Builder is just a visual way of using a subset of the same APIs and technologies that you can use with raw code, so while anything you can do in a storyboard can also be done in code, many great apps use a combination of both, employing each strategy where they make sense. The next time you’re building a UI on iOS, don’t think “should I use a storyboard or should I use the code?”, think “what’s the easiest way to implement the best interface?”, and I’m sure you’ll love the results.
Michael Hulet is an independent software developer from Nashville who specializes in iOS, watchOS, tvOS and the front and back ends of the web, but really just enjoys software in general. He’s also into data security, hockey (especially the Nashville Predators), and anywhere that has a good plate of barbecue. He’s looking for work right now, especially if your company is in Sweden. You can find him online at his website, on Twitter and at GitHub.