Don't Fear the Interface Builder

The question of whether to use Interface Builder is not one most experienced Cocoa developers that I've talked to struggle with. Basically, they use Interface Builder unless they have a good reason not to. And reasons not to are relatively rare.

In the days before the iPhone, Apple's Cocoa Dev Mailing List would once in a while get a question from somebody new to Objective-C and Cocoa who wanted to create their GUIs programmatically. Here's a response to one of those questions from knowledgeable Cocoa/NeXTSTEP programmer and frequent Cocoa-Dev contributor John C. Randolph way back in 2001 that pretty much nails it:

This question comes up fairly often, and the answer is yes, it can all be done in code (which, after all is what -loadNibFile: is doing), but there's no more reason to abandon IB than there is to forego compilers and write all your code with a hex editor.

Yep. I couldn't think of a better way to say it, which is why I've quoted John's eight-year old response.

With the popularity of the iPhone, we've seen an upsurge in the number of people wanting to create their interfaces programmatically again. There are a number of factors contributing to this. First and foremost is that we've got a lot of people from different backgrounds, including people who have worked with languages and tools with GUI builders that use different, more problematic approaches or who have simply never worked with building GUI applications in a compiled language at all. Another reasons is that Interface Builder wasn't initially available for the iPhone, so a lot of applications and even a fair amount of early Apple sample code was written without it, so newcomers get a false sense that Interface Builder is just optional: purely personal preference.

Prompted by a comment in a recent blog posting, I've decided to try and explain in more detail why you shouldn't avoid Interface Builder. Most of this information is recycled from my iPhone Boot Camp Workshop material.

If your gut is telling you to avoid Interface Buidler, for whatever reason, your gut is wrong. This isn't one of those cases where there's more than one right way and it's purely a matter of personal preference. Interface Builder is clearly the preferred way and with very good reason: it makes your applications faster to create and easier to maintain. But there's even more to it than that.


The name of Interface Builder is actually a little misleading. It’s much more powerful than the name implies and it’s important to understand why.

Interface Builder does not generate code. It doesn’t create a forms file of any sort. What it does, is actually instantiate and configure the same objects that you use in your application to show your user interface. If you add a button to your application in Interface Builder, you’re actually creating an instance of UIButton or NSButton. When you configure it, you’re actually setting state on that button instance. Then, when the nib file gets saved, that button gets serialized into the nib file using NSCoding, exactly the way we persisted objects the archiving section of the persistence chapter in Beginning iPhone 3 Development. Basically, the nib loader is doing exactly what the code you would write to create and configure the interface object would do, down to the actual method calls used.

Why is this better than code generation or a form file? Well, in addition to letting you leverage extraordinarily well tested code to build your user interface, it also means that you are not limited to having just user interface elements in your nibs. You can put instances of any objects that conform to NSCoding, which is the protocol that allows objects to be serialized and de-serialized. Any object at all. In the iPhone Xcode project templates, this is how your application delegate and your root view controller get created.

There is a design philosophy at work here. It's simple and important. This design philosophy goes like this:


Simple, but elegant. And valuable.

If you’re writing tons of code to implement your user interface, that’s lots of code you have to write, maintain, and debug. The nib loading code is solid. It’s been around darn near 20 years and is used in literally thousands of production applications, including most of Apple’s applications. Apple very much "eats their own dogfood" when it comes to their development tools. If you look inside the bundles of an Apple application, the chances are very high that you will find some nib files in there.

I know some of you will still want to resist Interface Builder. Don’t. Seriously. You’re wasting your time. You are being inefficient if you are creating your user interface directly in code when there’s not a compelling reason to. There are times when the programmatic route is the right choice. There are times when it makes sense to programmatically create your user interface. In reality, though, those times are very few and very far between.

Yes, there is a learning curve, especially with debugging. But stick with it. It won't be long before you recognize the signs of a disconnected outlet or other IB-related problems and in the long run, the gains will more than justify the time investment.