Ever since I started out with iPhone development, I have seen a lot of debate online about the pros and cons of using the Interface Builder tool that comes as a part of the developer toolkit for Mac and iPhone development. For a lot of people, the tool comes across as basic, limited in scope, and sometimes entirely useless. For the developers at the other extreme, IB is an invincible tool without which there is no app development.
This Wednesday, I got the chance to debate just this with the CTO of an iPhone startup here in Washington, DC. While I am short on the person’s technical background, he did mention that his previous programming experience was doing website development using Flash and Dreamweaver.
The seed for the debate was laid last week when I met with their co-founder and while going over my experience with the SDK, briefly mentioned how elegant the app development workflow on the iPhone was, thanks due in large part to IB and the way it stores object information. I was then told that the company only believes in handcoding every single UI element for an iPhone app, and that it should be good reasoning out the benefits of each approach (hand coding vs. designing using the IB) with the company’s smartest person.
Having moved to Cocoa from a Java background, I can understand why a developer would not like the elegance and, arguably, added development steps mandated by the Interface Builder. Almost every programmer has been badly burnt by such tools in the past. And, almost all of these developers are only just now making a foray into Mac development because of how hot the market is right now. Every other programming framework has taught developers that it’s not the design that matters, rather the end product. Very few developers adhere to the keep it simple principle, and countless volumes have been written on why too much abstraction is actually a bad programming practice. While reusing code is a novel concept, there is a tradeoff with simplicity.
In the Mac world, such a conundrum does not exist. The tools for development are provided by the company that also happens to be the only company working on the Mac hardware and software ecosystem. They have a vested interest in making sure that development is consistently a wonderful experience for both the programmers as well as the testers. And, with a company that has such an academic backdrop of excellence, as Apple, chances are that they have spent a good amount of time in making sure that the development toolkit adheres to best practices in development.
Below are the points raised by the person and my reactions.
Interface Builder makes the project unwieldy and hard to understand.
This is absolutely not the case if you’re a good developer. One of the best practices I mentioned above is that application design is a separate task from application coding. Interface Builder lets you do the design work without worrying about what the code is going to look like. In almost all instances, it also provides you with a good way to enumerate the object and view interfaces that you would like to expose to other classes in your application. Design comes before coding, and by mixing the two, you’re absolutely laying the groundwork for making your application a terrible failure prone to App store rejection from the get go.
The reason your apps are difficult to understand is that the developer did not follow established norms when it comes to using IB. From Apple’s own documentation: ‘A very simple application might be able to store all of its user interface components in a single nib file, but for most applications, it is better to distribute components across multiple nib files’. The mainwindow.xib should be just that…the main window minus any views. This way, you minimize load times. Also, I follow the convention of having every view complex or custom view in its own nib. The formula I follow says that an nib should only have views that are needed at that particular application lifecycle state. This way, I know which nib to look at if I want to clarify some connections.
Basically, IB would only make the project unwieldy if a bad developer worked on it.
IB cannot do most customizations needed by apps
This argument lacks a backbone in 95% of the cases. You can perform almost all kinds of customizations using IB. Want a bunch of labels inside a UITableViewCell? How about a combination of labels and images? How about controls inside a UIScrollView? All this can be done using just the IB. Well, there are a lot of cases where you might want to handle customizations by code (complex composite cells for example), it doesn’t negate the fact that, even then, in the interest of keeping the design process consistent, you’re better off having an NIB before you customize. In fact, Apple recommends doing so because there is a lot of framework code that stands the chance of being over-ridden if you decide to do everything from container allocation to adding to a view programmatically.
That said, I would argue that over-customizing almost always leads to bad application sales. Almost all the best-selling apps for the iPhone maintain the signature look and feel of the preliminary pre-installed applications. There are no performance or behavioral gains from using non-native UI elements.
IB is for newbies; you learn with it, but give it up
Not unless you want to enforce bad design principles for the lifetime of all your subsequent Mac projects. As mentioned earlier, IB is a design as well as coding tool. It serializes objects in a file that is lazy loaded in a perfect order and with well-tested memory management in place. Also, doing so involves the use of a lot of frameworks that not only make life easier, but also reduce chances of code defects.
We have used design tools in the past, and UI development using code trumped all
This is just the side effect of using bad tools for a long time. Such thinking has to go. Apple developers have been working with IB for a few years now. The toolkit keeps on expanding and getting better. Don’t let your previous bad experiences let you make bad design decisions. Do it the right way. This is not an Adobe framework.
I am very interested in doing a followup to this post on a more technical level, but I really wanted to share with other fellow iPhone developers the importance of working with the IB, not against it. The tool is there for a reason. Learn to use it. Apple recommends IB for every project.
Remember, when it comes to software engineering, it’s not always the end result that matters, but also how much future proof that solution is. Being engineers, we’re also designers – software architects, and it is upto us to engineer something beautifully, or make our product look like a patchwork of sorts.