Why Apple's iPhone is like a 1981 IBM PC

The iPhone: what is it good for?

When the iPhone was launched, it was a consumer device with very limited potential for third-party developers. Then there was either a change of heart or the delicate evolution of a secret master plan, and Apple unveiled a proper software-development environment — and started to talk about proper enterprise capabilities. Proper in all but one sense. While application designers are free to do almost anything they like, they can't create background tasks: software either runs on the screen or it doesn't run at all.

That's a limitation nobody's had to contend with for a couple of decades and one that's particularly keenly felt in a phone. After all, smartphones practically have to do lots of things at once, by definition. They play music and pick up calls. They browse the web and they run IM. They have calendars and they sync your email.

But not with an iPhone, or at least not unless you're using Apple's own software.

There are good arguments for this limitation, say Apple's defenders: you don't want hundreds of independent apps firing off network and phone requests willy-nilly — the battery would be dead in no time; other system resources, such as memory and CPU, are also limited — giving the user the chance to load too many items at once is a recipe for a terrible experience; there's no way for a user to safely interact with lots of programs going off in their own time, given the limitations of the iPhone's user interface; or perhaps it's that, with every new combination of resident programs, it becomes harder to test for unwanted interactions and other potential causes of unreliability; the iPhone is more like an iPod than a computer — it is an information appliance. Users and developers have to be educated to accept this.

These are good arguments. They're also wrong.

Let's deal with unwanted interactions between applications. Long-term survivors of IT will remember the nightmare days of MS-DOS, with battling terminate-and-stay-resident programs, conflicting expanded and extended memory managers, all layered on top of an medieval operating system with the manners and style of a hungover syphilitic warthog. The result was a fabulously unstable computing environment that took a lot of time and expertise to keep alive. Nobody wants that for the iPhone.

Read this

Apple's Leopard lasts '30 seconds' in hack contest

Security firm Independent Security Evaluators exploited a Safari flaw to compromise the OS, with Vista and Ubuntu remaining secure...

Read more

But this isn't 1981 — it's 2008. Modern processors have memory-management hardware. Modern operating systems, especially those which, like OS X, sit at the end of decades of continual development, are robust. We know how to shield applications from each other.

Then there's the resource crunch. It's true that the iPhone has a mere 128MB of RAM and likes to keep its processor slow; it isn't a top-of-the-range desktop monster. But it isn't an information appliance either; that's what simple phones are for. Again, at this point in the history of software development, we know how to put a lot of functionality into a small space.

Users have reasonable expectations and know that, if you pile in too many programs at once, then things won't work. That's something which can be underlined by disciplined reporting of program requirements and a modicum of...