Original URL: http://www.theregister.co.uk/2007/08/14/making_move_mac/

Making the move to the Mac

Mac development for Windows programmers

By Uncle Mac

Posted in Developer, 14th August 2007 11:14 GMT

As should be pretty clear from previous ramblings, I've about given up on Windows and am in the process of trying to reinvent myself as a Mac developer (I should perhaps say re-reinvent myself, since I worked with Macs back in the early days of the original 128K Mac, over 20 years ago).

Things are going pretty well so far, and if I could only resist the temptation to disassemble bits of the AppKit framework whenever I have an idle moment (see here for more on my strange personal habits) then I might actually have had a shareware application or two out by now.

This article is aimed at Windows developers who are considering making the move. The idea is to get you up to speed as quickly as possible with mainstream Mac development. Rather than discussing cross-platform programming techniques and toolkits (the subject of previous articles), I'm going to focus unashamedly on Cocoa and Objective-C. I'll assume only that you're coming at things from a RAD perspective: Delphi, WinForms on .NET, or maybe even "classic" Visual Basic. Think of this article as a "Dummmies Guide" to Mac programming if you like. All I'm trying to do here is cover the basics using terminology that should already be familiar to a Win32 RAD developer.

As with many development environments, the two most critical components in the Mac development equation are the programming language and the class library/libraries; we'll look briefly at these first.

Objective-C

Having bought out NeXT, Apple ended up with the OpenStep development system, hence the emphasis on Objective-C. For those who haven't used Obj-C before, it's basically a superset of C with object-oriented extensions. The syntax of the OOP extensions is rather esoteric for those unused to it. For example, to call a method taking three arguments in C++, we'd do this:

someObject->drawCircle (20.0, 27.0, 5.0);

To do a similar thing in Objective-C looks like this:

[someObject drawCircleAtX: 20.0 Y: 27.0 withRadius: 5.0];

Objective-C developers prefer to talk about sending a message to an object rather than calling a method. Notice that the name of the message (in this particular case, 'drawCircleAtX:Y:withRadius:') is arguably more self-explanatory than the C++ example because the meaning of each argument – preceded by a colon – is made clear; proponents claim that you end up with code that's more descriptive, but against this, you'll get much more verbose syntax.

Personally, I like Obj-C more than I did when I started using it, but in the gcc compiler the integration of Obj-C syntax leaves something to be desired. Leave off one of those all-important colons, for example, and you will get an unhelpful error message from a very confused parser. Put simply, part of the rationale behind the language syntax (aside from the language designer's fondness for Smalltalk) is to necessarily disambiguate the object-oriented extensions from the underlying C syntax. The brackets and colon symbols are compiler hints, if you will, which tell the thing whether it's looking at an Obj-C method call or a chunk of plain-vanilla C.

The whole thing is potentially more dynamic and reflective than many programming languages because, for example, an efficient mechanism exists for asking a particular object whether it handles some message before sending the message to the object.

AppKit and Foundation Kit Frameworks

Hand in hand with Obj-C go the classes that are available to an Obj-C programmer. There are two main class libraries, Foundation Kit and AppKit. In general, the Foundation Kit (usually just Foundation) implements relatively low level objects such as arrays, strings, keyed dictionaries – a very "key" (sorry) part of Cocoa programming – and the like while the higher level AppKit brings GUI-related classes such as windows and panels, buttons, and scrollbars to the party.

Both these class libraries are implemented as frameworks. In Windows-land, examples of application frameworks include the Delphi VCL, MFC, .NET WinForms, and more. In Cocoa programming, framework has a more precise technical meaning. A framework is, basically, a directory which contains a shared library (like a DLL under Windows) as well as any resources (images, strings, sound files, etc) needed by the class library.

Importantly, the framework also contains any header files corresponding to the class libraries contained therein. This makes a framework pretty much self-contained apart from the obvious comment that it might itself depend on other frameworks. The upshot is that, when working with XCode (which we'll be looking at in Part 2) you can just drag an existing framework onto your project and XCode will immediately have access to all needed info.

Incidentally, while talking about frameworks, this would be a good point to mention "bundles". A framework is a specific type of bundle, but not all bundles are frameworks. A bundle is essentially a directory with a special suffix which causes the Finder to support the illusion that it's a single, indivisible file.

The most common type of bundle is an application bundle with a suffix of .app (Hint: try creating a new folder on your desktop, rename it to fred.app and you'll see the default application icon appear). An application bundle might contain numerous resources, support for multiple languages, and even one or more private frameworks. 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.

What Is Cocoa?

I've referred to Cocoa a few times in this introductory piece. What exactly is Cocoa? Well, opinions differ. If you check out the Wikipedia article on Cocoa (API) you'll be told that a Cocoa application is one written using the Cocoa programming environment.

Unfortunately, the article earlier contradicts itself by saying you can also use command-line tools and the gcc compiler to create a Cocoa app. The same article also suggests that Cocoa applications have a distinctive feel. I'd also disagree with this because you can get much the same distinctive feel using Carbon (the distinctive look and feel of OS X comes from the Aqua GUI which is available to Carbon and Cocoa). So what's my take?

Basically, a Cocoa application is one that makes use of the AppKit and Foundation frameworks. It's typically written in Objective-C, but could be written using any language which has bindings capable of accessing these Objective-C frameworks. It's typically created using the XCode development system but – again – you can use command-line tools if you wish.

The Carbon API, on the other hand, has been around for longer than Cocoa. Arguably, it's a lineal descendant of the original Mac toolbox APIs. Carbon is procedural, so it can be called more easily from C, Pascal, and so on. There is some debate at the moment regarding how much of Carbon is going to be ported to the 64-bit programming environment under Leopard. In this mini-series, I'm going to concentrate exclusively on Cocoa.

Next time round we'll look at XCode and Interface Builder, the primary Mac development tools. Again, I'll try to do it from the perspective of a Win32 RAD programmer. ®