Leopards and development platform strategies

As any self-respecting geeks already knows (well, at least those who a) use Macs or b) keep up to date on technology news), Leopard, a.k.a. Mac OS X 10.5, the latest update to Apple's Mac OS operating system, was released this past weekend, and appears to have done quite well. Two million copies were sold over the weekend. Just for perspective, if the average purchase price is around $135.00 (Apple charges $129 for a single user license, and $199 for a five-user license, so assuming only a small fraction bought the $199 bundle), that adds up to a cool $270 million in one weekend. Quite a tidy sum in return for sale of strings of 1s and 0s, and sure to make Richard Stallman scowl his disapproval of a successful business model with which he so strongly disapproves.

Leopard has some interesting features, and as I am not a regular Apple user (I do work for Microsoft, after all), I am not a good source for information on them. For that, check out this amazingly detailed review on Ars Technica. John Siracusa clearly has a lot of enthusiasm for the product he is reviewing, and it shows in the quality of his work.

I am, however, a developer, and most of my current investigation into the Apple universe has centered around the APIs. That's why this bit, buried as it was at the end of the section titled "Internals grab bag," jumped out at me.

Objective-C, the flagship development language / runtime for Apple computers (and the language through which all Apple APIs are exposed), has reached version 2.0 with the release of Leopard.

I'd always wondered why Apple insisted on using a language that was somewhat at right-angles to the rest of the development world. The Objective-C runtime is open source, but its use is, for the most part, exclusive to Apple (de facto, not by any kind of licensing restrictions). If Apple wanted to attract more developers to its platform, why would they insist on a less common development language?

Mr. Siracusa points out in his article that Apple's "ownership" of Objective-C is, in many ways, like Microsoft's ownership of C#. The Objective-C runtime is open source, and C# is an ISO standard. Even so, though it is possible for third-party implementations to be created for and used on other platforms (Novell has a cross-platform C# compiler as part of Mono, and others exist as well), it's clear that the lion's share of development work in Objective-C and C# will be for Apple and Windows, respectively. The fact that Apple and Microsoft have a disproportionate influence into the language, however, means they can evolve the languages in directions of interest to them. The new LINQ extensions released as part of C# 3.0 are examples.

After pondering things a bit, it occurred to me that the fact that Apple concentrates its development energies on Objective-C isn't such a problem. I know LOTS of programming languages, which is common for developers, and the "C" in "Objective-C" implies the syntax won't be completely martian were I to spend any time using it. The bigger issue is that Objective-C is, at heart, a wrapper around the C language, and that means it is a language designed to be compiled to a native binary.

That makes the comparison between C# and Objective-C a bit like comparing Apples and Anteaters. In the former case, you have a language-agnostic runtime that enables components written in one language to be used by another seamlessly while providing stacks of runtime services that makes development easier. On the other, you have a native development language that leaves you lots of rope to hang yourself but, if done properly, can result in tight, high-performance code. Lamenting that Objective-C doesn't have the same kind of runtime features as C# is like complaining that fish don't run marathons.

But that's what I found so interesting about news of Objective-C version 2.0. On top of support for common managed runtime things like reflection, they've added garbage collection and support for Properties. There might be more, but probably not too much more, as Apple (according to Siracusa) emphasized that they are "not focused on revolutionary changes to your development world to achieve the next generation development environment." Quoting Siracusa:

That's all well and good, but then what is going to bring that "next generation development environment"?

I've been flipping out about this for years now, and the pressure just keeps mounting. What's Apple's plan to transition to a dynamic, fully memory-managed development environment? I did a three-part blog series on the topic (1, 2, 3) back in 2005 with the intentionally provocative title, "Avoiding Copland 2010." (The year 2010 is actually probably a few years before the crisis point.) In it, I pooh-poohed Objective-C with garbage collection as an unsuitable long-term solution. It appears that Apple agrees with me, but that still leaves the problem unsolved.

The takeaway here is that Apple is trying to turn itself into a better developer platform. That makes sense, as they already made the wise choice to move their device efforts to a common Mac OS X base, creating cross-device consistency in development environment as a natural byproduct (and most important, creating consistency with desktop Mac development). The next step needs to be creating a more modern development platform, one that doesn't have all the tripwires and landmines of native development.

Feel free to disagree (though it would appear Siracusa doesn't), but this is one area that Microsoft is ahead of Apple. Apple has great user interface and hardware design skills, and are clearly ahead of Microsoft in this area. Microsoft, in contrast, is far ahead from a platform standpoint, leveraging its managed .NET runtime to create whole new ways to create desktop applications (e.g. WPF/Avalon with integrated support for 3D graphics and animations that are laid out in XML (XAML), as an example). Though WPF development is not as common now, expect that to change, particularly with the release of the next version of Visual Studio (code named: Orcas).

This makes for an interesting competitive counterpoint. I clearly prefer the Windows platform. That doesn't mean, however, that I don't appreciate Apple products, nor begrudge their success. Not only am I more inclined to try out Apple products, but it makes Windows (my current preference) better as Microsoft must rise to the challenge posed by Apple's design skills even as they continue their lead in development platforms.