On the Failure of Push Notifications
As a paid member of the iPhone developer program, I was invited to beta test push notifications using a beta of AIM. After spending a few hours last night with push notifications turned on, I quickly realized that Apple’s implementation of push notifications needs some work before it comes close to both Google’s and Palm’s offerings.
Apple introduced push notifications as an answer to the complaints that the iPhone OS doesn’t allow apps to run in the background. The APNS (Apple Push Notification Service) works by having the iPhone maintain a connection to Apple servers. Developers can send messages consisting of text, badge icon numbers and/or sounds to Apple’s servers, which are then relayed to the phone. When a phone receives a push notification that includes text, an alert (similiar to an SMS alert) is presented to the user with options to close the alert or view the message. If the user chooses to view the message, an application is launched and it handles the message.
Apple hopes that push notifications serve as an alternative to background apps, which decrease battery life, complicate the user experience and can affect performance. In reality, push notifications fail as a solution when the iPhone is disconnected from the internet and when applications need to access data from the device, namely media players and GPS applications.
The first case is the most disconcerting because it removes push notification functionality from all applications, even for those which the solution is appropriate. This is especially detrimental for applications such as to-do applications who wish to remind users when a task is due that might utilize APNS as a workaround for the lack of a calendar API. These applications might appear to not need access to the internet, but Apple’s solution requires it in order to get full functionality.
The second class of applications have the most pressing need for the ability to run in the background, and push notifications do absolutely nothing to address their needs. For example, push notifications do nothing to allow users to listen to Pandora while playing a game, surfing the web or composing an email.
Further, Apple’s implementation of push notifications is so simple it borders on detracting. Here is how I spent the first few minutes with the AIM beta:
- Incoming IM
- Push “View”
- AIM opens, takes 20 seconds to log in
- Respond to IM
- Quit AIM
- Return to Tweetie/Flight Control/etc, takes 5-10 seconds to load
- Incoming IM (ignored)
- Incoming IM (ignored)
- Incoming IM
- Push “View”
- AIM opens, takes 20 seconds to log in
- Respond to IM
- Quit AIM
- Return to Tweetie/Flight Control/etc, takes 5-10 seconds to load
- Incoming IM
- Push “View”
- Respond to IM
- Sign out of AIM and disable push notifications
For each notification, I lose 30 seconds if I choose to respond, and since the notification is modal, I am forced to interact with the alert even if I want to ignore it. Compared this to Android and webOS, where notifications are unobtrusive and can be dealt with at the user’s convenience.
After spending just a few minutes with push notifications, it is apparent that Apple’s implementation is not only too limited, but it actually detracts from the user experience. The APNS also doesn’t address the entire class of applications that require background processing, the main reason Apple developed the service. This new system only serves as a shiny thing to distract us for a few months until the shine wears off and we’re all back to complaining about the continuing inability to run background applications.