Back in March, when we first learned the details behind the upcoming iPhone SDK, I wrote about Apple’s decision to not allow background applications on the iPhone. As described in Apple’s Human Interface Guidelines for iPhone developers, if the user switches a program into the background, that program must then cease running. At the time I wrote the original article, we didn’t really know why Apple made this decision; I theorized it may have to do with stability and reliability.
During Monday’s Worldwide Developer Conference keynote, though, Apple’s Scott Forstall cited two reasons for why background processes were the wrong solution—battery life and CPU usage. Too many background apps, and your phone’s battery life goes to nothing, and everything gets sluggish.
While I understand these problems in principle, I still feel the decision as to whether or not to allow a program to run in the background should be one that I’m allowed to make. Apple, however, showed a very compelling slide of a task manager on a Windows Mobile device that effectively argued why this was a bad thing to shunt off on the user’s shoulders—why should the user have to debug their phone’s slow operation or poor battery life?
At the keynote Monday, executives covered a new service for iPhone developers — due in September — called “unified push notification.” While that’s a lot of fancy words, here’s what it boils down to: Apple will provide a server (or more realistically, many servers) that act as a go-between for a developer’s server and the end user’s iPhone.
If you think about iChat, for instance, when you talk with someone, you’re really talking to a server that relays messages back and forth between your machine and your correspondent’s machine. When you’re running a chat application on your iPhone, you’ll be doing the same thing. But when you’re not running the chat program on the iPhone, the program’s developer can use the unified push notification service to send messages to your iPhone. Apple’s servers will maintain the IP connection to the iPhone on one end, and to your server on the other end.
So just what kind of messages can be sent? Apple detailed three allowed message types:
- Badges. Badges are familiar to anyone who uses OS X. You see them in the dock icons for Mail (a count of unread emails) and iChat (new chat message count), for example. On an iPhone, similar count badges already appear on Mail, and with Apple’s new service, can appear on third-party developers’ programs as well.
- Custom alert sounds. Instead of placing a badge on a program, a server can instruct the iPhone to play a custom sound. There can even be different sounds for different events. So instead of (or in addition to) a badge, your phone may just make a sound to let you know you need to check on something.
- Overlay text messages. The most eye-catching message is a floating text window that overlays whatever application happens to be running at the time. The message may also include action buttons that could, for instance, ignore the message or switch to the program that sent the message to handle it.
From Apple’s perspective, the new unified push notification service solves the problem without unduly affecting either battery life or CPU usage. From a user’s perspective, this seems like a pretty good solution to the problem in general. The user won’t have to worry about managing background tasks or take any action to get updates from programs that use the push notification service. Like the rest of the iPhone user experience, the push notification service makes things as easy for the user as possible.
Of course, there’s a downside to this ease of use. While Apple’s solution should work great for things like chat applications and the new eBay auction tool, it’s still not the same as allowing programs to run in the background. Consider a program that allows you to connect remotely to your Mac at home, for instance. Such programs exist today for jailbroken iPhones, and I believe they will exist in the App Store as well. Such a program really needs to be able to run in the background—otherwise, every time you exit that program, you’ll break the connection to the home machine (because the network link will be closed). Or a program that tracked your walking path based on GPS coordinates—it would need to be able to get a new set of coordinates every so often, even if you happened to be looking at your calendar or checking stock prices. I’m not sure if there’s a way for programs such as these to work without the ability to work in the background.
Apple, of course, will have to insure that its notification servers are always available, and that they’re responsive enough to push out whatever huge number of notification events are flowing through those servers at a given point in time. But we’re talking about the same company that keeps the iTunes Store humming in the face of much greater demands, so I’m not too worried about it. Another possible concern is privacy—how will Apple insure that the messages that flow through its servers aren’t compromised before they reach their destination? Will the notification messages be encrypted, for instance? Time will tell, but again, I would think Apple has thought about that very question in depth.
For most users, however, I think Apple has come up with a very good solution, and one that’s quite elegant. Users will get most of the benefits of a background application without any of the associated CPU usage or reduction in battery life—all without having to lift a finger, at least until they have to tap on a push notification text message.