iPhone, Leopard and Developer Expectations
After the keynote speech for WWDC, there is a lot of kvetching about Steve Jobs’s announcement that the only way to develop apps for the iPhone right now is as web applications, not to mention the features announced for Mac OS X 10.5 Leopard are not exciting enough and there are no exotic new Macs on display. Maybe if people concentrated more on liking what they’re given they’d feel happier in general.
Leopard will be Fun
The next version of Mac OS has new desktop---which boils down to some translucency effects and a new UI called Stacks. When I saw the icons spring gracefully out of the dock I knew I wanted Leopard, just like when I first saw the Exposé effect. The use of animation is not just pretty, it also helps you make sense of what is going on, which makes the feature easier to use. And, also like Exposé, it helps you navigate around a desktop cluttered with all those extra applications and files we couldn’t have fitted on our computer twenty years ago. Stacks also replace the much-missed pop-up windows of Mac OS 9, and the use of the Apple menu to open applications.
No-one even bothered to mention that it casually uses rotated icons and text to achieve that graceful arc.
A lot of the other things Mr Jobs was demonstrating were for sifting through your heaps of media looking for just the right photo or for that brochure you were thinking about: Quick Look, the Cover-Flow effect in Finder, extending Spotlight to searching your local network, and so on. In the keynote, he talks about Macs almost entirely in a home setting, slotting invisibly in to everyday tasks like creating home movies for Grandma or choosing your daughter’s college; he leaves discussion of professional Mac users like designers and film makers to other venues.
The really exciting thing about Leopard is the new facilities it offers developers, like Core Animation, support for easier parallelism (vital to properly exploit multi-core processors), and other things that have not been properly announced yet. And that’s how it should be: the real worth of an operating system is the programs you can run on it. And Leopard is adding enough magic for developers that many applications plan to make their next version Leopard-only, a proposition that sounds sufficiently risky that Mr Jobs made a point of mentioning that most Mac owners actually run the most recent software. This is helped by the fact that Mac OS X runs fine on quite elderly hardware, so more people buy OS X upgrades than you might think.
In some ways this makes the postponement of the release of Leopard to October seem quite sensible from the marketing point of view, surprisingly enough: if the launch is going to be accompanied by a flurry of releases of new Leopard-only software, it will make for quite a buzz, nicely filling in the gap between the June launch of the iPhone and the build-up to the December gift-buying season.
iPhone Has Not Even Started Yet
Of course this is not the same as being allowed to develop and install Cocoa applications on the iPhone, writing in Objective C++, using Core Animation, Core Data, and all that jazz, with an icon on the home page and direct access to the multi-touch gestures. But wait! what’s the API for multi-touch? Cocoa has APIs for mouse movement and tick boxes and drop-down menus, and so on—but the iPhone has none of these. With the iPhone, user interfaces are being reinvented, with very little directly carried over from conventional mouse-driven GUIs.
I don’t know how a multi-touch class library would be designed. I don’t think Apple know yet, either. By this I don’t mean to suggest they have no plans, or no idea of what they are doing; it’s just that developing simple, elegant, powerful and efficient library interfaces is hard work and takes a long time. You can’t really write a library until you have written enough applications to understand which functions can be usefully shared, and what the common abstractions are. You can’t even write the applications without creating and discarding a few prototypes first while you work out the details of how physical events will turn in to application events, and discover which gestures work well and which turn out to feel unnatural or turn out to be unsuitable in some other way. You can’t plan all this in advance of writing the software: a large part of programming is an exploration of the problem domain, and you can’t fully understand what you really need the program to do until you have got it to almost, but not quite, do it.
It seems to me that a sensible plan for the iPhone might look like this:
- iPhone plus some new applications from Apple
- iPhone plus new applications by partners working closely with Apple
- iPhone plus third-party applications that are certified by Apple.
During the first couple of iterations, Apple would be bashing away at library design, refining it and refactoring existing applications to use it, until it is ready for use by outsiders.
This isn’t just a necessity of engineering, I also think it may turn out to be good for Apple’s style of marketing: after a year to get used to iPhone, you can talk about iPhone plus X. This parallels the progressive enhancement of the iPod:
- iPod (1000 tunes in your pocket)
- iPod, but with contacts
- iPod, but for Windows too
- iPod, but with photos
- iPod, but smaller
- iPod, but with video
- iPod, but with games
The iPod with video would have been too complicated to describe all in one go. It isn’t until the public at large have absorbed the concept of the iPod that they are ready to hear about iPod plus photos. The latest iPod is less simple than the original, because it has more features; it is only the familiarity of the basic iPod package that allows them to sell the more complex version. In the same way, later iPhones will have more features, possibly including some of those features everyone has condemned it for lacking, and new features will be introduced one at a time.