Designing the iPhone interface in a nib or in code?

It depends on your preference.

I prefer to write it in code.

1. I get to reuse the code.
2. Using a XIB/NIB generally breaks the one definition rule (if you are doing any customization).
3. XIB/NIB maintenance is often more tedious and error prone (ODR). I really dislike maintaining button styles (example) for each button.
4. circular references are more likely.
5. Code/objects/ib instances are often less reusable/modular. Though I am the type to avoid a ui object that can do everything.
6. Deferred/ambiguous initialization order makes for a pretty scary state for clients, which they must never assume an object is ready for use or entirely initialized (unless you prefer to maintain those checks, which is a good way to waste time).
7. If performance is important, guess which is faster?
8. Resource management vs linker... seriously, I have written sub-programs and tests to verify nibs' existence in the bundle.

IB is great for prototyping and browsing object capabilities and appearances (I am not a graphic designer), though I think it is easiest to just write it in code once the prototype exists if you have any intention of maintaining or reusing it.

My recommendation: Write highly reusable and stable code libraries, and use IB primarily for prototyping and one-offs.

Responses:

Sbrocket: I'm curious as to why you assert that circular references are more likely to occur as a result of using NIBs.

Hi Sbrocket: I'll start by saying I've used Interface Builder since the Project Builder days (Xcode's predecessor).

Lack of reliable structured ownership, identity, and initialization. I don't want ivars to be IB connections because it makes many classes difficult to use beyond 'the current context', In other words, it ties the code to the resource (more often than ideally). Since you can't d