andrewsardone

On today's train ride from Chicago to Ann Arbor, instead of trying to beat my friends' high scores in Doodle Jump (I'm a distant 3rd), I stopped to think about Justin William's recent tweets regarding Interface Builder.

Recommending someone not use Interface Builder when learning iOS development in 2011 is insane, unless you enjoy writing extra code.

Every project I've ever written has used Interface Builder. Less code = more gooder

There are many benefits to using Interface Builder (visual layout, quick simulation, etc.), but I was stuck on William's and others' 'less code' point.

Now, if we take 'code' here to strictly mean C/Objective-C code, then yes, view objects that are laid out in Interface Builder use less code. In fact, by this definition, they don't use any amount of code. But I'd say XIBs are code. A XIB file is an XML document representing serialized objects (views, controllers, their respective outlet connections, etc.) which are deserialized at runtime. And these documents consist of a lot of (practically) unreadable XML. Generate a project from Xcode's View-based Application template. The generated XIB for your initial UIViewController is 156 lines of XML. This XIB simply creates a full-screen root view with a gray background and other defaults. Let's take a look at how much code this requires if implemented directly within your UIViewController:

Four to six lines of code that, to me, are actually readable. Now, I don't get to see the nice visual layout, but when compared to reading the XIB's XML, this is a breeze. I'm dealing with objects and setting properties on them in the same manner I do everywhere else in the project.

But Andrew, you don't manipulate a XIB's XML directly. Instead, you rely on Interface Builder and its GUI to write changes to the XIB file. There's a translation layer, so comparing the -loadView chunk of code with the 156 lines of XML is foolish.

It is here that I see a problem. I don't know about you, but a decent chunk of my development time is spent in version control looking at diffs. Whether I'm reviewing a co-worker's set of changes or digging through the project's history, I'm dealing with changesets and their relevant diffs.

Look at the following two git commits. Each changeset implements the exact same thing: adding a functionless button.

The first is done in code:

The second via Interface Builder:

Looking at the first changeset, I can concisely see what happened. The second, to me, is garbage. Sure, I can look at the commit message, but the diff is pretty much worthless to me. I'll have to fire up Interface Builder and look at the new version without any good comparison to a previous revision. Suddenly, I have a tool at my disposal (version control) that lost a lot of power (and we're not even addressing the difficulties of resolving merge conflicts for XIBs).

So, Interface Builder might have its advantages, but I don't think reining in the amount of code (in a readable and diff-able, i.e., useful, manner) is one of them.

I gave a talk at a2div this evening on CouchDB and CouchApps. a2div is a great group that has hosted a lot of neat talks, so I thought I'd try to contribute.

I attempted to record the presentation but the audio did not work (so no video link, darn). Here are the slides though if anyone is interested.

This is just a quick tip given that a lot of people have grown to love TextMate's mate command. Simply add the following to your shell's configuration file to simulate the behavior for Xcode.

Without any parameters, xcode simply looks for an Xcode project file to open.

$ ls
Classes                Mapper-Info.plist      Mapper_Prefix.pch build
MainWindow.xib         Mapper.xcodeproj       RootViewController.xib main.m

$ xcode    # opens Mapper.xcodeproj

You can also name the file you'd like to open in Xcode.

$ xcode main.m    # opens main.m in an Xcode editor window