The Hidden Costs of Apple’s Push Notification Service

Guest author Ryan Daigle (Profile) is the creator of the open-source Rails-to-iPhone web-services bridge ObjectiveResource and a Rails Core Contributor. He runs Y Factorial.

With iPhone OS 3.0, Push Notification is finally coming to the iPhone. Those of you with access to the iPhone OS 3.0 beta program can find the details of the push notification architecture in the Apple Push Notification Service Programming Guide (login required).

As this recent Ars Technica article points out there are a lot of implementation details that may push push notifications out of reach for most small and mid-size development shops. I’d like to expand upon the concerns listed in that article and focus specifically on the server-side (or “provider”-side in Apple’s terms) costs.

Persistent Socket Infrastructure

Messages are delivered via socket connections to Apple’s push notification gateway. In and of itself this is not that intimidating – and there is a lot of example code on the developer forums (login required) explaining how to interact with the gateway in your language of choice.

Apple’s Push Notification Service is structured very similarly to SMS gateways. With SMS gateways you have a raw binary interface to the service via long-lived/persistent socket connections. By requiring that messages from the same sender share a long-lived connection a greater level of gateway performance can be ensured and IPs that are constantly connecting and disconnecting can be identified as potential DOS attackers.

This persistent connection requirement has an implementation side effect: you have to keep your connection pool separate from the independent request/response life-cycle of your provider application. For Java or other enterprise language developers this may not be a big deal as there are already facilities available for establishing and maintaining independent resource pools. I would argue that most iPhone developers have backgrounds in lightweight server-side languages/frameworks like PHP or Ruby on Rails whose main strengths are in executing logic based upon a single http request.

Building components independent of the HTTP request/response life-cycle has implications that aren’t obvious. This turns up in the sample code in the forums where few if any examples use long-lived connections. Sure, these are proofs of concept, but at any volume they risk being classified as a DOS attack.

Administration, Maintenance and Scalability

Because of the stand-alone nature of providers’ APNS services, this represents a new component that needs to be maintained in a production environment. Unfortunately, while PHP, Rails, Python and a host of other languages have standard ways to deploy and monitor web-applications, the options for standalone components outside the web infrastructure are much more limited. Usually these components require custom deployment procedures and homebuilt monitoring tools.

Finally, there is also an implied cost to ensuring that all the independent parts of your application can scale in unison. Apple itself stated that the delay of push notification service was a result of re-architecting the service for the type of scale they saw.


While push notifications are an exciting feature in the upcoming iPhone OS release, they need to be thought of in a very different manner than the client-side application development aspects of iPhone development. There are a host of both apparent and subtle costs that come with developing and maintaining independent server-side components.

© 2008-2051 • Mobile Orchard and the Bar-Tree Logo are service marks. ContactAdvertise