With iOS 5 gaining traction, most of you have already moved to iOS 5+ in your apps. This means, you would have explored UIStoryboard and might have migrated some parts of the User Interface from nib files to Storyboards.
Storyboards have a rather annoying problem when you work as a team. When you create a new application (choosing the “Use Storyboards” option), Xcode creates a project with one Storyboard for the entire app. So any UI change made my two different developers at the same time could potentially end up in a merge conflict hell. Since Storyboards are internally auto-generated XML, these merge conflicts are too complicated (and almost impossible) to fix.
Just because Xcode’s default template creates one Storyboard per project doesn’t mean you should cram all your UI into that. You can have multiple Storyboards in your project.
The fix I recommend for this is to break your application’s UI into multiple storyboard files, maintaining one file for every use case. In most cases, one developer would be working on a use case and chances of ending up with a merge conflict are lower.
An example use case based storyboards for a Twitter client would be Login.Storyboard, Tweets.Storyboard, Settings.Storyboard and Profile.Storyboard.
Login.Storyboard would show the landing view, login view and/or register view.
Tweets.Storyboard would contain the tweets list view, mentions view, search tweets view, tweet details view, a web view for displaying links, a image view for displaying embedded images and a map view for showing location.
Settings.Storyboard would contain the settings and detailed options for settings like Instapaper login UI, choosing the URL shortener and similar stuff.
Profile.Storyboard would contain the user’s profile details view, friends list view etc.,
A developer who is working on the Login use case will probably not be working on Tweets. So, instead of breaking up into multiple XIBs (going back to square 1), using multiple Storyboards will help solve the merge conflict issue while preserving the elegance of using them.
If your application is a UITabBarController based application or a sliding menu based application (like Path/Facebook), or a springboard menu driven application (LinkedIn) you can create one Storyboard file per menu option. So a Facebook like application would have a “Events.storyboard”, a “NewsFeed.storyboard”, a “Profile.storyboard” and so on.
I have been using this technique for quite a while and I would highly recommend that you use it too.
Follow me on Twitter