Apple Push Notification Service: Bad news for indie devs?

Posted on Jun 10, 2008 in iPhone, Opinions

So Apple took the wraps off of the iPhone 3G and the latest 2.0 firmware yesterday. But what I  found particularly interesting was Scott Forstall’s brief explanation of how Apple is going to tackle the issue of background applications.

Basically Apple will rely on a data connection to their “Push Notification” servers to send messages to 3rd party applications with information that would normally be displayed by an app running in the background. For example: If you were to receive a new chat message whilst your IM client isn’t running, the IM service servers would notify Apple’s Push Notification servers, which would in turn send a message to the iPhone to add a “1” icon to your IM apps home screen icon.

All about the Customer

This solution is elegant in two ways:

  1. It solves the issue of background apps draining battery life and slowing down the phone without requiring any input by the user. There’s no “Task Manager”, no remembering to close apps, nothing technical at all.
  2. It cleverly takes advantage of the reason you’d want background notifications in the first place: to receive updates from something that has happened online. So you’ll need a data connection for this to work, but in places without a data connection you wouldn’t need a background notification in the first place.

So instead of having applications running on your phone that poll your IM servers for new messages, Apple is effectively offloading the processing power required to do that to “the cloud”. A server somewhere will check for new messages and once a new message has been received, you’ll be notified. For a company such as AOL, setting up that kind of server-based service should be fairly trivial.

You and whose server?

But lets consider another scenario: Imagine you’re an independent developer who has a great RSS reader that you’d like to port to the iPhone. On every other device, you’d write the app, tell it to check the users various feeds every x minutes and sell it for $10. Mission accomplished.

Apple’s model instead now requires you to set up a server that knows which feeds a particular user is subscribed to, checks those feeds every x minutes and then notifies Apple’s notification servers once a new article is published. With 10 million potential users subscribed to dozens of different feeds, the server and bandwidth costs associated with that kind of service suddenly become pretty significant. Plus those are costs that are recurring – so you either have to charge the user a much higher price for the app, or even turn your idea into a subscription service, instead of a one-time license purchase (assuming the AppStore even supports subscriptions).

Consequences

I believe the Push Notification Service will mean that those sorts of Apps will be left to “larger players” such as Google, Yahoo and perhaps larger software developers such as Newsgator, who already offer similar web-based services. Indie devs will not want to deal with the extra hassle of running a server application and worrying about all the associated costs of keeping the service running.

Instead indie devs will either choose to simply make their apps “active-only”, meaning you’ll only receive updates when you decide to launch the app and check for them, or they’ll focus on apps that don’t require notifications at all.

On a side note: the technical limitations of this service also means apps such as mobileScrobbler that can send details about your recently listened tracks to the Last.FM service as you play them or stream music in the background whilst you check your email will probably not be feasible in their current form at all.

Overall

The advantages of this approach outweigh the drawbacks, but it’s clear that this solution does have at least a few drawbacks.