Summa

My  background is with Java and Flex development, so there was a lot to get used to with Xcode. One of the steepest learning curves came with Interface Builder.  I’ve used technologies like JSP, Facelets for JSF, and Flex MXML to develop user interfaces.  In all of these technologies, you have a markup language that you use to describe what you want your interface to look like, and that markup has some way to reference code.

That was my predisposition, and Interface Builder was just a whole different world.

With Interface Builder, you are making a choice: do I want to write my interface with code or do I want to design it with Interface Builder?  There are pros and cons to both approaches, but it is good to know you are making the choice.  At first it may seem comparable to using a “design” view in Eclipse.  But in the latter case, the IDE is building that view based on the markup which you, the developer, can still edit directly.  With Interface Builder, you can’t edit the code.  It’s not a view of the code,  it is the interface.  And you have to jump through hoops to get your code to talk to that interface.

Those hoops are really why I am now more careful about when I use it.  You have to create an IBOutlet for everything you want to reference from your code.  If you want to refactor as your design changes, you have to hook everything up again.  Interface Builder is integrated well with Xcode to help with this, giving you yellow exclamation points to say, “Hey buddy! This property is gone, you better do something about it.”  But compared to a code refactor, it’s a soft warning and a lot of trouble.

After working with Xcode and IB for some time now, I have divined the following “lessons” for my own personal style:

• Unless I have a good reason, I prefer code to Interface Builder.  The iPhone screen is not too big, so there won’t be a ton to do.  Sometimes I even use IB to get me positioning info so I don’t have to do a lot of math, but then still draw the UI in code.
• If I have a screen that is heavy on layout, that’s a good reason.  I go ahead and do that in IB.  Maybe the screen has a ton of little pieces such that moving one will require you to move all the others.  Maybe there’s just a tight-fitting layout but you keep adjusting widths and positions.  All good candidates for Interface Builder.
• If a component is re-used often, say a UITableViewCell with a label and a value, I would definitely lay that out in code.  The amount of overhead needed to use Interface Builder, the amount of extra work needed to use outlets and make connections, etc. is just not worth the headache.

This is no means an exhaustive or prescriptive list — just the sum of my continual re-evaluations of how best to use Interface Builder in my own development.