... I understood every word, and the only thing I've ever programmed is a clockwork cooker timer. Well written.

As a 3D artist who recently made the decision to learn a bit of programming, I can say this is a pretty sweet article. I'm totally mac-based, so I'm not so "down" with the windows jargon as others might be here, but I can say that I'm only a little way into Obj-C, and already I like it. Never having done much real programming to date, the learning curve is quite astronomical in places (esp. with the maths, didn't expect quite so much mathematics), with things like unary operators (?) and matrixes! Still, I'm getting there, and your article has given me a couple of pointers here and there, probably since it's looking at the whole thing from a slightly different angle. I look forward to the next instalment!

Nice, looking forward to it. Although could you also compare how it differs to Java? My C++ is practically non-existent!

... and bypass the whole OS-dependency thing altogether.

And your apps would work on Linux too, with no extra work, earning you the love and admiration of penguinistas everywhere.

It's best not to think of Java. So comparison would be confusing. The syntax and back to pointers for objects is real guts of it. Then there's Interface Builder and wiring up the classes, actions and outlets. These things are things to get your head around. Aaron Hillegass has excellent book on Mac coding.

I look forward to your coverage of Interface Builder, which I think is the most difficult component for a someone to get used to when moving from say Visual Studio or Delphi to XCode.

There's this guy at Apple who will correct people who post to Apple's discussion lists when they write XCode.

I would recommend anyone interested in Mac programming to visits lists.apple.com and sign up for the Cocoa list (lot of traffic, sometimes daunting so stick with it), and the Xcode list.

As it might or might not have been mentioned, Obj-C was one of the inspirations for Java. The real difference is not just C and its speed, but in what things are vs. what they can do.

A big win of Obj-C and cocoa is the delegate and protocol concepts. That is, rarely do you subclass in as much as simply support various messages; since it's dispatched at runtime, it'll work out. If it handles the functions fine, who cares what the internal structure looks like?

As for UI, there is a Cocoa for Java API, but it's quickly falling by the wayside. And using straight Java is pretty much a garunteed failure. Not just for the usual reasons (Speed, etc) but because mac users are very demanding on the interface. What is perfectly fine for Windows and Linux is considered barely marginal at best for the Mac.

For example, we expect any text field to support the text-to-speech, interapplication drag-and-drop, the full spell-checker, unicode and multi-lingual support, and the other services in text fields. Fortunately, NSTextField provides all this for free. Want a spell-checker in your program for this text field? Check a box in Interface Builder. These are features that a one-size-fits-all approach will fail to have.

I'm a Mac developer who moved to Cocoa about three or four years ago, and has never looked back (I was using C++ before that with Carbon). It's good to see articles like this coming from a not obviously Mac-related site. As a professional developer I find Cocoa to be the most productive API (and with Xcode, toolset) I have ever used, bar none. And that' s by a considerable margin. I'd say to anyone wanting to dip their toes in the waters of Mac development: go for it. Obj-C's syntax might seem odd at first but after a while you'll appreciate its readability if not actually love it. And you can build a very functional small app (say, a complete word processor) in an hour or two which should be enough to impress the most hardened old coders. As for Java - well, it may be cross platform but (Mac) users know a Java app when they are forced to use one, so if you really want to make "proper" Mac apps, Cocoa is about the only reasonable way. I also find Java's documentation and class libraries bewilderingly complex compared to Cocoa's. Cocoa isn't perfect and has a few holes, but one of the great things about it is that plugging them is really easy (thanks to categories, among other things). I could go on... but I think I've made my point.

"But the end-user sees only a single file which can be installed by simply dragging to the Applications folder or de-installed by dragging to the trash. Ah, if only Windows worked like that."

There are lots of Mac apps that require installers - heck iLife - arguably the showcase Mac app set - requires an installer. Anything that comes in a .pkg file is going to be using an installer. If you just drag the application to the trash for these, you'll leave bits of the application behind - and you may even break tasks that the installer installs. The day of 'uninstall any app by dropping the app in the trash' disappeared a long time ago and it's weird that this myth is still being promoted.

On the flip side, .Net apps (which are the foundation of Windows moving forwards) not only do not require an installer (although they may use them) - the use of them is highly discouraged (xcopy is preferred). All .Net apps I write are drag install/uninstall. None of them have installers.

I hope the rest of this article series is a bit more accurate...

Anonymous said: "Nice, looking forward to it. Although could you also compare how it differs to Java? My C++ is practically non-existent!"

Hi Anonymous. I don't really want to get too bogged down in language comparisons. The main aim here is to look at things from a typical Windows developer's POV. I guess you could argue that a Windows Java developer moving to the Mac will just carry on using Java. Or so the Java zealots would have us believe. ;-)

Uncle Mac

Sorry Douglas. I guess old (case-insensitive!) habits die hard...

Uncle Mac (one time Delphi programmer) ;-)

Anonymous said:

"There are lots of Mac apps that require installers - heck iLife - arguably the showcase Mac app set - requires an installer."

In context, I was trying to explain bundles & frameworks, not trying to write an article on Mac installer technology. For sure, there are Mac apps which you can't just drag-install. But there will always be exceptions on both sides: contrary to what you imply, for example, there are plenty of .NET apps which use a custom installer.

I believe that one of the reasons iLife uses an installer is because it installs a certain amount of shared stuff into /System/Library/PrivateFrameworks. As an example, iLife '08 updates the media browser framework. But at the expense of some extra disk space, there's no reason it had to be done that way...

Uncle Mac

"All .Net apps I write are drag install/uninstall. None of them have installers."

Really? So you never put anything in the GAC? That doesn't sound like a proper .NET app to me!