The Java Perspective: Cocoa's Interface Builder
Let me start off by saying that I am rather "hard-core" when it comes to Java GUI development. I am a strong believer in the Swing/JFC API and have written several articles on the subject. I write all my Swing GUI code by hand. I do not use any WYSIWYG tools in my Swing development, and I enjoy using GridBagLayout (arguably the hardest layout manager out there).
Until recently, I did all of my development using vim and only recently switched over to using Intellij's IDEA. That switch was mainly due to my aging memory and inability to keep 100 percent of the methods and packages straight in my head. However, even using that IDE, I still avoid graphical Swing development tools like the plague because they produce slow and bloated code and because these tools do not write code the same way that I do (so they produce code that is difficult to maintain).
Introduction to Interface Builder
When I first approached Cocoa development, I started by walking through the tutorials provided by Apple on its developer website and worked with every tutorial in Aaron Hillegass' excellent book, Cocoa Programming for Mac OS X. I admit to some trepidation when I approached Interface Builder. All the tutorials used it—I checked. I looked for programmatic ways to build the GUIs in the tutorials and I could not find them. (I eventually found them, but that's another story.)
So with my dislike of WYSIWYG tools in hand, I approached Interface Builder and started working through the tutorials. My first tutorial was trivial: It involved a simple GUI with one window, two buttons, and a label. After I completed the tutorial I looked back at it with wonder.
In that small project I learned the following:
- Interface Builder is not a code generator.
- Interface Builder is an integral part of the development process on Cocoa.
- You can build Cocoa projects without Interface Builder, but it would be just plain silly.
Interface Builder approaches GUI design in a way that is quite foreign to a Java developer. It took quite awhile for me to properly grok it. Once I did, I realized that its solution made perfect sense and I enjoyed using it.
Interface Builder works by creating a real instance of the GUI. When you drag and drop a button onto a window in Interface Builder, the underlying code actually instantiates that button and places it on the GUI. When you are done with a GUI and save it, the GUI is serialized to disk. When your application starts up, the GUI's nib file is de-serialized back into memory, which produces faster startup times because the objects do not need to be initialized, nor do any of the connections need to be established.