How do you keep Storyboards from causing merge problems later?

by Lou Franco

There’s this myth in the iOS community that “professional” iOS developers never use Interface Builder. It’s meant to imply that coding your interfaces is always better, and if you don’t do it, you are somehow less of a programmer. The myth perpetuates the idea that IB is a crutch, a toy, something that only newbies use.

I call BS.

As with a lot of things, the truth is complicated. Designing in Interface Builder has some real drawbacks, but it has a huge benefit in that you can visually see your UI at a glance.

It’s clear that Apple is investing a lot in IB, so this is only getting better. I think it’s the best way to see how a UI is going to react to different device sizes. My main project has a long build cycle, so this quick feedback loop is essential in some cases.

What a “professional” really does is learn all of the different tools and then reach for the one that makes the most sense given the tradeoffs. So, learn the advanced features of IB, but also learn how to code a UI. And, most importantly, learn how to combine those techniques.

But, that’s not what I came here to say.

One big drawback of IB is that the resulting files, even though they are text (XML), are not designed to diff and merge very easily. IB does you no favors in trying to keep them stable—sometimes a small edit ends up reordering sections. If this happens to be the first edit with a new version of Xcode, there might be whole bunch of IB modernizations mixed in.

This means that when you go to merge these files later, you can have a big mess.

I’ve seen three things that work to make this easier. Two are technical and easy to adopt, but the last one may require a cultural change on your team.

1. Adopt Storyboard references (and break out views into XIB files).

This is a no-brainer. If you use more (and smaller) files, it’s just a lot less likely that multiple people need to change them at the same time. Even before there were storyboard references, you could always break apart storyboards and just bring up the next VC in code instead of using a segue.

Any complex view should have it’s own class (and XIB) anyway to make it easier to reuse.

2. Use Storyboards for layout and code the “style”.

If you come from web development, this is the biggest no-duh piece of advice you have probably ever read, but I can tell you that it’s rare in iOS projects to extract and layer style out of structure.

The main benefit of this is that it makes your storyboards have a lot less information, but it retains the visual glance and device size checking benefits. It’s up to you how much you take out, but you should minimally leave in all of the constraints.

The side-benefit to doing this is that fonts, colors, etc are usually best stored in constants somewhere, so you want them in code anyway. And there are a bunch of things that are arcane in IB but simple in code.

Finally, if you ever think you are going to internationalize your app, get your translatable strings into code, as the tooling is much better than IB right now.

3. Keep branch life extremely short.

You hopefully make little branches for each feature or bug, but what I am saying here is that from the time of branch creation to PR should be on the order of (at most) days. To do this, break down bigger projects into smaller changes and use feature flags if you need to keep them out of releases.

Restart the clock on any branch by rebasing whenever other PRs are merged.

As with the other suggestions, you get side-benefits. In this case, tiny PRs enable code reviews to be much easier to do. This means that the PR gets merged faster and others can rebase to it—it’s a virtuous cycle.

If this last suggestion has you rolling your eyes, believe me, I understand. I probably never would have understood how much I would love working this way until I joined a team that had this culture firmly established. We have only doubled-down on this while growing.

The good news is that you can adopt this for just yourself and very rarely need to resolve conflicts for your own PRs. Your team may follow your lead, and at some point it will be right to have a discussion about it.

“Professionals” rarely have one true way

There are definitely some things in iOS development that are dangerous that I have learned to avoid (I’m looking at you implicit unwrap). But IB isn’t one of them.

Interface Builder may be looked down upon by some, but it’s better to learn to overcome the drawbacks rather than miss out on what could be a big win. If it drives some discipline on file size and branch age, then great!

And even if you choose to implement your entire UI in code, do it because you valued the benefits of that, not some “pro” rule.