What is the best practice when using UIStoryboards?

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

Answer 1

I found this article mentioned a lot of issues when using StoryBoard, one thing the author raised is using a huge of nib files in one StoryBoard, which I agreed he shouldn't do that, but there was other issues such as:

My root view controller has become a source view controller for lot of segues and therefore its prepareForSegue: has become a stupidly large method filled with a lot of “if (segue.identifier isEqualToString:@”…”)” statements in a row

and

It is possible to assign view controllers in a storyboard an identifier. Unfortunately this identifier property is not exposed in the UIViewController class. This makes it very hard to perform safe introspection of the view controller hierarchy at runtime. It would be really nice if identifier was exposed for view controllers as well as for segues.

and ...more other issues, I thought it does make sense, and I'm worry whether should or shouldn't use StoryBoard for now ??

Answer 2

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.