On the last iOS app I worked on, we used Storyboards in the app. However, I walked away from the experience with a bad taste in my mouth, and have decided to not use Storyboards in my next project. Here’s a list of reasons as to why.


Storyboards can’t be diffed meaningfully. Since they serialize to unreadable XML, it’s more or less impossible to look at a diff of a storyboard and figure out what really changed.


Because storyboards can’t be read by human beings, merging or rebasing storyboards across branches is an absolute nightmare. It often results in re-creating the work on one of the branches manually.

Opening a file modifies it

I’m not sure why this happens, and it doesn’t happen all the time, but I’ve often found that merely opening a Storyboard file modifies it. This is super irritating, because I’m no longer sure about whether or not I made a change to it that matters.

Code review

A broken storyboard can completely break the app (like say, if you’ve got an ambiguous constraint), so it must be code reviewed like all other code. However, because of the above reasons, it is really hard to do a proper code review.


One of the goals of using Storyboards is to be able to visualize what the app will look like without actually running it. In reality, though, storyboards don’t really come close. More often than not, they look like this:

What I’m doing instead

I’m going to be using AutoLayout in code. While NSLayoutConstraint is incredibly verbose, there’re a few open source libraries that appear to make it significantly less painful: SnapKit, EasyPeasy, SwiftAutoLayout, etc. I’m not a big fan of the ASCII art version of NSLayoutConstraint. As awesome as it is, it’s stringly typed, and I try and avoid stringly typed code whenever possible.

Who knows, this may be a case of “the grass is greener on the other side”. For all I know, I may come running back to storyboards in a few months 😀.

If you’ve found a way to work around the above problems, I’d love to hear about them. Hit me up on twitter: @gopalkri.