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

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.