Volume Number: 19 (2003)
Issue Number: 8
Column Tag: Viewpoint

Apple's Developer Toolchain

Or, how I learned to appreciate Objective C

by John C. Daub

Mac OS X has been publicly available for over two years. Many others and myself have come to appreciate the "native" offerings that Mac OS X brings, such as increased stability and true multitasking. But one thing that still boggles my mind is how many Mac OS software developers still balk at the "native" Mac OS X software developer toolchain; by that I mean: Cocoa, Project Builder, Interface Builder, and Objective C. I have found this toolchain greatly increases my productivity over my previous toolchain, and it pains me whenever I find a Mac OS software developer that simply refuses to give it a try. I admit I too had "bracket shock" when I first looked at Objective C source code, but I'm glad I didn't let that scare me away because I've found a way to develop software faster and better than the way I was previously developing.

Cocoa is the name for Apple's native object oriented application development frameworks. These days it's safe to say Cocoa's chief competitor is PowerPlant, Metrowerks' object oriented application development framework. Cocoa and PowerPlant work to accomplish the same goal: wrap up the procedures of the operating system and present them to the developer in an object oriented manner, along with utility and helper classes that solve common programming problems to facilitate faster application development. I believe Cocoa does it better, and I think that's due in part to the maturity of Cocoa as an API. I've found Cocoa's abilities to be very broad and very deep, providing me with just about everything I need apart from whatever specifics there are to my application's logic. As an example, I wanted to hack up a small application to help me keep my notes. I started in PowerPlant and after two weeks was greatly frustrated at how much work I had done and how little I had accomplished because in that time I was still struggling to get the foundation for the application established. I had just finished going through the Learning Cocoa book and decided to try using Cocoa to hack up my application. Even with my inexperience, within a day I had gotten further working in Cocoa than I did in PowerPlant, and I believe this was due to the breadth and depth of the API that Cocoa provides.

One thing about PowerPlant's design is the "buffet style" approach it takes. PowerPlant is intentionally designed so that its classes can be used together or separately; one is able to pick out and use what looks interesting. While I certainly find merit to this approach, in my years of using PowerPlant I've also found myself occasionally frustrated by this approach. When I worked for Pervasive Software developing Tango 2000 I used the MacApp framework, which is more of an "all or nothing" framework as it has a common base class which most all classes inherit from: TObject. Cocoa has a similar approach with most all classes inheriting from NSObject. I actually didn't find this approach as bad as I was lead to believe, and since my MacApp experiences I've grown to actually appreciate and prefer a common "object" base class. This is because I've found myself striving to write code in more of a true object oriented manner, and it helps when everything you're working with is an object.

When I work in Cocoa I feel like I'm programming the system in an object oriented fashion, unlike Carbon, which is procedural in nature. One thing that helps make this possible is how the Objective C language and runtime is integrated into the system. I'll speak more on Objective C later in the article. But along the lines of integration is the core development applications: Interface Builder and Project Builder.

Project Builder is Apple's project management tool. It's akin to the CodeWarrior IDE in terms of the problem it's providing a solution for - project management. Most Mac programmers these days have used CodeWarrior and feel that Project Builder isn't quite the tool that the CodeWarrior IDE is. I tend to agree with that assessment. There are a lot of nice things that Project Builder can do because of how it's implemented, such as how it takes advantage of the runtime environment that Mac OS X provides whereas the CodeWarrior IDE is still WaitNextEvent/Thread Manager based. I do find CodeWarrior's class browser features to be wonderful and miss them greatly when I work in Project Builder, but at least as of CodeWarrior Pro 8.3 its class browser didn't support Objective C (heck, the function popup still doesn't grok Objective C). But then I find Project Builder's integration with API documentation very handy. I find myself preferring Metrowerks' compilers to gcc and that the MSL C++ libraries are an excellent piece of work. But then tool integration like the CodeWarrior IDE and Constructor just isn't there like it is with Project Builder and Interface Builder.

Project Builder is certainly a more than usable product, but it does have a ways to go, especially if it wants to bring the die-hard CodeWarriors into the fold. As I revise my writing of this article, WWDC 2003 just ended and at the show Apple announced Xcode, their new integrated development environment (see Dave Mark's guided tour of Xcode elsewhere in this issue). I believe Project Builder is presently the weakest link in the Apple toolchain, but the features and promises that Xcode makes certainly raise the bar for Mac developer tools. Let's hope Xcode can deliver on those promises and that the competition between Apple and Metrowerks leads only to good things for Mac developers and ultimately Mac users. However, at present we still have to work with Project Builder and it remains the weakest link in the chain, but it doesn't bother me that much because I find Interface Builder to be one of the stronger links in the chain.

In my experience, I have found Interface Builder to be a hands-down better tool than Constructor. Constructor is a good and necessary tool, indispensable for PowerPlant programming. But I have found Interface Builder better suits my needs.

I find the whole GUI layout process works nicer in Interface Builder. When laying out widgets, there are guides to help enforce the layout dimensions and measurements from the Apple Human Interface Guidelines - I'm not wasting time and straining my eyes to count pixels. I also love how I can try out my GUI from within Interface Builder to really get a good idea about how my GUI is going to look and feel. It's a terrific tool for RAD development and prototyping, not to mention mocking up screenshots for design documentation.

Even though the application is called Interface Builder, I consider it a tool for more than just building your GUI - it's a tool to build your objects and establish relationships between those objects. In Interface Builder you can not only construct your GUI objects, but you typically will create other objects such as controllers and data sources. From within Interface Builder you can create the (sub)class, instantiate the object, and even generate the skeleton source code which Interface Builder can automatically add to your project open in Project Builder. When generating source code, Interface Builder can generate it as Java or Objective C. While Java's a good language, when I'm developing Mac OS X software I'm finding that I prefer Objective C.

The more I use Objective C the more I find it to be a really cool language. It looks scary at first, but it takes maybe 30 minutes to understand the basics of Objective C and perhaps a weekend of tinkering with tutorials and sample projects to really grok how the language works. If you're familiar with object oriented programming from C++ or Java, you'll find many similar concepts in Objective C; in fact, Objective C influenced Java's development. Once you understand how the language works, then you'll be ready to understand how Cocoa works.

Just because a language may not be widely popular, like Latin, there's sometimes still merit to learning and knowing that language. Objective C ultimately is C with, in my opinion, better object oriented concepts tacked onto it than C++ tacked on to C. The bracket syntax is better thought of as message passing. In C++ you might do this:

   object->Method();

or a PowerPlant programmer might do this:

   widget->BroadcastMessage(msg_SomeMessage, ioParam);

In Objective C you'd do this:

   [object method];

In terms of what it functionally means, it's all the same: having an object do something. What's different is the syntax for how messages are passed to objects: in C++ you call an object's function, in Objective C you're passing the object a message. What's also different but not apparent from looking at the code is in C++ the function and it arguments are joined together in compiled code, whereas in Objective C the message and the receiving object aren't bound together until the program is running and the message is actually sent; this is called dynamic binding. Dynamic binding gives Objective C a great deal of power as an object oriented programming language since at runtime a developer can vary not only the messages sent but the objects receiving those messages. Receivers and messages can be determined on the fly and be made contingent upon external factors like user input. Ultimately I think of Objective C as just another language in my toolset. But if you think about speaking languages (English, Spanish, French, etc.), the more languages you know the more you can understand, describe, and work with the world around you. Knowing more languages helps you think a little different, a little better - your horizons are broadened.

One thing I should tell you is that years ago I worked as an employee of Metrowerks as a PowerPlant engineer. As much as I adore PowerPlant, I've really come to discover the limitations with the C++ language. I believe that C++ is a great language for generic programming (templates are awesome), but I'm finding Objective C to be a better language for object oriented programming. Objective C's support for dynamic typing, dynamic binding, and messaging feel to me to lend better to the paradigms of object oriented programming. And within Apple's developer toolchain, I believe Objective C is the linchpin that makes it all possible.

Sure I miss C++ isms like using stack-based classes for cleanup, but I'm also finding that with well-crafted code I don't need those facilities when I write in Objective C. I've found constructs like categories to be very useful so that I can extend a class without having to subclass and create a new type (e.g. I can add Str255 "constructors" to NSString via a category). What I find most powerful about Objective C is how the language is dynamic and binding occurs at runtime. This has allowed me to write some really neat code that I just couldn't do in a static compile-time binding language like C++. But I haven't abandoned C++ entirely because again it's a great generic programming language. Plus if you have to write code that's cross-platform, C++ makes for a good choice. You can write your generic engine code in C++ and share that across platforms, then write your platform-specific GUI code in Cocoa (for Mac). The Objective C++ language and compiler support allows C++ and Objective C code to live together in almost perfect harmony.

Sometimes it feels strange to me to use something (Cocoa) other than what I had a hand in creating (PowerPlant). Sometimes I feel that having Objective C on my resume won't get me as far as it would having Java on my resume. But I've gotten over these feelings. I've come to a point in my career where I no longer care to be a religious zealot about a computing platform or a programming language or a development framework. I just want to be a zealot for creating insanely great software for Mac OS X. My users don't care if I use Carbon or Cocoa, PowerPlant or REALbasic, C++ or Objective C, CodeWarrior or Apple tools. Users just want software that provides solutions and works well, and they want it today. So when I am presented with a programming problem, I don't first pick my toolset then cram my solution into it. I now analyze the problem and work to determine what tools will be most appropriate to solve the problem. Maybe Java and the Swing libraries will be the best solution. Maybe C++ and PowerPlant or Qt will be a more appropriate tool. Or maybe quickly hacking up a Perl script will be the best tool for the job. The more variety of tools I have in my toolchest, the more power I have to pick the right tool for the job to ensure I can do the job effectively.

I have discovered that when I use Apple's developer toolchain of Cocoa, Project Builder, Interface Builder, and Objective C all coupled with the killer environment that is Mac OS X, I find I can deliver more robust solutions in less time. It may not always be my toolset of choice for a particular project, but at least since I know about and how to use the toolchain I can see the disadvantages and advantages that it has. For example, a project I'm presently working on has requirements that forced me to drop Project Builder for CodeWarrior because of some issues with the -header-mapfile option that I couldn't work around any other way. But I'm still using Cocoa, Interface Builder, and Objective C (along with C, C++, and Objective C++) in this project. Generally speaking, Apple's toolchain is becoming my toolset of choice because of the power, speed, and flexibility inherent in the system. In a few years I may feel differently. PowerPlant X is on the horizon and I know Metrowerks is working hard to maintain their lead as a tools platform. And with the release of Apple's Xcode, it's obvious that Apple isn't resting on their laurels when it comes to developer tools. I hope this competition in the developer tools space will only lead to better solutions for developers, which means better software for end users, and that keeps us all in a job.

If you haven't given Apple's developer toolchain a try, dedicate a weekend to trying it out. Set your biases aside and just give it an honest try. Even if you don't stick with it, at least you've been able to evaluate it from a more hands-on perspective. By knowing a little bit more about the toolchain, it helps you to expand your knowledge and toolset. I believe that will make you a better and more valuable software developer.

John C. Daub is a MacTech Magazine Contributing Editor, a Mac OS Software Developer for Aladdin Systems, Inc., and Grand Pooh-bah of Hsoi's Shop. John resides in Austin, Texas USA with his wife, three children, two cats, and a tank full of tropical fish. He strongly believes Californian's have no idea what good BBQ is. Thanx to Adriaan Tijsseling for the article review. You can reach John via email at hsoi@hsoi.com.