The Hidden Costs of Apple's Push Notification Service
By 
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.
Summary
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.
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.
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!
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.
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.
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.
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.
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. 😉
@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.
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.
@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?
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.
@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.
@Ryan, word. Just adding my voice to the lash-back 😉 Thanks for the great article!
Thanks, Billy – and a deserved lash-back it is!
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?
Hi Kishore,
An app like this could initiate communication up to the server when it’s running, but otherwise you’re SOL.
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?
> 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????
> 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.
On the other hand, I made a typo spelling my own name.
If you’re a Java server developper, javapns is there to help you create payloads and send notifications.
One solution to this problem is to have someone host your push notifications for you… You can check out https://appnotify.com/ 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.
just check http://www.ns4app.com
It is an Apple Puch Notification Server integration tool with fast sending engine.