Some thoughts on Apple's Push Notification Service

Last month, at WWDC Steve Jobs announced iPhone 3G. Very cool. I think the iPhone is a game changer. Enough people have dissected the iPhone 3G that I'll skip re-stating what everyone knows already.

One of the more interesting announcements Jobs made at the WWDC Keynote was the iPhone Push Notification Service. In short, it's a single channel from the cloud to each iPhone, and can be used by software publishers (in addition to Apple) to send signals to apps on the iPhone without having to worry about creating their own custom channel to the cloud or using polling schemes. This sounds like a win-win for both publishers of iPhone apps and for Apple.

Given that I work in a similar space, this was interesting to me. We had been thinking along similar lines and have in some ways even taken the concept even beyond what Apple announced. I'll save the details/designs of what I'm working on for another post.

The technology Apple touted sounds a lot like Exchange Direct Push/Always-Up-To-Date, except that it opens up the channel from cloud->phone to third parties instead of the exchange model where the only publisher is Exchange and the only consumer is the Outlook Mobile client.

The design challenges of opening up a channel of this sort to third parties are:
1) Delegated authentication to allow third parties to use their notification channel
2) Routing notifications to the correct iPhone
3) Introduction of a single point of failure for most apps on all iPhones (kinda similar to AT&T going down - if Apple's service goes down all cloud-dependent apps are 'bricked' unless they have some form of background polling, which would defeat the purpose of the single notification channel since Apple touted battery life as their primary motivation. BTW, I don’t believe that is their primary motivation – more below).

One interesting feature they did not talk about, and I believe that they won’t add anytime soon, is a 2-way communication channel to allow for messages from the phone to the publisher. The notification channel is likely 2 way inherently, but communication from the phone is only ever seen by Apple.

Here are my guesses on how they deal with the above three:

There is only one way to get apps on the iPhone (assume non jail-broken iPhones) – the Apple App Store. To publish to the store, publishers share revenue with Apple. I’m certain there is some kind of certification that happens at this stage to ensure that apps are well behaved. Once certified, the publisher probably gets a ‘security token’ to communicate with Apple’s Notification Service if they want to use it. Further, my guess is that each app published by each publisher might have a unique security token. I presume that the content of Notification that publishers push through the channel would be encrypted and opaque to Apple – it would be very bad if that’s not the case. However, at least 2 pieces of information must be known to Apple – who is publishing and whom is the Notification going to.


My guess is that Apple is told what phone to send a notification to by publishers, versus figuring out itself where to route the Notification. In other words, the subscription is held by the publisher and not by Apple. The reasons I think this is how it must be is:
- Apple would not like to be responsible for tracking subscriptions of each app on each iPhone. It would mean they have a ton of subscriptions to manage, plus they need to perform lookups in their cloud for routing notifications to the right phone. By letting publishers deal with this, they are no longer responsible for the costs incurred of maintaining these subscriptions. Apps that create several hundred subscriptions cost the publisher, and the cost of performing lookups are also incurred by the publisher. This makes Apple's SLA much simpler.
- Publishers (I hope) would not want Apple knowing data about their customers.

#3 is interesting – the service needs to be robust again badly behaved publishers. Their first line of defense here is probably their certification program. Apps must not do wild-card broadcasting, must not poll, must have an upper limit on Notification payload sizes, etc. Note that the announcement yesterday was only to allow 3rd parties to support 3 types of Notifications – ‘badges’, ‘audio alerts’ and ‘text alerts’. By nature, the first two should be tiny in size, the third probably has an upper limit on size of text. Their second line of defense is probably real time metering and throttling. Apps must be self metered or will be throttled by Apple. Publishers are motivated to adhere by these guidelines because Apple controls publishing their app and could impose restrictions on downloads of the app in the App Store.

Regarding Apple’s stated motivation for the Notification Service – I suspect they have more interests than just “preserving battery life”. By controlling the App Store and this Notification channel, Apple now has direct insight into a ton of data that can be mined – what apps are most popular, what apps are most chatty, what app is the ‘flavor of the month’ by usage and not just by download metrics, most active users, etc. They can use this data both ways – to make special licensing deals with specific app makers they detect are 'hot' and create popular apps (popular download is different from popular usage) and also to directly target ads/other apps to consumers.

Other's have posted on how Apple might be building something similar for the Mac. They probably are, but the motivation for publishers to use such a channel is greatly lesser in case of Macs. There is no single channel of publishing apps for the Mac, although they do make it easier. As a publisher, the primary attraction of using something like this would be to not have to build something yourself, but I think the need to share revenue with Apple, get certified and distributed via official Apple channels only and use Apple as the middle-man for what essentially shouldn't be any of their business might act as deterrents.