Storyboards are a quick and easy way to start building a simple app. But should you use Storyboards on more complex apps? Or on a team? What are the pros and cons of using them? Do experienced iOS developers use them? Are any mainstream apps built with Storyboards?
Let’s start with the simplest questions and move on to the more difficult ones.
Are any mainstream apps built with Storyboards?
The short answer is yes, mainstream apps use Storyboards. I’m not even going to attempt to guess how many, but I can tell you that I’ve worked on two apps for clients that are currently in the App Store that are built using Storyboards. And I’ve talked with a few colleages – at least a dozen other apps use Storyboards, too.
Do experienced iOS developers use Storyboards?
Yep. Do all experienced developers use them? Nope. But that’s true about every technology, right? Some do, some don’t – the better question is:
What are the pros and cons of using Storyboards?
Let’s start with the pros
The biggest benefit of using Storyboards (especially over nibs/xibs) is that you can see how the screens in your app are related. When you’re just starting on an existing project (or coming back to an old one), Storyboards give you an easy way to follow the flow through the app and zoom out to get a high level overview of what the app does.
Another benefit to using Storyboards (over creating views programmatically) is that you get to see what your view will look like at runtime without having to run your app. You can quickly make a change in Interface Builder and immediately see what it’ll look like – without waiting for Xcode to compile and run. (Nibs/xibs get this benefit, too.)
And a third benefit is that you can create static table views in Storyboards. So if you have a Settings screen, for example, with tappable rows of static text, Storyboards allow you to quickly and easily create them – no code required.
And now the cons
If the benefits sound nice, consider the cons, too, before making a decision about whether to build your app with Storyboards.
On teams, Storyboards are tricky to use for two main reasons:
- Merge conflicts are painful: When two people edit the same Storyboard file at the same time and cause a merge conflict, it’s tricky to sort out how to merge the changes. Part of this is because of the format of the Storyboard file (it’s XML) and part of it is because Xcode rearranges elements and makes changes in the Storyboard when you open it – even if you don’t touch anything. And when you do touch something, it’s that much worse.
- Code reviews are tricky: If you conduct code reviews on your team, reviewing changes to a Storyboard file is… difficult. Again, the format is XML with lots of hard-to-understand attributes and elements, so reviewing a diff and making constructive comments is just not easy.
And those are just the cons to working on a team. Even if you’re working on your own, there are some cons to using Storyboards:
- Confusion when they become complicated: If you have a relatively large app and you keep adding new view controllers, your Storyboard will eventually become complicated. Those pretty arrows that connect one view controller to the next start overlapping each other or getting hidden under view controllers – and it’s really hard to see what’s happening in the app.
- Xcode grinds to a halt when opening a large Storyboard: Again, if you’re working on a relatively large app, Storyboards can be difficult since it takes Xcode a while to load them into the editor. I’m working on a project with about 30 view controllers in a Storyboard, and it takes multiple seconds (around 4-5) to load the Storyboard whenever I want to edit it. (And yes, my MBP is fast.)
Whenever I’ve worked on a team, we’ve agreed to create separate Storyboards for different flows to avoid the confusion and performance issues of massive Storyboards. And we’ve always been careful to communicate about which Storyboard we’re working on before we start to make changes so we can avoid having to deal with messy merge conflicts. The code review issue exists, and will continue to exist, until Apple changes the format of the XML in the Storyboard file.
So, should you use Storyboards for your next app?
Absolutely. I always use them nowadays – I like to be able to see the screens and flow through my app, and I like to be able to create static table views without a line of code. For larger projects, you need to be careful not to cram all your view controllers into one massive Storyboard, but if you do that they’re great for larger projects, too.
And another big reason to use Storyboards: Apple’s pushing them, and it’s always easier to go along with Apple and follow their recommendations.
You can learn to build your app with Storyboards in the Intro to Auto Layout workshop
If you want to use Storyboards for your next app, you can get started with the Intro to Auto Layout Workshop. You’ll get the video that teaches you the fundamentals, plus some tips & tutorials to help you continue to learn Auto Layout. Where can I send your video?