Storyboards vs. doing it in code

Question

I'm working in a company where we have several iOS developers and we use GIT to work in the same projects together. We never use Storyboards or .xib files in our development process as it's nearly impossible to merge them correctly.

With the introduction of the iOS7 I thought about the fundamental differences between Storyboards and coding all the UI "the old way", without the use of Interface Builder.

Is there anyone here who does just that? And most importantly, is there something you CAN do in Storyboards that you can't do in code in XCode 5?

Answer 1

I'm going to split your question into two: NIBs, and storyboards.

As far as NIBs are concerned, source control issues can be painful but manageable, mainly because you've typically got one NIB file per view controller. You could imagine a situation where you have two developers working on two different sections of your NIB powered app without any merging issues. Storyboards are different, since you have one single file that describes most - if not all - of the UI of your application. Clearly there is a far greater potential for conflict issues there.

NIBs can be extremely useful and time saving, if used correctly. Here's an example: the iPhoto App on iPad has a very complex UI. The vast majority of that UI is laid out programatically. However, the app also uses NIBs to load in graphical elements which are then laid out in code. This is how the brush panel works - all the brushes are created in a NIB. This means that Apple don't have to have dozens of identical image/image view alloc/init pieces of code. All the creation can happen in a NIB (this was discussed in some detail in a WWDC 2012 session on the iPhoto UI - it's well worth tracking down).

So NIBs - sometimes good, can save you a lot of time, and whilst there are merge issues they can in many cases be easily managed and handled.

Then we come to storyboards. Storyboards are interesting. On the one hand, they are extremely helpful and useful for straightforward apps and developers new to the platform. I've just converted a UINavigationController based app from NIBs to storyboards and found some significant time savings (particularly around table views, since with storyboards you can take advantage of prototype cells).

However, if you're working on a large scale project with several developers I'm not convinced storyboards are that beneficial. There are, as you say, big issues with merge conflicts, and unlike NIBs it's not easy to resolve them since that single storyboard file controls all of your app UI.

Here's what I'd suggest (and feel free to ignore me!) - if you're currently developing apps and doing your layout/UI entirely in code consider whether NIBs might save you time. They may well not - they're not for everybody - but it's well worth at least considering. You may be surprised at how many large apps actually use NIBs (iPhoto, as I mentioned, but also many built-in apps provided by Apple, as well as many popular third party apps by large teams). I probably wouldn't consider storyboards unless you were a sole developer working on an app with fairly straightforward navigation. That's not to do down storyboards in any way - I love using them - it's just they're not really suitable for collaboration.

Somebody posted this comment in reply to your question - I wanted to discuss it:

There is nothing you can do in storyboard and can't do in code. Objects, gesture recognizers, segues, even constraints - are all available for you to build programmatically

This is technically true, but in reality there are things in storyboards/NIBs that are much easier than code. A good example of this is auto layout. Whilst you can certainly manage your auto layout contraints entirely in code, the harsh reality is that the ASCII auto layout representation is much harder to work with than the visual representation you get in IB. This is especially true on XCode 5, where there are massive improvements to auto layout in IB (I can't detail it too much as it's still under NDA, but Apple publically talk a bit about the changes here).