Apple's iPhone is renowned for being the sole mobile platform that runs only one application at a time. If you want to write an instant messaging client for iPhone, knock yourself out, but recipients will be reachable only while your IM software has control of the screen. As soon as an iPhone user presses Home, the running application quits, voluntarily or otherwise. It's not allowed to leave so much as a thread behind to listen for connections from the network, do periodic GPS logging, or run anything else in the background. Its competitors, such as the Palm Pre and RIM BlackBerry, have no such limitation.
Apple's not likely to give ground on background apps, but it does realize the competitive and functional gap that its one-app-at-a-time policy creates. So the iPhone 3.0 OS offers the APNS (Apple Push Notification Service) to provide a workaround. Is it a limited workaround or enough of a bridge to overcome the multitasking advantage of its competitors?
[ Should you buy an iPhone 3G S or just upgrade to the iPhone 3.0 OS? | See who wins InfoWorld's mobiie deathmatch: BlackBerry or iPhone. ]
APNS does run in the background and listens for communications from a single server, and vendors or organizations are free to use APNS as a gateway to deliver short alerts and data messages to individual iPhones. Google, Yahoo, and AOL still can't run background tasks on your iPhone, but as long as they link to APNS, they can push chat invitations that pop up on the invitee's iPhone no matter what he's running. If the user taps Accept, the IM client launches and the session begins.
IM is neither the only nor the best usage scenario for APNS. Most users will experience it in a familiar way: A small badge that appears on an app's icon, such as the familiar unread-message counter in the iPhone's Mail app or the new new-invitation counter in its Calendar app. (The user has to see the Home page in which the app resides to see such indicators, however, which means leaving whatever app you may be in and seeing if other apps have any new notifications.)
If the app is running, it gets the notification immediately. If the app isn't running, the notification is held in the phone to be consumed at the app's next launch. If the iPhone is offline when the sender attempts delivery, APNS attempts to send the notification for 28 days. (The notification itself is a small [256-byte], arbitrary encrypted payload sent from a server-side app to a specific application running on a specific iPhone. So APNS is a general mechanism for shooting structured data to iPhone applications.)
Only the Chosen May Pass through APNS
Safety is paramount in Apple's approach to APNS. The service and the client API guard against misuse. The sender is validated using keys issued to registered iPhone Developer Program participants, and the API ensures that only the specifically targeted application can unpack the message data. Opportunities for abuse are quite limited because cooperation of the user -- only a user can launch an iPhone application -- and sender identity that's beyond repudiation are prerequisites for getting a message through. APNS has the advantage of being extremely simple in concept, server platform-agnostic, safe, and free to use for anybody who has software listed on iPhone's App Store.
But the delivery of an APNS notification is neither guaranteed nor acknowledged, even though Apple's experience running global infrastructure makes delivery awfully likely. APNS has some qualities of RIM's fire-and-forget push infrastructure, but APNS is strictly one-way: From an external server, through APNS, to an iPhone. There is no return path for a delivery receipt or other communication from the phone.
The worst-case scenario that APNS presents is one in which some flashlight or girly pix app from App Store is a Trojan horse for notification spam. Apple has wired in an easy solution: If the iPhone user has uninstalled the application targeted by a push notification, if the App Store has withdrawn the app, or if the server generating the notification messages is sending an excess of messages, the APNS blocks the sender. In the case of uninstalled apps, Apple adds the targeted iPhone's device ID to a list of IDs maintained on Apple's servers. Servers are required to consult this list -- Apple recommends hourly -- to avoid tying up the APNS servers with undeliverable notifications.
APNS Is Not a Substitute for Multitasking
APNS isn't a substitute for other platforms' background processes or remote execution capabilities, but with cooperative users who launch apps when notifications appear, many custom mobile applications and services that rely on background tasks can now be ported to the iPhone. Apple gets to stick to its guns and still give customers and developers some of what they want.
APNS does have one major flaw: It is strictly one-way. It's impossible for a sender to know whether a message has been delivered to the device until the recipient drops what he's doing to launch the targeted application (which must then acknowledge receipt manually). There is no way to determine even whether a given iPhone is present on a network.
But for active users who want to be reachable at a moment's notice, APNS fits the bill without breaking the platform.
This story, "The Limits of Apple's Push Notification for the iPhone" was originally published by InfoWorld.