Thursday, July 22, 2010

A case for Interface Builder

There is a lot of hatred for Apple's UI tool Interface Builder among many programmers. I was firmly in that camp but lately have seen some advantages.. Especially as our last project spiraled over budget.

I've released 8 apps without using a single XIB. But the next one I'm planning on relying heavily on the tool. Here's why:

- Design/implement GUI graphically, right brained like you will use the program
- LESS LINES OF CODE to debug, write, remember to think about retain counts and spend dozens of lines setting up, say text field properties
- Less memory management! The whole XIB is loaded/unloaded behind the scenes
- Share the XIBs so DESIGNERS CAN LAY THEM OUT. No more time spent pixel pushing from a PSD comp, the designer will create the VERY LAYOUT U WILL USE! :D
- Less buggy code. IB makes sure you are initializing, configuring and disposing properly. (Not that *I* need that)
- FASTER development of a complex UI. If you have 10+ styled elements on a view, it takes probably 50 lines of code to set them up right. With IB it takes zero.

Now, the shortcomings.. (Rumored XCode 4 with integrated IB might fix some of this)
- Terminology is confusing. Outlets, "File's Owner" etc are never used in non-IB code, so pure coders don't know what they do
- Seems difficult to style/configure certain things. Attaching a UITableViewCell to a UITableView for example.
- The magic of how the elements interact with the code is a hurdle for many at first.

Ultimately I wouldn't recommend newbies using IB. Get a firm grasp on the codez first and then you will see how IB can help you.