Development Platform
I’m afraid I have a confession to make. A couple of weeks ago, I purchased an iPhone. And to make matters worse, I’m wonderfully happy with it.
Now, I know that I should have got something more compatible with the community that I’m a member of. Maybe one of those OpenMoko powered Neo FreeRunner devices or even an Ubuntu Mobile powered prototype device.
But an iPhone it was. Why?
Well, frankly I needed something that works today.
The iPhone is a fascinating device. Don’t worry, I’m not going to go on about its features and all of its bling. What fascinates me is how easily Apple brought it to market, and now that the App Store is up and running, how quickly native applications are being written for it.
The most breath-taking thing is that this device is effectively running a version of Mac OS X ported to the ARM processor, and with any unnecessary bits for the smaller platform removed. The graphics, audio and other core libraries are basically the same as on the bigger brother computers.
In other words, Apple have done what Linux always promised; turned Darwin into a truly scalable platform.
What’s more, the pace at which new applications have been developed for it shows that this platform is easy to write for. My phone has rich, native applications for Twitter, Facebook, Flickr and Google; none of which came pre-installed.
I have a theory about how they’ve managed to scale their platform so quickly down to a size that fits in my pocket whilst also running on a machine that barely fits on my desk. The same theory explains why developers have been so quick to develop applications for it.
It’s not that their platform is better, or more capable, or even necessarily more flexible.
It’s that their platform is better componentised.
The core technologies of their platform are grouped into easy to understand components. It’s easy to draw boxes that show how these stack up to provide functionality to the developers, and it’s easy to see which boxes you can remove when scaling the platform down. Documentation is easier to write too, each component has a specific function and tech writers can turn that into a story and write simple to understand overviews and rich API documentation.
Audio playback is a great example here.
In Linux, you want to play sounds from your application, so you have a quick hunt around for Linux audio APIs. Your resulting list looks something like this:
- libcanberra - “a simple abstract interface for playing event sounds”
- gnome-sound - “Sound playing routines”
- GStreamer - “Media framework”
- PulseAudio - “Sound Server”
- ESD - “Enlightened Sound Daemon”
- libasound2 - “ALSA library”
- ALSA - “Advanced Linux Sound Architecture”
And those are just the libraries and daemons installed by default, and I didn’t even include the format libraries such as libogg. If I were to include those, and the various other sound daemons, mixers and framework libraries (hello, Phonon), we’d be here all night.
Where is an application developer actually supposed to start?
Even I have no real idea where GStreamer, PulseAudio and ALSA begin and end; and where they overlap and contradict each other, which I’m supposed to use.
Apple developers have it much easier. If you want to do anything with audio, you want Core Audio.
If I were to try and do something more interesting, like putting things on the screen, a somewhat common requirement for GUI applications, I’d have to read up on Clutter, Pigment, GTK+, GDK, Cairo, Pango, FreeType, Xft and X11. At least.
An analogy can be drawn with Lego.
When I was a young kid, if I wanted to make cars to sit on the roads around my lego town, you used to have to build them from scratch. I didn’t really care about lego cars, but the town looked silly without them, so it was a chore.
The chassis for each car was the same. A 1×4 flat at each end for the bumpers, with a 2×4 end on in the middle to make the wheel arches. These were joined by a 4×4 to make the car floor. (Sadly I couldn’t find any images on Google).
You had to know how to do it, but when you did there was a certain pride in being able to build a car from memory and knowing how all the pieces fit together. If you cared about cars, anyway.
Then an amazing thing occurred. Lego released a new car, and in the box was a single piece that made the chassis. No more mucking around and searching for lost bits, or realising you’d built it upside down. Now you could instead spend more time deciding what colour the body and windows would be, or if you really didn’t care, spend more time on the houses and other buildings that were more fun to build.
If the single piece wasn’t right, nothing stopped you building your own custom chassis, but it was a great time-saver. Nowadays they probably have a box where a complete car rolls out, but that’s ok too. Those are the boxes for people who really don’t care about cars, but understand that they need them to fill the multi-storey car park. They do other boxes with a thousand pieces to build a single car for those people who like making cars. Those are neat, the engines look like they’re working and everything!
Apple’s approach is somewhat like this. Their APIs are grouped into big components that you can quickly get to grips with, and spend your time on the interesting bits of the application. Linux’s API stack is more like a box of bits, you have to know how to fit them together and build the chassis before you start.
The only people that really delight in the differences between GTK+, GDK, Cairo and X11 are the authors of those particular parts of the platforms. The rest of us really wish we just had a single piece marked “InterfaceKit” that we could use.
