Last Sunday, I arrived back in Cupertino, CA, for another summer internship at Apple. Since arriving, it has been quite the whirlwind of activity (hence the fact that I have been unable to put up a blog post).
This summer, I am working on the same team at Apple, Interface Builder, which is a specific team of about 6 people in the Development Technologies group. I love what I am doing, and am really excited to be back again with the same people and such. I am living in some apartments across the street from the Apple campus (not the same place as last year) with my roommates Justin, Mike, and Elliot.
I will certainly try to get posts up as much as I can, but no promises given the insane amount of work to be done for some releases coming up.
Probably the most common question asked about IB 3 is: how do you subclass something? In IB 2, it was easy, right? You could just go to the class browser, find the class you wanted to subclass (typically NSObject), subclass it with a name, and then instantiate an instance of that subclass. But, what happened to the class browser in IB 3? Interface Builder 3 goes back to the idea of M-V-C: model, view, controller. For those of you familiar with this concept, you can ignore this next sentence: model is where you write code pertaining to data, view is where you write code or make graphics for what users see, and then finally, controller is where you write code relating to the response of user events. Thanks to Cocoa, the interface code is all written for us, and we can benefit from just dragging objects out of a library in IB. Our typical use to subclass an object in IB is to create a controller object or something similar that our interface talks to.
Note: Interface Builder is not the place to write code, that is the role of Xcode. IB has the ability to generate code, but more for a traditional sense. So the idea is to create a class in Xcode, and then bring the knowledge of that class into IB. Thanks to the smarts of IB, you don’t have to do any work for this, since IB is in constant communication with the pieces of your project. If you create a class, IB knows about it the next time you switch to IB from Xcode.OK, enough talk, how do I do this? Here is a step-by-step guide to subclassing something to use in IB (the example below is creating a subclass of NSObject called AppController)
- Create your class in Xcode
In your Xcode project, add a new Objective-C class file by choosing New File… from the File menu. Name the file AppController.m.
- Instantiate your class in IB
The instantiation process is two-fold. First, switch over to IB, and from the Library, drag an instance of NSObject (which you can find using the filter text-field) into your Document Window.
And your Document Window should look something like this now:

So now you have just instantiated NSObject, but what about your subclass? To make the instance you just created descend from your subclass, select in the Document Window, and then open the Identity Inspector (you can do this from the Tools menu, or if you have the inspector open, it is the sixth segment with the little “i”). Once the identity inspector is open, at the top of inspector, there is a slice called “Class Identity”, and under that is a text-field labeled “Class”. In that text-field, start typing the name of your subclass. As you are typing, by the time you get to “App”, it should have auto-completed the text-field with the name of your subclass. Again, please understand here, you no longer have to tell IB about classes in your project because IB has automatic integration with your project.

And your document window should now look something like this, with the “Object” replaced by “App Controller”.

At this point you are done, but if you would like to add connectivity to your class, proceed to step 3.
- Add actions and outlets
Now that you have an instance of your subclass to work with in IB, you may very well want to add some connectivity between it and the interface. To do so, you can add outlets(IBOutlet) and actions (IBAction) to your class’s header file. To do so, go back to Xcode, and enter them where desired. If you need more help on this, please see the Cocoa tutorials on connections. Once you have created your outlets and actions in Xcode, switch back to IB, and by the time you do so, IB already has parsed your source code and found all of the outlets and actions, and they are now readily available for you to use.
So to quickly recap:
- Create your class in Xcode
- Switch to IB and add an instance of NSObject from the Library
- Change the instances class name to your subclass using the Identity Inspector
- Add actions and outlets
- Realize that subclassing in IB 3 is a lot easier than in IB 2
So, in case you have not already heard, which most people really have, this summer I will be interning at Apple Computer in Cupertino CA, about 45 minutes south of San Fransisco in the heart of Silicon Valley. Probably a question that you are more prone to ask is, what will you be doing? Well, I do not exactly know yet. I do know, however, that I will be working on the Interface Builder team. Interface Builder is an application that helps Macintosh developers make user interfaces. You can read more about Interface Builder by clicking on the link below.And by the way, I didn’t really leave my heart there. I actually am leaving my heart in Wheaton.Read more about Apple.Read more about Interface Builder.
I’m sorry if this image looks fuzzy in Windows