• 03.17.09

Achilles Heel of Apple iPhone 3.0: Background Application Support

Today, Apple had the opportunity to double-lap the Google Android and BlackBerry platforms. They failed.

Achilles Heel of Apple iPhone 3.0: Background Application Support

The iPhone maker has raised the bar for its competitors, to be sure, showing off a host of smart innovations to their iPhone 3.0 operating system during a sneak preview event today in California. But one crucial omission will give RIM and Google the leverage they’ll need to make their respective app stores a success: the iPhone still can’t run applications in the background of the phone.


Since the first incarnation of the iPhone, apps have worked the way they used to on the first Macintosh: you can only use the app you’re in. The Macintosh was revolutionary because it allowed you to use a computer without knowing code, but it became truly useful once Apple developed the MultiFinder in System 2: it finally let you use more than one program at once. This singular improvement turned the Macintosh from a novelty PC into a tool for power users. (That, and a cheaper price.)

The iPhone is at a similar crossroads. Look at many of iPhone 3.0’s improvements, and you see missed opportunities where background running could have made a salient difference. The new iPhone OS, for example, supports peer-to-peer Bluetooth connection for information swapping and gaming. That’s great, but what if I want to build an app that could sync the iPhone with my PC as soon as I walked into my office? I can’t; I will forever have to sync manually, since my app couldn’t run while I’m doing other things with my iPhone.

New support for subscription-based applications is equally hamstrung. Amazon, for example, just released its Kindle app for the iPhone, through which you can order magazine subscriptions. Instead of having the iPhone automatically download a new version of the New Yorker as soon as it’s ready, I have to open Kindle and wait for the download before I can read.

This also eliminates the possibility for truly powerful subscription music applications. Why would I pay a few bucks a month for a Rhapsody application, if it existed, when I can’t keep listening to music and check my email at the same time? Only Apple’s iPod app can keep music playing in the background when I do other stuff, leaving all other music apps impotent.

Turn-by-turn Google Maps directions are also now available for developers to call into their applications. That’s a notable improvement, but it would be truly signficant if it could run in the background. If I map walking directions to a new coffee shop near my house, I’d like to be able to fiddle with the iPod app while I’m walking, and let Maps interrupt me when it’s time to take a turn.

Ditto for the new potential for third-party devices. Since developers can now facilitate connections with other gizmos, you’d think that the opportunity would be ripe for apps that use, say, heart-rate montitors for running. But apps that could use measuring devices rely on uniterrupted streams of data to be useful. If someone calls you during your run, bam–you’ve exited your heart-rate app, and now your training record for the day is flawed.

Apple says that they haven’t enabled background applications because the extra strain on the processor would cut down battery life, and they’ve got a point; Windows Mobile phones are notoriously plagued by their tendency to keep every app you use open in the background, slowing things down and eating into talk time. But T-Mobile’s G1 and RIM’s BlackBerrys are capable of running several apps at once without discernable lag or lost life, and once their app stores become populated, they might see a spate of powerful apps that leave iPhone owners wanting.


What’s the solution? Like WiFi and screen brightness, multi-tasking on the iPhone should be something that individual users are allowed to tune depending on their power economy needs: we should be able to turn off multi-tasking for third party apps, or set a limit on the number of apps that can run at once. The functionality to be gained would be well worth it.

About the author

I've written about innovation, design, and technology for Fast Company since 2007. I was the co-founding editor of FastCoLabs.