8 comments:

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.

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.

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).

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).

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.

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.