Question

Having used storyboards for a while now I have found them extremely useful however, they do have some limitations or at least unnatural ways of doing things. While it seems like a single storyboard should be used for your app, when you get to even a moderately sized application this presents several problems.

1. Working within teams is made more difficult as conflicts in Storyboards can be problematic to resolve (any tips with this would also be welcome)
2. The storyboard itself can become quite cluttered and unmanageable.

So my question is what are the best practices of use?

I have considered using a hybrid approach having logical tasks being split into separate storyboards, however this results in the UX flow being split between the code and the storyboard. To me this feels like the best way to create reusable actions such as login actions etc.

Also should I still consider a place for Xibs? This article has quite a good overview of many of the issues and it proposes that for scenes that only have one screen, xibs should be used in this case. Again this feels unusual to me with Apples support for instantiating unconnected scenes from a storyboard it would suggest that xibs won’t have a place in the future but I could be wrong.

Answer 1

You are correct, breaking up the storyboards is the best way to go. Decomposition does more than just make parts of the UI more reusable. It also makes using storyboards in a team more manageable.

Lately, many of my storyboards have contained four or less scenes. It is easy enough for one person to solely build and maintain one or more of such UI modules. This practice reduces or eliminates merge conflicts.

In the case I do need something changed in a storyboard owned by someone else, I ask the owner first if he or she has any local changes. If so, I sometimes have the owner add the changes for me. Decomposition still requires some coordination, but it is substantially less than a full-app storyboard. Ever since I started this practice, I haven’t had any merge difficulties.

As for XIBs, I don’t think I wrote enough about them in my article. They are still very useful. They can be nice for single view controllers. However, this is not where they truly shine. XIBs have one advantage that storyboards may never have. The most basic unit of a XIB is a UIView, whereas the basic unit of a storyboard is a UIViewController. Since XIBs can hold collections of UIViews, they are great for visually creating custom controls. In a XIB, I can visually build a rotary dial or a GPS widget. Then I can drop these controls and widgets into storyboards or other XIBs. Such XIBs are seen more often in iPad apps since they have larger screens capable of holding many controls and widgets. It would be unnatural to build a UISwitch within in a UIViewController in a storyboard.

Now for the best news. It is possible to connect storyboards within Interface Builder and without writing any code. I was planning on releasing this technique after WWDC, since Apple may release similar functionality in iOS 6. However, since you asked, I decided to release it now. Rather than duplicate my explanations on how RBStoryboardLink works, you can find more details on my blog and on GitHub. This will make your UIStoryboard experiences much more enjoyable.