Storyboards. You can’t live with them. You can’t live without them. Anyone who has built an iOS app as part of a team knows there is a special circle in merge hell dedicated to this particular problem.
With source control, it is simply unrealistic to put all of the app’s UI design in a single file. Too many people on your team will touch that one file. Pretty soon, nothing will automatically merge because there’s a conflict in your storyboard.
Of course, we also want all of the supposed benefits that come with storyboards. In principle, it seems reasonable that one would want to see the entire flow of an application in a single view. It also goes without saying that it’s really nice to have a visual tool for designing UI.
For years, we have we had our cake and not been able to eat it too. Why? This seems like a problem we should be able to solve.
How today’s teams manage storyboards
The best teams I’ve been on always have some kind of storyboard policy you learn about on day one. Typically, it’s this.
1. No storyboard represents the entire flow through the app.
2. Each storyboard represents a single screen in the app, a View Controller if you will.
3. Whenever you intend to reuse a view, go ahead and make a custom UIView subclass with its own nib file for it.
4. Take a walk and enjoy the extra 5 hours of your life you got back because you’re no longer fixing merge conflicts in the same goddamn monolithic XML file.
Of course, if you do these things, you seem to miss out on the key selling point of storyboards. You have given up on the idea that a single file will magically show us all of the users' journeys through all of the screens of an app.
Maybe that’s a misguided vision in the first place. Maybe there is only marginal utility in such an idea, and the people who work with storyboards all the time (read actual developers) derive no value from it.
You could certainly make a case that there are all sorts of edge cases that a single storyboard won’t necessarily surface. Oftentimes getting logged out will take the user to some beginning screen, and this isn’t all that obvious if you look at the storyboard.
So it seems like the real tool we want is something much more sophisticated than what we’ve got.
What would a storyboard crawler look like?
First of all, I think Apple or whoever decides to take on this challenge needs to acknowledge the reality of the situation. No sane developers use a single storyboard in their projects anymore. To do so is to make it impossible to work on your app with source control.
So maybe there are a few solo developers out there doing it, but projects can’t really scale fast unless you have some kind of team.
Taking actual reality into account, how can we change it?
Maybe we could start referring to things as we truly use them. Storyboards, at least the way my team and I use them, aren’t so much a storyboard as they are a representation of a single screen. So let’s call them screens.
Screens can connect to other screens. Different controllers can manage how different screens get presented. Inherent in the idea of a screen is its relationship to its neighboring screens.
With this idea, we have freed up storyboards to mean what they should have meant in the first place. A storyboard is what you get when you traverse all of the relationships between all of the screens in an app.
A storyboard shouldn’t be a thing that you as a developer get to manipulate. It should be the computational result of the work you have done on the individual screens, a high level view that you can see whenever the need arises.
Is this sort of work being done? Not really, at least not that I can tell with my feeble Google searching abilities. Maybe it is being done in secret at Apple.
If it were, we might get to eat our cake in addition to merely possessing it, as the saying goes.
What to do for now?
For the time being, there is practically unanimous agreement that if you are going to use storyboards to visually design your View Controllers, you should break each View Controller into its own storyboard.
That way, if there are any merge conflicts in a given storyboard file, they will be constrained to a single View Controller as opposed to all of the View Controllers in your entire application.
You will still have to deal with the occasional merge conflict in a storyboard file. It will still suck, as it always has. But you’ll no longer find yourself searching through a single monolithic file to find the one or two places where you need to decide which changes to accept or reject.
It might also help if it were generally easier to deal with merge conflicts in a storyboard file, but it doesn’t look like that’s ever going to change. In a perfect world, we would work through the conflicts as if they were a series of design decisions.
You can imagine some artificially intelligent assistant tool asking:
“This branch says you want Oceanside Blue, but the other one says you want Steel Blue. Which blue?”
In spite of everything you’ve been hearing about the Singularity, we are very far from that reality.
For the time being, we just need to stop ourselves and our colleagues from entering the ninth circle of merge hell. Please do everyone a favor and give each screen its own storyboard.
If you enjoyed reading this, please reccomend and subscribe. If there’s anything iOS or Swift related that you want me to talk about, just ask!
Support Practical iOS Development
Did you like what you see? Did I save you some time?
If so, please take a moment and support me on Patreon.
As a supporting member, you will get exclusive access to content, a vote on the topics covered, and at the higher levels, a “help me get unstuck” pass where I will personally help you fix a problem with your iOS app.