It's exactly the opposite of magical: you're simply building objects in IB that are "live" while you're building them and that then are freeze-dried when you save the file, and reconstituted at runtime.
It's certainly magical in the sense that it's a beautiful way to do things. ;-)
I prefer a programming model that is not so complicated that you need an IDE to generate the code for you. Even watching the Apple tutorials on using XCode I was struck by how many magic incantations you have to kearn that seem totally opaque and unmotivated (just hold down command and drag this thing on top of that thing and set this property in the pop up - what?).
I think simple programs should be able to be expressed in one file and created in a simple text editor.
You're missing the point: no code is being generated. Objects are being generated. The real objects you'll have at runtime are being generated. The real objects that will be freeze-dried to a file and reconstituted at runtime.
You're saving creating the hundreds of lines of codes that would be required to do this in a "normal" IDE.
This seems a patently false statement. I would count as code any representation of procedural or configuration information that could be interpreted or executed in the running of an application.
If the underlying systems requires hundreds of lines to represent a simple object (like a button, panel, or toolbar), then maybe as a programming environment designer, you should go back and simplify your underlying representation, rather than add a layer of UI to generate hundreds of lines of code.
...which is a big part of why Interface Builder is handy, because it saves you from trying to figure out exactly how large you want the button to be and where to put it.
Now, when you put together all the objects in a moderately complicated UI, you will end up with hundreds of lines of code. Some people find it easier to work with this visually in Interface Builder. Others find it easier to manually construct the UI in code. Either method works perfectly well. I generally use a mix of both, depending on the nature of the UI element I'm working with.
> Some people find it easier to work with this visually in Interface Builder.
All of our designers use IB to layout the UI. It works really well - as they don't have to touch the code and we don't have to touch the layout.
Unfortunately, if you are doing any kind of custom animation (think sliding/expanding), IB is useless - you'll have to set the frames in code.
In general, IB is great because it helps separate presentation from the code.
When I first started out, I hated IB, but I've come to accept the fact that it really does help productivity (when working with designers closely). If you hate IB, consider going Android - there is nothing like IB on Android. All XML and a simple (nothing like IB) layout editor.
Serialization, marshaling, pickling...whatever your favorite terminology, that's all a nib is: archived object instances. If you don't have a mental model for that then you've got bigger problems than interface builder.
I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on.
I suppose I could have gotten over those mental hurdles eventually, but I chose not to. I prefer thinking about objects that I make myself, and I avoid Interface Builder whenever possible.
Even if you just wrap your head around File's Owner, you're 80% of the way there. Essentially, what it boils down to is this: it's a proxy object that gets set when NSBundle's loadNibNamed:owner:options: is called (which is called behind-the-scenes by UIViewController, which is where you'll usually be interacting with nibs). So, in Interface Builder, you change the class of File's Owner to whatever class should be managing the nib and it will give you access to all of that class's IBOutlets.
Like you, I prefer to create a lot of my UI programatically. But in a lot of cases it's just so much more efficient (from a time management perspective) to lay everything out in Interface Builder.
