Tech —

Copland 2010 revisited: Apple’s language and API future

How future-proof is Apple's development platform? In 2005, Cocoa and …

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they're currently working at is exactly the right one for the task at hand.

Things are more like they are now than they have ever been

Oh, I know what you're thinking. You there, you Cocoa developer—you think I'm off my rocker. Cocoa and Objective-C are Apple's biggest strength, you say, not a ticking technology time bomb! Furthermore, despite its C heritage, it's unfair to characterize Apple's implementation of Objective-C as "low-level" when it offers dynamic capabilities and language features that even the mighty Java still lacks. And hey, don't forget about garbage collection. That'll surely come to iOS eventually.

Anyway, you argue, all of this is besides the point. The proof is in the pudding. Who's making better applications? Who's providing the best user experience? Who's making more money? Not only are the supposed technical weaknesses in Apple's desktop and mobile platforms obviously not deal-breakers, they don't seem to be having any effect at all!

And so continues one of the biggest constants in software development: the unerring sense among developers that the level of abstraction they're currently working at is exactly the right one for the task at hand. Anything lower-level is seen as barbaric, and anything higher-level is a bloated, slow waste of resources. This remains true even as the overall level of abstraction across the industry marches ever higher.

First the C guys can't imagine writing in assembly anymore, but C++'s vtable dispatch is still just too slow to consider. Then the C++ guys look back with chagrin at the bad-old-days of rolling their own half-assed object systems in C, but Java is dismissed as a ridiculous pig. Still later, the Java guys sneer at pointers and manual memory management, but JavaScript is ridiculed as a toy "scripting" language for validating web forms. And on and on.

And in the short term, in the moment, they're often right. But this arrow points only one way, and that's in the direction of ever-higher abstraction. To judge how much time remains before the next leap forwards, look at the leading edge of the industry. Apple may seem to have bought itself some time with its newfound mobile focus, but given the state of the competition, that may just be wishful thinking.

Trading up is hard to do

Despite the lack of a 2010 crisis, Apple will eventually need to address this issue. The reason I was thinking about it five years ago is the same reason I'm even more concerned about it now: development platforms are hard to change. First there are the technical issues of selecting or developing a new language and creating a new API for it. Great APIs take years to develop and mature. Just look at Cocoa for a good example.

Unfortunately, you can't just port your existing API to the new, higher-level language and runtime and expect it to be pleasing. One of the biggest benefits of moving to a higher-level language is the elimination of the most awkward and warty conventions, concepts, and entities from your previous API. A framework with methods like this:

A new API that's a better match for the new language is definitely needed. But that's a piece of cake compared to the next problem: getting developers to move over to the new language and API while maintaining your platform's momentum. Even assuming you make great technical choices and all of your developers are willing and able to come along with you, these kinds of transitions take time and energy on both sides of the vendor/developer divide. Meanwhile, competitors whose current platforms are farther from the end of their useful lifetimes are not yet burdened by the need to transition and can make gains against you while you toil.

It's probably hard to be as panicked as I am about this issue if you're just a regular end-user. And if you're a developer, as discussed earlier, you may be predisposed to dismiss me outright. All of that's okay. I'm sure a lot of my concern is an overreaction caused by having lived through the actual Copland crisis in the 1990s, and watching Apple almost die because of it.

But that Apple is long gone, clearly. Technical issues like this, no matter how daunting, can only lead to a crisis if they're either incompetently addressed or ignored completely. In the past decade or so, when Apple has chosen to tackle a problem, it's done a pretty damned good job. So things are looking up in that department. But the outlook on the second possibility is not so rosy.

The largest single collection of people who know and love Objective-C and Cocoa is at Apple, and these same people are perhaps not the most likely to aggressively push for a new language and API. Add to that Apple's tendency—as evidenced by its App Store policies—to charge ahead with what it believes is the best course of action, despite outside opinions to the contrary, and you have some strong forces pushing Apple away from thinking seriously about this issue.

As incompetent as Microsoft has been at putting together coherent product offerings in recent years, it deserves full credit for having the foresight and will to address its deepest technical issues head on. Microsoft avoided a Copland-like crisis by starting its modern OS initiative years before even Apple's first such attempt, developing Windows NT and polishing it over several releases before moving its technology over to its consumer OS.

And even when Microsoft was a bit late, like when Java burst onto the scene and Microsoft was still firmly in the C++ camp, it very quickly applied considerable brains and funds to ramp up its .NET virtual machine and C# language efforts to fill the gap. Less technologically confident companies might have taken a different tack, instead arguing that their current language and API actually has important advantages over the newcomer and that there's nothing they need to do to remain competitive. In other words, "ignore it and it'll go away."

Which of these scenarios reminds you most of what you know of Apple's attitude towards Objective-C and Cocoa?

Reality check, part two

Once again, let me anticipate your likely reaction. "Don't try to frighten us with your technological worries. Microsoft's sad devotion to its modern, multi-language runtime has not helped it conjure up some decent mobile market share, or given it clairvoyance enough to dominate any product category outside its core Windows/Office strengths." All of this is true. Successfully addressing a technical issue like this is not a guarantee of success, nor is being a bit behind in this area a death sentence.

And then there's the problem alluded to at the end of the last section; what do any of us outside Apple really know about its "attitude towards" Objective-C and Cocoa and its future plans in this area? Shortly after I published the original Copland 2010 series of articles, details about Apple's involvement in the LLVM project started to surface. Is Apple's work on LLVM, and now, Clang part of a longer-term strategy for evolving its platform? Well, it certainly doesn't hurt, but there has to be a lot more to it than that. And maybe there is; we just don't know.

I have a hard time even imagining what Apple will do about this. If I had a concrete solution, believe me, I'd be pushing it. But all I've got so far is a pretty good idea of what Apple is using as its hedge against its aging platform technology…

Then you will know the web, and the web shall set you free

Apple can't use another platform vendor's API without ceding control of its destiny to an outside entity. Apple would also probably prefer not to hitch its star to a programming language predominantly driven, if not outright controlled, by a competitor. That leaves two options: either do it all in-house or find a "vendorless" solution not controlled by any single party.

So far, Apple appears to be going with the latter by investing heavily in web-based technologies. Ah yes, the web, the undisputed king of vendorless platforms! Apple's got WebKit, of course, its triumphant (in the mobile space, anyway) entry into the browser engine wars and the vehicle through which it's advancing web standards (albeit sometimes doing it wrong). Then there's Apple's use of the SproutCore HTML5 application framework in some of its more recent web applications, plus PastryKit, one of several in-house web framework experiments that Apple has deployed publicly.

The use of web technologies neatly solves many of Apple's potential problems. Instead of having to come up with a world-beating language and API on its own, Apple's got the entire industry working towards a solution on its behalf. The web is not controlled by any single competitor, and Apple arguably exerts as much influence on it as any other technology company.

Unfortunately, that means it's not controlled by Apple, either. Furthermore, web technologies have a long, long way to go to catch up with the state of the art in traditional GUI application development environments. Most experienced Cocoa developers are very aware of this, and view any alternative based on web technologies with…some trepidation, let's say.

All of this is why I think web technologies are just Apple's hedge—its (distant) second choice. But I'd feel a lot better if I knew what its first choice was.

Taking my lumps

My obsessive fretting notwithstanding, Copland 2010 has not come to pass. Despite this, I (obviously) feel the issue is not going away, and is only getting more pressing with time. Of course, as the person who was already freaking out about this five years ago, my definition of "more pressing" may differ widely from yours.

I'm not here to sell Cocoa developers—let alone Mac OS X and iOS users—on the idea that their platform of choice is getting long in the tooth and that they should be filled with a sense of technological inferiority or impending doom, but I did want to revisit this issue. I've been writing about Apple long enough to have caught up with some of my long-term predictions, and I want to hold myself accountable. I hate it when technology pundits conveniently forget about their dire warnings from previous years.

I'm also trying to help Apple, either directly through Apple decision-makers that may read what I've written, or indirectly by encouraging developers to at least think about this issue, even if their conclusions don't match my own. I'm trying to help by gently reminding interested parties, Apple included, that this issue is out there, lurking.

Finally, I have to admit that I also just love a good mystery. Five years ago, I had no idea what Apple's future language and API plans were, and today I still don't. In a world where almost all of our longstanding fantasies have now actually come true—we've got our new OS, our Apple phone, our mythical tablet—the language/API successor question stubbornly remains. I've wisely chosen not to put a new deadline year in the title this time around, but rest assured, I'll be watching and waiting. I just hope I'm not the only one.

John Siracusa
John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer. Emailsiracusa@arstechnica.com//Twitter@siracusa