I remember when my team leader asked me if I think it’s possible to compile our C libraries for a new platform called “iPhone OS”. I said yes and my programming career took a 180 degree turn that day.
A new platform was born for learning, hacking and building cool stuff that could run on my super sleek new phone. When the iPhone SDK came out, I sat to write the first iPhone app of my company. I love working on new platforms and learning all I can about it.
I read about every single article about iPhone development and found out that “Interface Builder” (IB) is not to be used by real men. I used to hand-code HTML and I knew how crappy those WYSIWYG editors were so I didn’t think this IB will be any different. Also, a builder tool is for newbies, right?
So the entire iPhone app was hand coded with beautiful segments of code to alloc views, init them, set their frame, color, alignment, alpha value, text when they are normal and text when they are highlighted, connected buttons to actions and let scrollview know if they should be paging or not. Very fun.
Seriously, I think 70 percent of the code was doing UI work. 90 percent of my time was shuffling pixels from one line of code to the other. I had so many #defines and static variables so the code would be… neat… and of course it wasn’t. Should I use the Interface Builder? Hell no, I’m a real man.
One day I decided to use the IB for our next upcoming feature. Just to try it out… it wouldn’t make me less of a man. That was a good decision. I found out that the IB is a time saver, a clutter saver and a pixel-nazi’s best friend.
From then on I I set a goal: “Always use the Interface Builder, unless impossible”. And so I did. I had my chance at working on some crazy, customisable, non-standard UI so believe me when I say that almost everything can be done using the IB.
Interface Builder is not a crappy WYSIWYG HTML editor. It will not make your code worse. It will not break when you upgrade to the next version of Xcode. It’s the suggested way to build the app UI, and real men DO use it.
Not convinced yet? Here’s the full list of reasons (IB > code) when it comes to UI:
1. Easy prototyping
When you just want to play around with an idea, you can use IB to drag and drop views and get an overall feel of your next feature.
2. Easy changing stuff
Oh, that view is a few pixels off? Let’s move it a bit to the left. IB is much faster at this then the usual loop of changing-values-in-your-code, running it on the simulator, rinse and repeat…
3. Less code
How many lines does it take to configure a label? At least 6: One for alloc’ing it, another for sizing it, another for an alignment mask, add one to choose a color, another for choosing the correct font, oh and don’t forget a line for setting the actual text on the label. Yes. you can throw this entire code away.
4. Easier to maintain
Once everything is configured, you can let your grandma play with the IB to change stuff. I don’t let my grandma touch my UI, but if my product manager asks for it, he can open the UI in the interface builder and have a kick at it.
5. All options are revealed
Do you know everything a view has to offer? When coding, you’ll have to lookup the header file or documentation of each and every parent-class of the view you’re creating. With IB all options are in front of you, so you can’t miss a feature like auto-sizing, text-shadow, content-offsets and others.
6. One for iPhone and one for iPad.
Creating a universal app? You can use a dedicated XIB for each device that uses the same class. Some people even use this feature to design one UI for portrait mode and a different for landscape.
7. Educate your designer
I showed my designer the IB and let him play with it a little. Once he figured out how I’m going to “build his PSDs”, he understood how to cut them into beautiful PNGs, all ready to use.
8. What can’t be done with it, can be done without it.
Yes, some things are impossible to achieve with the IB. For example, reusing a UI control from a different Xib is not yet possible. So what do I do? I create everything in the IB and connect them in code.
Today I added code so my button will use a stretched UIImage as its background. So the UIButton was all configured in the IB expect for this tiny unsupported feature. The point is it all plays along well.
Some people would suggest dropping the IB completely over this. They are plain wrong! It’s okay to turn to code when things are not possible. Maybe the next version of Xcode will allow it.
IB > Code
To sum it up: use IB whenever possible, but do know how to build the same UI using code. You’ll need both skills to create a killer, easy-to-maintain app.