Designing the iPhone interface in a nib or in code?

Question

I've been pondering over this question for a while now...

On the one hand, Interface Builder offers a really easy way to design the interface and wire the elements up with objects in code.

On the other hand, in larger projects, Interface Builder becomes a hassle to maintain.

Any suggestions would be greatly appreciated.

Answer 1

I was once very strongly against using Interface Builder in my own projects. This was due to a number of factors. I started first working with the Xcode tools when the iPhone SDK was back in beta (around March 2008), and since I didn't come from a Mac Cocoa background I was somewhat unfamiliar with using it. This was not the major factor in my initial rejection of IB for iPhone development, though - Interface Builder for iPhone development during the initial iPhone SDK beta did actually suck and it was a pain to use.

However, the story is much different with today's iPhone SDK. While there are still certainly some annoying IB bugs, I've done a nearly complete 180˚ with my attitude toward using Interface Builder. More often than not it is a good idea to use Interface Builder in your projects, I've found. It is a great tool now, and you should avail yourself of it.

Now, don't get me wrong - I am still firmly in the camp that believes that you should be able to implement anything you do in Interface Builder using code alone and I think being able to do so is invaluable. Do not use Interface Builder as a crutch - you'll only hurt yourself (and your productivity or the quality of your products) in the end. While the drag-and-drop niceties of IB are great for 90% of what you'll need to do, when you have something custom to implement that can only be done in code, you'll either wish you had followed or be thankful for following this advice. I was lucky enough to hate IB long enough that I taught myself how to do everything in code alone, and then applied that knowledge back to IB.

Edit:
To address the lack of reusability (perceived or real) with NIBs versus code...you won't be implementing something that is meant to be heavily reused in Interface Builder in all likelihood. You can't really make a custom control or view in IB, so that's ruled out, and in most cases you're going to be implementing a view controller subclass that is built to address a specific purpose. You should of course always strive to make your code and associated resources as reusable as possible. This could include design considerations to ensure that you don't unnecessarily duplicate view controller subclasses that are very similar.

Answer 2

Using builders frees you of code that you would otherwise need to maintain and the less you need to maintain the better.

The layouts built by IB do require some maintenance but it is a standard tool with its own documentation and its own online support (forums, lists, etc). If someone else ever needs to jump into your code, you can virtually guarantee they have experience with IB, but not necessarily your particular style of layout building.