From the author of

From the author of

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.