Apple's iPhone to Use a Centralized Push Based Notification Architecture

Update 2: Hank Williams says iPhone Background Processing: Not Fixed But Halfway There. Excellent analysis of all the reasons you need real background processing. Hey, you can't even build an alarm clock! Hard to believe some commenters say it's not so..
Update: Josh Lowensohn of Webware tells us Why users should be scared of Apple's new notification system.

A big item on the iPhone developer iWishlist has been background processing. If you can't write an app to poll for new data in the background how will you keep your even more important non-foreground app in sync? Live from the Apple developer conference we learn the solution is a centralized push based architecture.

Here's the relevant MacRumorsLive transcript:
  • Thanking the developers for their hard work. Now talking about how the #1 request has been background support. Apple wants to solve this problem.
  • The wrong solution would be to allow for background processes -- bad for battery life and performance. Poking fun at Windows Mobile's task manager.
  • Apple has come up with a far better solution -- a push notification service available for all developers.
  • When the user quits the application, Apple will push updates from their servers to the iPhone. The developer's servers push the notifications to Apple. These updates can include badges, sounds, and custom messages. This requires just one persistent connection and is extremely scalable.
  • Apple has come up with a far better solution -- a push notification service available for all developers.

    A poll based architecture is good when system capabilities are relatively symmetric. Clearly mobile phones are restricted along a number of dimensions, the most important being battery power. Having a large number of apps constantly polling for updates sucks down battery power faster than vampires at phlebotomist convention.

    So Apple's logic is sound. Keep a single connection over which data is pushed and work on the phone is minimized. You also maximize battery life and maximize bandwidth usage because data can be aggregated on the server side and be sent in large chunks rather than a random distribution of small packets.

    The mechanics of how this works isn't clear. Must all apps needing to push data to a phone become part of Apple's private iPhone cloud? Smart for Apple as it gives them complete control. For sculptors of the ultimate user experience you want total control. Not so good for developers as it's just another garden with a very high wall protecting it.