Are these still valid negatives against using Storyboards in developing iOS 6 applications?

Question

Using storyboards in lieu of the traditional .xib strategy is something I'm still wrestling with as there is some hesitancy about adopting something that does so much under-the-covers without really understanding what it is doing, and what control I'm really losing.

The BNR iOS Programming Book highlights several "cons" to using Storyboards. I've listed them below, and my question is: Are these negatives still valid with iOS 6?

1. Storyboards are difficult to work with in a team
2. Storyboards screw up version control
3. Storyboards disrupt the flow of programming
4. Storyboards sacrifice flexibility and control for ease of use
5. Storyboards always create new view controller instances

I'm looking for answers from guys who are actually building, and preferably deployed real iOS applications and have struggled with the "storyboards vs .xib" thing themselves.

Thanks

Answer 1

I don't think iOS 6 fixes any of these situations. More to the point, xcode 4.5 doesn't fix them or even attempt to do so. The issues listed seem to reflect opinions or stylistic preferences, and perhaps some misinformation. These aren't the kind of thing that COULD be fixed in code.

I'm using storyboards for a substantial app and I find them to be a real productivity boon. I encourage you to try them to see if you don't agree.

A couple of comments on the issues list:

1. I'm not aware of any issues with teams and SBs, but if 2 were true (which it isn't) that would explain this concern. I think this is a misconception based on 2.
2. Not true. I use Git religiously, and commit frequently. No problemo. During commits, SBs are displayed in their source code form (XML). The diffs work perfectly and actually provide some insight into how SBs are implemented. This reduces the feeling of mysterious "under the covers" behaviors, which becomes a non-issue with familiarity.
3. Disagree. They don't disrupt the flow, they offer a different flow - which is where they get their power. Lots of programmers find value in the separation imposed by the MVC discipline. SBs introduce a separation between UI element placement and the supporting code. It's a natural split, and eliminates a ton of mindless code (which eliminates the opportunity for typos, and "de-clutters" the REAL code that remains).
4. Partly agree - they definitely improve ease of use. But I don't find any sacrifice at all. Even when using SBs you can always revert to hand coding any objects if you need to. There's no sacrifice of flexibility or control.
5. Not sure what this means, and why it might be a problem. Of course we create different VCs for different scenes - that's natural. But it's certainly possible to reuse VC classes in SBs. This item might be a misconception about how to set the class for a SB object. It's easy to forget to do this step, and it sometimes baffles beginners. But it's trivial to correct, and setting the class quickly becomes a habit.

For me the real concerns are:

1. Using SBs demands a lot of screen real estate for development. Using SBs can be frustrating on a small display.
2. Highly complex UIs with many many scenes should be split into multiple SBs. Multiple SBs are fully supported, but it's easy to fail to do it. (It's like refactoring a method that gets too big. Usually I notice that I need to refractor code AFTER something has already gotten messy.)

The convenience of SBs during layout and the elimination of so much of the boilerplate code that clutters up VC objects is a huge benefit. (Every line of code that I eliminate is a line I can't screw up, and a line that can't obscure the real code that remains.)

In short, I can't imagine going back to life without SBs. Yes, it is a change. But I haven't found any real serious downside. It's especially important to keep in mind that even when using SBs, all the non-SB coding techniques still work. Give SB's a try, and report your own experience. Good luck!

Answer 2

I generally agree with jbbenni. The only "valid" criticism I see in your points was that about "Storyboards always create a new instance." Basically, this meant that though you could wire up a button to push a view controller on the stack, you could not wire up a button to pop back up the stack without extra code. This has been resolved in Xcode 4.5 with "exit segues", which let you indicate that you want to pop back to a previous controller rather than creating a new instance.

The other limitation of storyboards many complained about was that you could not embed child view controllers in the storyboard itself. This has also been addressed in Xcode 4.5.

Storyboards are a significant step forward for iOS development. Complaints like "it makes merging hard" are unfounded; storyboards are no harder to merge than other code; you just have to take the time to actually read the diff instead of glossing over it as "not Obj-C; can't read."

I've used storyboards successfully in a team setting since their introduction. Don't let the uninformed scare you off. They're great.