Thursday, July 8, 2010

Remove Interface Builder from the iPhone Project Templates

I find it frustrating that the XCode iPhone project templates are set up to use Interface Builder. Here are the steps to remove Interface Builder from the project templates:

  • Create a project using a template
  • Delete the .xib files from the project
  • In the .plist file, delete the "Main nib file base name*" properties
  • In main.m, pass the name of your Application Delegate class to the UIApplicationMain() function as the forth argument
  • Remove the IBOutlet keywords on the properties
  • Update application:didFinishLaunchingWithOptions: to create / initialize the application window

8 comments:

Dennis said...

I have to ask why are you fighting using IB? IB is not as inefficient as it may first seem. Coming from a Java background, I know the temptation is to put everything in code. But that's not how Apple designed the Cocoa APIs to work, though they will allow you to do it that way if you want.

I made the same mistake myself at the start of a couple of my early projects. Almost always I ended up either going back and putting IB back in or starting a new project with IB from the start.

mpv said...

I wasn't fighting Interface Builder it was fighting me and I walked away. I like code.

Dennis said...

I like code too - hence my initial attempts to bypass IB. But I quickly found that it was a loosing battle. Having your view completely encapsulated in XIB files means that you could hand them off to someone else quite easily.

Sure, you can do everything in code - and sometimes that's a great thing - but having the XIB files enforces the separation between model, view and controller that we should all be striving for.

mpv said...

Well, IB might help somewhat with MVC separation but it can't enforce it. I've found that in practice on significant projects (more than one or two programmers) the UI inevitable ends up partially in IB and partially in code and that split becomes at times a big pain in the ass. I think it is much better to have it all in one place (which is not IB).

mpv said...

Well, IB might help somewhat with MVC separation but it can't enforce it. I've found that in practice on significant projects (more than one or two programmers) the UI inevitable ends up partially in IB and partially in code and that split becomes at times a big pain in the ass. I think it is much better to have it all in one place (which is not IB).

Dennis said...

Whoa -- triple post :)

I haven't yet had the pleasure (or displeasure) of using IB with more than one person yet, so I can't comment there. But I would be interested in hearing about your experiences going down this route sometime in the future. It wasn't clear to me that I had made the wrong decision right away -- it wasn't until I had to spend time putting things back into IB later so that I could interoperate with some existing libraries did it dawn on me.

The thing about IB is that it wasn't something that Apple put together just for the iPhone. Or even MacOS X. IB has been around since the NeXT days. It's tested technology. Which means that whenever I start thinking that maybe IB isn't the tool I should be using, I like to step back and re-evaluate my own usage. And a lot of times it turns out that I was doing it wrong.

mpv said...

And I'd be interested in hearing about what libraries require IB. :-)

Dennis said...

OpenFeint heavily uses XIB files. Once I started integrating OF into my project, using IB became a must. Especially since I didn't have my project setup correctly for IB at the time. To make it work right, I had to go back and setup proper XIB files for each of my views. I probably could've made it work without IB, but it was much easier to not fight IB.

The other place where IB shines, IMO, is when you need to create a view in multiple places. You can just load the view each time you need it, and everything gets connected up as it should. You can certainly do that in code, as you can with anything that IB does -- but I happen to prefer the IB way myself.