Scott Stevenson interviews Aaron Hillegass about the new edition of Aaron's book, programmers' fear of the NIB file, and why there aren't more Macs in corporate America.



Scott Stevenson: What sort of experience should a developer already have before reading Cocoa Programming for Mac OS X? Do they need to know anything about using Apple's development tools or Objective-C?

Aaron Hillegass: One of the most difficult things about writing a book is choosing your audience. It would be great to write a book that assumes nothing; anyone could read it. However, an experienced programmer would find the resulting book painfully tedious.

In the end, I decided to assume that readers are familiar with the C programming language and thinking in an object-oriented manner. The reader with this base knowledge will find Objective-C to be a rather unsurprising language, so the book moves quickly through the fundamentals of Objective-C and into the design patterns of Cocoa.

Scott: Conversely, how far does this edition take the reader? In other words, if a developer has already stumbled through the basics, knows the Objective-C syntax, and has compiled a few sample apps, will they find this book useful?

Aaron: I think the old adage rings true: "If you only know how to use a hammer, everything looks like a nail."

The typical self-taught Cocoa programmer has mastered a few concepts and uses them in every situation. By going through the book from beginning to end, the reader gets familiarity with a large collection of ideas and technologies. This deeper understanding results in better, more reliable applications — because the reader uses the Cocoa frameworks as they were intended to be used.

The book doesn't cover everything — that would take thousands of pages — but I have done my best to identify and explain the concepts that the average Cocoa programmer uses on the average day.

There is also some interesting feedback in the system: Because my book has become the standard approach to learning Cocoa programming, a lot of documentation and discussion on the internet assumes that the audience has read it. Thus, the chapters in the book now represent the core knowledge that every Cocoa programmer is expected to have.

Scott: I see that you've refined many of the existing chapters, as well as added brand new material. Which new chapter did you find the most interesting to write, and which existing chapter received the most re-working?

Aaron: For years, I have taught students in my classes how to do view swapping in an elegant, maintainable way. With 10.5, Apple added the NSViewController to Cocoa. It isn't nearly as glamourous as Core Data or Core Animation, but I think the chapter on View Swapping was the most satisfying addition because it is a technique that Cocoa programmers use daily.

The NSArrayController chapter was reworked so much that it eventually underwent mitosis and became two chapters: One dedicated just to the ideas of Key-Value Coding and Key-Value Observing and a second devoted to the mechanics of using these ideas with NSArrayController.

Scott: I've seen emails from novice developers who liked the way the previous editions of the book were written, but were confused how they didn't match up with the recent changes in Mac OS X 10.5 Leopard. Has all of that been addressed now?

Aaron: If Apple would just stop innovating, I would stop rewriting this book and write new ones instead. Yes, the third edition is now up-to-date with Xcode 3.1 and Mac OS X 10.5.

The world outside Apple has also been changing. For example, web services have also become very important, so I added the web services chapter to the book.

Scott: What was the most challenging part of writing this edition of the book?

Aaron: The technologies documented in the first and second edition of the book had been around for a decade, and the community had developed a set of common idioms and best-practices. I could authoritatively say, "This is how we do it." The new technologies — Core Animation, Garbage Collection, and Core Data — don't have a deep history. No one can speak about their use with complete authority. I did my best to study how the engineers who created them wanted the technologies to be used.

Scott: Is the material in this book a good starting point for developers looking to hit the ground running with the iPhone SDK, or are the development concepts too different? Do you plan to write a book specific to iPhone development?

Aaron: There is, at this point, no better starting point for iPhone development than "Cocoa Programming for Mac OS X." If you understand the book, you can get started with iPhone development. There are ideas that have changed — for example, controls on the iPhone can have multiple targets and actions — but they have evolved naturally from the ideas of Cocoa programming.

In September, Big Nerd Ranch (my company) will debut its iPhone Development Bootcamp. That class, which will be every bit as brilliant as our Cocoa Bootcamp, is going to focus only on iPhone development. By removing ideas like the pasteboard, we create time and space for discussions of iPhone-specific topics like the CoreLocation framework and the accelerometer.

Perhaps that class will become a book someday, but we need to test and improve it in the classroom for a while first.

Scott: What would you say to new developers who are trying to figure out if they should learn Objective-C or use one of the Cocoa scripting bridges in Leopard? On a related note, what do you think about the comments from those who say Apple should have based the iPhone SDK on Java or C++?

Aaron: For fifty years, there has been a heated debate going on about programming languages. In the meantime, real programmers have been solving real problems with imperfect languages like Perl and Objective-C. Why?

Perl and Objective-C have three things in common:

They come with incredible libraries. Perl has CPAN and Objective-C has Cocoa. They don't get in your way. Both languages have good performance and loose typing. They are easy to learn.

Ruby and Python are lovely scripting languages, and you can write Cocoa applications with them after you learn Objective-C!

Cocoa was written in Objective-C and for Objective-C. You will never really understand Cocoa until you understand Objective-C.

It is true that some people have voiced the opinion that the iPhone SDK should have been based on languages other than Objective-C. However, it is important to note that none of these people have ever shipped an application written in Objective-C. Anyone who has used Objective-C knows that it is an able work-horse.

Scott: What do you think are the most common misconceptions that new Mac developers have coming from Windows, Java, or even traditional C++ GUI toolkits?

Aaron: Fear of the NIB file. Experienced Cocoa programmers put a lot of the smarts of their application in the NIB file. As a result, their project has a lot less code. Programmers who have spent a few years working in Visual Studio get freaked out. They ask me stuff like, "Can I write Cocoa apps without using Interface Builder? I like to see the code. Maybe I can just explicitly create my windows and the views that go on it?"

It is difficult to explain how the NIB file (and a few other scary ideas) create leverage. It is that leverage that enables one guy in his basement to compete with a team of engineers at Microsoft or Adobe. It is like I showed a chain saw to a early American colonist, and he said, "Can I cut down the tree without starting the engine? I don't like the noise. Maybe I can just bang it against the tree?"

Scott: I think a lot of developers wonder how to get their work noticed by potential employers, customers, and the community. Do you have any suggestions?

Aaron: One of the nice things about the Mac community is that quality gets noticed. People love their Macs, and anything or anyone who can make it better will get recognized in blogs and discussion groups and magazine articles. The Mac community has been very kind to me; people have spent a lot of energy explaining the strengths and weaknesses of my books and my classes. I couldn't be more grateful.

Scott: What sort of effect do you think the iPhone will have on the Mac development community? Do you think they'll divide into separate camps, or is it more likely that the lines will blur? Do you expect to see an influx of new Mac developers from the iPhone?

Aaron: It is a great time to be a Cocoa programmer. Apple is selling 50% more Macs than they did a year ago. They are selling iPhones by the boatload. The Cocoa community is, in the grand scheme of things, rather small right now. I suspect that it will double in size over the next two years. Everyone in that community will know how to write code for either device.

But! A good iPhone app is going to be very different from a good Mac app. iPhone apps are going to be smaller and simpler. Overall, I suspect that a brilliant iPhone app will take six months to write, while a brilliant Mac app takes five years. I suspect that there will be two camps — not because the skill sets are different, but because iPhone programmers will have different personalities and proclivities than Mac programmers.

Scott: The Mac appears to be making real inroads in the mainstream consumer computing market, and certainly the iPhone is doing the same. Do you expect to see this carry over to the corporate world?

Aaron: Apple seems to doing its best to keep Macs out of the corporate world. Most dialogues between Apple and a corporation go something like this:

Corporation: Hey, does Cocoa include something to help us write apps that talk to our Oracle database? Apple: Um, nope. But isn't GarageBand cool? Corporation: Hmm.

Scott: What do you find most rewarding about the books you've written and the classes you've taught? Seeing the light go on in the student's head, seeing them ship an app, or something else?

Aaron: I'm a good programmer — I've written large medical, military, and financial systems — but that is not my calling. I am a teacher, and I live to get people to "Aha!"

Over my career, I've developed and tested many theories about teaching and learning. Now, I want to make these ideas manifest in a physical form. I have purchased some land, and I'm working with architects to design an environment for learning — the new Big Nerd Ranch.

Scott: Mac development has changed a lot in the last few years, and dramatically so in the last six months. What sort of things surprise you when you see them now versus how things were when the first edition of the book came out in 2002?

Aaron: I think people overestimate how much has changed since 1991. If we thawed out a developer who had been writing an app for the NeXT computer in 1992, he would not feel out of place on Mac OS X 10.5. The last 16 years have been spent making significant, but evolutionary, steps toward fulfilling the promises embodied by the elegant ideas in NeXTSTEP 1.0.

Scott: When you're not busy writing, do you spend most of your time teaching classes in person, or are you involved in other projects?

Aaron: I teach about a dozen classes each year. I continue to help our clients write applications for the Mac, and now the iPhone, but as Big Nerd Ranch grows, I spend more and more of my day being a business guy. We are always developing new courses on technologies like Django and Android — I spend a lot of time editing these new courses.

Scott: Will you be at Apple's Worldwide Developers Conference in June? How should developers that want to meet you in person at the conference try to track you down?

Aaron: I'll be at WWDC, and I'm always happy to meet new people. I am pretty easy to spot — I'm quite tall and I wear a cowboy hat. Please come say hello.

Scott Stevenson runs Cocoa Dev Central and theocacao.com, which help programmers learn how to write software for the Mac. Scott also owns a tiny company called Tree House Ideas.