iOS Storyboarding - practical experience re: multiple developers?

Question

Storyboards seem to be an elegant way of dealing with multiple view controllers in iOS, and the transitions between them.

However, I've avoided using them up to now, out of concern over what happens when multiple developers make changes to view controllers in the same storyboard file, and the possible resulting merge conflicts.

Has anyone had much practical experience with this, in production apps of moderate complexity?

What's your assessment -- is storyboarding ready for "prime time" in this respect? Or is it better suited to single developers, or small development teams?

(And how about workarounds, such as 'sharding' into multiple storyboard files?)

Opinions?

Thank you!

Answer 1

Little bit of background:

My five person team, four developers and QA, just finished up a fairly large project (50k+ lines of code) that utilized significant amounts of Storyboarding. We have at least 10 different Storyboards with many of them going 5 or 6 levels deep in a Navigation structure.

Additionally, we rely heavily on version control through Perforce, with dozens of check-ins a day.

My Experiences:

Never once have I had to even think about handling a resolve with any of our Storyboards. They are handled extremely well with version control for two main reasons. First, if you open one up, you'll see that it's well structured XML which plays very nicely with versioning. Secondly, with storyboards you'll always want to layout your entire UI structure before any details or code is added (that's the whole point). This lends itself very well to a team coding solution, simply because each member can then take an individual ViewController and implement it, staying isolated from the rest of the teams efforts.

However, I would recommend doing some 'sharding' because you can easily get a giant rats nest of connections going on.

Finally:

If you look around online a bit, you'll find many negative responses to Storyboarding because it can get 'messy' to pass data along from one view to the next. However, if you're getting yourself into this situation, you've already violated the basic principles of MVC. You shouldn't be using your views to store and manage data. It's tempting and easy at first, but ultimately will get you into trouble as your project moves beyond the basics.

Answer 2

Merge conflicts are still a big problem that Apple has not solved yet (including in Xcode 4.6). Sometimes, just viewing storyboard content leads to it getting modified. The modifications appear to be harmless internal workings of nibs, but if 2 people view a storyboard without making modifications, save the file, and then commit, you may see conflicts that you don't understand how to merge. I filed a bug on this a while back and it is marked as a duplicate of a known problem.

See also these questions which support this:

Storyboards and SVN conflicts

http://robsprogramknowledge.blogspot.com/2012/01/uistoryboard-best-practices.html

Xcode changes unmodified storyboard and XIB files