The Hidden Costs of Apple's Push Notification Service

On April 16, 2009
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.

  • David J. MacKay

    I don’t disagree with the article in summary but I wouldn’t be too quick to assume that most iPhone developers are coming from lightweight PHP/RoR backgrounds. Maybe you guys can do a survey on that (or have you already?!).

    In terms of $$$ costs, you’ll need scalable hosting just like every other web app out there. It’s the price of success. It might be time to consider the new recurring billing options Apple has put in place. Obviously “free” isn’t a great business model and isn’t sustainable.

    In terms of development cost, consider using Amazon Simple Queue Service in conjunction with EC2. Send your notifications to your queue and process them using a long running process on your EC2 instance.

    Someone could even write the software to send push notifications to Apple Push Notification Service (APNS) and put it on a public Amazon AMI. Developers would simply need to make small customizations to get it running with their app.

  • Ryan Daigle

    Hey David,

    I think you bring up a good point – that iPhone developers with this type of infrastructure requirements can no longer rely on free or $0.99 apps to cover their costs.

    Regarding hosting the provider service on AWS, that’s great, but it still pulls iPhone developers into the server-side business instead of the client-side business. This may pull them in more directions than they can reasonably handle?

    Thanks for your comments!

  • Geoff Mandelson

    This is Networked Protocols and Services 101 stuff. There’s nothing of significance here at all. Building a backend with persistent connection to the push service is trivial (and very cheap). Of course you can’t do it with tools designed for solving a completely different problem: serving dynamic web content. It’s like complaining that you can’t use a hammer to screw in a screw. Sometimes you need to use nails sometimes screws.

  • Ryan Daigle

    I definitely agree, Geoff. My point is somewhat more nuanced and, perhaps, not well articulated: That most developers are used to using different tools than are required to solve this particular problem and that they need to think about this before designing their iPhone apps.

  • Adrian Hosey

    I’m less concerned with how to build my gateway, and more concerned that I need to build a gateway AT ALL. The whole push system seems to assume that all apps which want push, will already be client/server apps. But I want to make an app that only has local data, and also wants to make notices on the local device. (Think calendar.) Under the current model, I have to bring up a server, sync ALL of my customers to my server, and run a job on the server that monitors the sync’d data and sends notices to Apple, who sends them to the devices, etc… All of this to get the iPhone to generate an alert about a piece of that data that it ALREADY HAS in local storage! Not only is this silly, not only does this force the developer to carry more overhead – it also adds more potential points of failure.

  • Ryan Daigle

    Adrian – you’re absolutely right. This has the potential to become a very expensive and heavy-weight hack to masquerade as a local cron system on the iPhone.

  • Adrian Hosey

    So how about an API for applications to register notices with the device, and let a centralized cron-like daemon deliver them even when the app isn’t running? No servers, no lengthy round-trips, no background processing. This would solve MY problem, but still leaves the other issues you describe. 😉

  • Dan Grigsby

    @geoff – This may be Network Protocols and Services 101 but consider as an analogy the number of people that have their email hosting by third parties. Mail servers have been a known quantity for decades, yet people punt on the sysadmin overhead and farm it out to third parties. With Push Notifications, not only do you have to do the sysadmin, you also have to write the server in the first place.

  • Randy Becker

    I submitted a feature request to add support for Apple’s Push Notification Service to Google’s App Engine. More than a hundred people have already starred the request, making it one of the top 25 issues. Since App Engine is free for low traffic uses, and designed to scale, it could make cost-effective and scalable push notifications available to small and mid-size development shops.

  • Ryan Daigle

    @Randy, I’m not too familiar with Google App Engine limitations, but even if you’re allowed to make socket connections will it solve the fact that you need to keep a persistent connection open to APNS? I.e., if it’s python based won’t the connection open and close within each request, violating the part of the APNS docs that say you must keep the connection open or you could be flagged as a DOS attack?

  • Billy Gray

    I think the better thing to do here is to not use APNS, and maybe the brains at Apple will get the hint. I’m sure there are some great uses for this (I can’t think of any I’d be willing to go thru the work to develop), but like Adrian says above, it’s a lot of fail-prone nonsense to fill a particularly simple need. It’s really wasteful. The devices have a local scheduler.

  • Ryan Daigle

    @Billy, there does seem to be some lash-back at Apple for such a heavy-weight solution to push notifications. However, keep in mind there are legitimate uses for push notification beyond compensating for the lack of local cron, and for those cases the costs outlined in this article should still be considered.

  • Billy Gray

    @Ryan, word. Just adding my voice to the lash-back 😉 Thanks for the great article!

  • Ryan Daigle

    Thanks, Billy – and a deserved lash-back it is!

  • Kishore Seshadri

    Given this model, is there any way for an app on the handset to asynchronously initiate communication? Consider a hypothetical app (as far as I’m aware) where the current location is advertised to a coupon server that then sends you a coupon to the nearest Starbucks. Are apps like this out of the question with no support to run background tasks?

  • Ryan Daigle

    Hi Kishore,

    An app like this could initiate communication up to the server when it’s running, but otherwise you’re SOL.

  • Pingback: Urban Airship: Providing air cover for independent iPhone developers | Silicon Florist()

  • Pingback: Urban Airship: Providing air cover for independent iPhone developers | Oregon Startup Blog()

  • Pingback: Urban Airship to Provide Push and Sales Infrastructure for iPhone Developers | GroupHelp.NET - Easy everything!()

  • Pingback: Urban Airship to Provide Push and Sales Infrastructure for iPhone Developers | google android os blog()

  • Pingback: Urban Airship to Provide Push and Sales Infrastructure for iPhone Developers - Feed -

  • Pingback: TumbleTech » Urban Airship to Provide Push and Sales Infrastructure for iPhone Developers()

  • Pingback: Read Write Web | Urban Airship to Provide Push and Sales Infrastructure for iPhone Developers | Your Gadget Review()

  • foz

    This sounds like the type of thing that is ripe for 3rd-party support services… as an iPhone developer I would love to push this whole headache on to a reliable service provider, who charged based on messages or volume. But perhaps this is not possible given Apple’s terms?

  • Jill

    > details that may push push notifications out of reach for most
    > small and mid-size development

    What is “push push”????

    Why are there always so many typos in articles here????

  • Chri

    > What is “push push”????
    > Why are there always so many typos in articles here????

    That’s not a typo. He’s talking about pushing push notifications out of reach of some developers. “push push notifications” is exactly what he meant to say.

  • Chris

    On the other hand, I made a typo spelling my own name.

  • LeMac

    If you’re a Java server developper, javapns is there to help you create payloads and send notifications.

  • Pingback: AMB Album » Urban Airship to Provide Push and Sales Infrastructure for iPhone Developers()

  • Pingback: links for 2009-08-20 at adam hoyle presents suckmypixel()

  • Josh

    One solution to this problem is to have someone host your push notifications for you… You can check out which offers a new hosted Push Notification service which removes the need to host your own server and gives you complete control over your data. It should be out in a few weeks.

  • Pingback: First Look at Apple Push Notification Service - Apptivity Lab()

  • Firat

    just check
    It is an Apple Puch Notification Server integration tool with fast sending engine.