Thursday, October 1, 2009

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:

Any line of code you don't have to write, is a line of code you don't have to maintain and is a line of code that you can't introduce a bug into.
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.


sserye said...

Dear Jeff:

You so fast!!!

Thanks for this valuable post.
Regarding IB i will give him a try in my next iPhone App.

All the best!

Adrian Kosmaczewski said...

Great post Jeff!
Just a bit of shameless self-advertising :) A couple of months ago I wrote a simple command-line tool that reads XIB files and outputs Objective-C code (for the iPhone) which can be used by those (still) willing to use code for whatever reason...
It's open source and on Github:
Cheers! Thanks for the great info.

Stephen Darlington said...

Great post. I've seen a lot of bad advice about Interface Builder but this meshes with my experience having built UI's in both code and IB.

Hunter Hillegas said...

My first few iPhone apps didn't use IB mostly because until SDK 1.0, it was pretty crappy compared to the AppKit experience.

Since then, couldn't agree more.

One thing - any difference in performance between the two approaches, specifically with regard to table cells? I've heard both yes and no without any real evidence one way or another.

Jeff LaMarche said...


There's a slight overhead with loading the nib - you've got a little bit of IO that needs to happen that doesn't when you work programmatically. It's not enough to worry about that - nothing that's going to affect your performance or, in most cases, even be measurable.

Now, if you were to put a few thousand object instances in a nib, then you might detect a little sluggishness at launch, but in most realistic cases, the difference is meaningless.

Sedgwick Coleus said...

I love this article. I wish it existed before 360iDev. I met a presenter who was adamantly against using IB and despite all the arguments we threw against him, he persisted in his stance. (Also, needs more cowbell!)

spamwars said...

It was the consistency of your approach in the first edition of your iPhone book that set my head straight about IB. Back in April, I told my tale (and why I think so many are confused by IB) at my blog. I've done even more retrofitting with IB for my first app, iFeltThat, and the conversion is now complete in version 2.x.

Danny said...

"Any line of code you don't have to write is a line of code you don't have to maintain and is a line of code that you can't introduce a bug into".

I find this rather disingenuous. As you mention in your final paragraph, it's perfectly easy to introduce bugs via IB. And even if you can recognise the signs of a disconnected outlet, what about finding it? Just because you know that an EXC_BAD_ACCESS is likely to mean a null pointer dereference or over-release in your code doesn't mean you have to blindly guess at where it occurs: you have GDB (and now CSA) to help you.

As a seasoned Cocoa coder, I use IB wherever possible. But I can well understand why newbies want to create their user interfaces in code: because bugs in lines of code are much easier to debug.

Tess said...

As a newbie xcode/iphone developer coming from a .NET background I'd have to agree with Hamish.

If IB generated code I could examine I'd be happier with it, but in general my view is 'Any line of code you don't have to write is a line of code you don't understand.'

Subkey said...

Thanks for this! I too had this "gut feeling" that using Interface Builder was "too easy" and it was more advantageous to do everything programatically - good to know that I should lay this feeling aside! :]

Malcolm said...

Also, nibs are loaded and unloaded as necessary as memory levels change. Very important on a mobile device where memory is constrained. Would take some extra time to code that behavior yourself, and most programatic UI developers aren't even aware of it nevermind don't bother to handle it.

Jeff LaMarche said...


It's not disingenuous. You can make mistakes anywhere. Compilers don't prevent you from making mistakes, but it does make mistakes less frequent and easier to find by letting you work at a higher-level abstraction. I never said that Interface Builder prevents mistakes, but it does reduce the number of lines of code you have to maintain.

In Interface Builder, once you understand the way it works, are relatively easy to fix. The vast majority of IB bugs are unconnected actions or outlets.

On the other hand, typing in the code to create a full, complex UI requires literally tens of lines of code that have to be typed and maintained.


Your statement shows exactly the kind of thinking that frustrates me. You can't look at the code for initWithFrame:, yet you have no problem using it in your code. Why do you find it frustrating to get the same functionality without having to write the code?

Interface Builder is well documented. Take a little time to read up on it and I guarantee you it won't seem like black magic any longer just because you can't see the code.


I almost wrote that, however, I believe it's actually the case that a programmatically created nib will get lazily loaded and unloaded the same way one in a nib will. I wasn't sure about it either way, and didn't have time to research it, so I just left it off.

If anyone knows the answer though, please feel free to educate me. :)

Jeff LaMarche said...


I love 360iDev - I wish I had been able to attend this one, and I will definitely try and get to the next one.

However, the first 360iDev struck me as schizophrenic, almost like two conferences, and I got the sense that this one was the same. There was the group that was probably 2/3 who were primarily application developers using the iPhone SDK to make apps for the App Store, and then there was the other 1/3 who were the Jailbreak community. Of course, it's not that simple, as many of the jailbreakers are also app store devs and vice versa, but there was a very clear split between the official sdk and jailbreak sessions - not just in content, but in attitude.

The jailbreak community have different priorities and a different take. They view Apple as an antagonist rather than a partner. Oh, at times, I think all iPhone devs get frustrated with Apple, but it's different with many of the jailbreakers - they see Apple as almost evil, as a company actively working to curtail their rights and freedom.

Sometimes, I think that view of Apple as an antagonist colors their opinions about things. Many of them also learned to program for the iPhone before IB was available. They're comfortable not using it and don't see the benefit of learning now.

I have strong opinions about the experienced iPhone developers who refuse to use IB, but I'll refrain from stating them because I fear it would come across like an insult to a bunch of people whom I basically like and respect, but feel have made what I consider to be a poor choice in one small area.

Hamish said...

Jeff: I agree with you in general, but I think that Apple have woefully neglected debugging in IB, and I think that this deserves more than a passing comment in a post like this. However, the central point of your post still stands: learn to love it! Thank you for a well-written article.

P.S. Outlets and actions may comprise the vast majority of problems on the iPhone, but that's only because we don't have to deal with NSObjectController :)

Muhammad Adil said...

I have a little experience of doing some Desktop programming using Java and Netbeans, but i find IB much more easier, and very good experience vs the java desktop programming, which i believe is pain in ass! And i think desktop programming is much more easier in Mac than on Windows (Visual Studio). I don't see the reason why people should do it using programmatically, unless they have only one screen. And i really like your this conclusion and i really should say, the core reason why you should use IB, "less code => less code to maintain/debug".

But now Apple should give some attention on Xcode, i have a background of using Eclipse and Netbeans, and i really find it very hard that there are lot of things which we have to do again and again, like synthesizing, putting things in dealloc method and writing @Property stuff, there should be some hot keys for doing all that stuff

Jeff LaMarche said...


Yes, there are advantages to working with the iPhone SDK, since we don't have twenty years of legacy (aka baggage). View controllers are first class citizens in the responder chain on the iPhone, unlike in Cocoa where fifteen or twenty years went by before they started tacking on generic controller classes.

jsd said...

In my first iPhone project I did a lot of UI creation in code, simply because I could not really wrap my head around what IB was doing. Now I'm on my second major project and I'm doing just about everything in IB. It really is a timesaver, and the rare times when I have to create things in code seem really tiresome. Setting up IBOutlets used to be a pain until I found this post on Cocoa With Love. It's a real timesaver!

Chris Ryland said...

@Tess: "If IB generated code I could examine I'd be happier with it, but in general my view is 'Any line of code you don't have to write is a line of code you don't understand.'"

Yes, except that IB isn't writing any lines of code. It's generating objects, so the only errors you can have are in failing to connect them up properly.

Andiih said...

In my relative-newbie state, I'm currently in the code camp. My experience with IB has been that its buggy, and it can get lost...often. Broken XIB's with objects that can't be deleted (well not by me) but which aren't really there. More than once I've had to scrap a XIB and recreate from scratch. I felt it wasn't saving me time, and writing in code helped me understand what I was doing. No scratch that, helped me understand what the platform was doing. Now I understand it, I might go back to IB a bit more for my next project. Thanks for the post.

pj said...

Just out of curiosity: Are there some stats about the percentage of apps in the App Store that were created using IB?

wolfscliff said...

Hi Jeff

For the first month of my Xcode life, I struggled with IB. For the 6 months that followed, I learned to live without it.

I would like to give myself a second chance to learn to love the IB.

If you have already written an IB tutorial that has the thoroughness of your OpenGL ES tutorials (taken as an example), please point me to it. If someone else has written such a tutorial, please point me to it. Otherwise, let's make a deal : you write this tutorial, and I get the privilege of trying it out. And please do not make it a video tutorial, just plain text with figures, something that you can publish in an (e)book. Oh, and one more thing: please don't forget the section on how to debug that unwritten code that the IB creates for me.


jsd said...

@wolfscliff - IB doesn't write code, it creates "freeze-dried" (serialized) objects that are instantiated at runtime. Thus there are no lines of code to debug.

Edwin said...

scrub m65 kamagra attorney lawyer body scrub field jacket lovegra marijuana attorney injury lawyer

JeansPilot said...

Just a bit of shameless self-advertising :) A couple of months ago I wrote a simple command-line tool that reads XIB files and outputs Objective-C code (for the iPhone) which can be used by those (still) willing to use code for whatever reason...
Buy Jeans

h4ns said...

What youre saying is completely true. I know that everybody must say the same thing, but I just think that you put it in a way that everyone can understand. I also love the images you put in here. They fit so well with what youre trying to say. Im sure youll reach so many people with what youve got to say.

Arsenal vs Huddersfield Town live streaming
Arsenal vs Huddersfield Town live streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Notts County vs Manchester City Live Streaming
Notts County vs Manchester City Live Streaming
Bologna vs AS Roma Live Streaming
Bologna vs AS Roma Live Streaming
Juventus vs Udinese Live Streaming
Juventus vs Udinese Live Streaming
Napoli vs Sampdoria Live Streaming
Napoli vs Sampdoria Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
AS Monaco vs Marseille Live Streaming
AS Monaco vs Marseille Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Technology News | News Today | Live Streaming TV Channels