We asked Apple for background processes
Several months ago I wrote a fairly popular article on why the iPhone needed background processes. The gist of my argument in that piece is that background processes are needed for three things. To allow applications:
- to be notified about things happening in the outside world, such as notifications of inbound instant messages or email.
- to notify the user about things happening locally. An example might be an alarm clock.
- to broadcast information about the users current situation to the outside world such as his/her location or presence.
They heard us… kinda
And so, it appears that, at least to some extent, the rallying cry worked. Apple announced a new mechanism for receiving background notifications. We (meaning all of us, not the “royal we”) did make a difference.
Specifically, since the solution will not be available until September, I must assume that this feature is a late addition in response to the noise over this issue since March when Apple initially announced the SDK. To see Apple responding directly and quickly to market requests is indeed refreshing.
Unfortunately, Apple’s response does not go far enough, though this first stab at the problem is compelling. Apple has fully solved the first problem in the above list, which is being notified about external events, including things like inbound messages.
The way it works is that application developers will be able to send messages from their web servers to Apple servers. In turn, Apple’s web servers can directly push notifications to iPhones. Apple’s stated design goal here was to skirt the need for developer accessible background processes by implementing their own single background notification process that all developers can effectively share.
This is indeed a great solution for notification. Unfortunately it does not eliminate the need for additional developer accessible background services.
We still need other background services
Apple’s new solution resolves the first of the three above points. You can now build an instant messaging client for the iPhone. Unfortunately, you still can’t do things like:
- build an alarm clock.
- write an app to broadcast your mobile location, unless you stay exclusively in that application. So no taking phone calls and no letting your phone go to sleep.
- write code that *responds* to notifications. All the new notifications do is send a message to the user. They can’t trigger code execution.
As I explained in the last article, these are important functionalities for really delivering on the full potential of the phone as a developer platform. I am particularly excited about the idea of my mobile phone being able to detect information about the world around me, and notifying me of relevant things in my environment. With the new GPS functionality I’d also like to be able to track my whereabouts. Where did I go today? How long did I stay? I believe this kind of almost “agent-like” functionality is a hugely compelling application class that is not being enabled by the current application model, but should be.
Mobile Me reminds us of a fourth reason background functionality is key
Interestingly, beyond the application categories I had considered in my last article on this subject, Apple’s introduction of Mobile Me is a vivid additional demonstration of the need for background processing. Mobile Me is a cloud based system that among other things, allows contacts, email, and calendar information to be synced to your iPhone in the background.
Mobile Me looks great, but I wonder why I as an application developer am not being given the tools to write such an application. Of course I have not seen how it actually works, but presuming that it really does sync in the background, I am left wanting to ask Mr. Jobs why I can’t do that too.
Apple’s “background apps take too much power” argument
In Apple’s defense, their argument is that background applications take too much power and add too much complexity. Yesterday they held up Windows Mobile as the straw man for why you don’t want background processing.
But of course we all know that because something has already been done a bad way doesn’t mean there isn’t a good way to do it. So I accept the argument that in considering these options, complexity and power consumption are critical considerations. But I reject the notion that they cannot be addressed.
As I see it, the solution to this problem is a special *very* slow task manager specifically for background tasks. The idea is that applications can register to run background tasks on some periodic but very infrequent basis. They would be allowed to execute a very small number of instructions, and they would be set to run at most every few minutes. In this way, it would be possible to do some very quick processing at very long intervals. By making the background processing very lightweight, no Windows style task management would be needed, and worries about battery power would be essentially eliminated.
Additional functionality could be tied into the GPS and the new notification system to allow background code to be triggered to do specific things when, for example, the user’s location changes, or some external event happens. This would allow for applications to do things like respond in the background to user movement.
The bottom line is that I do like the idea of specialized services to handle background needs in ways that are battery friendly. Hopefully the new notification system is the first in a series of such services that can truly take mobile platforms to the next level.
The Awkward Marriage Of Google And Apple in Mobile
We Have The iPhone Because Steve Jobs Has Big Brass Balls
Apple Says: We Weren't Lying, AIM *will* Be A Turd
The Anti-iPhone: Google's Android
Apple's iPhone SDK Inhibits Real Mobile Innovation
The iPhone Doesn't Suck - duh