Apple Push Notification Service: Why It's "Right"

Matt Patenaude

Apple Push Notification Service — hence, APNS — is a brilliant system: a unified push-style notification service for iPhone OS that allows any application to receive and act upon textual, aural, and numerical information in realtime from a server up in the cloud. It's Apple's answer to the call for the ability to run applications in the background on the iPhone and iPod Touch.

For some reason, many people are more than a little peeved about this. "It's underpowered," they cry in the streets, "it's only like having pseudo-background apps." And I can't help but agree: it really is only like having pseudo-background apps. And that was the goal; in fact, in my opinion, that's what we want.

With APNS, Apple answered a question different than that which was asked, but in my opinion, they answered the question that should have been asked. Here's why.

Asking the Right Question

In Douglas Adams's famous now-more-than-five-part trilogy The Hitchhiker's Guide to the Galaxy, Slartibartfast relates the story of the creation of the supercomputer Deep Thought, designed to calculate "the Answer to the Ultimate Question of Life, the Universe, and Everything." After 7.5 million years of calculation, Deep Thought reveals the answer to be none other than 42. It is at this point that the civilization in the story realizes that no one knows just what exactly the Ultimate Question is.

And as I write this, the Coldplay song 42 comes on unwarranted. Freaky, isn't it? Incidentally, anyone who doesn't have a copy of the awesome free album LeftRightLeftRightLeft should go get themselves one.

Developers asked for background applications, and users asked for background applications, and Apple said "here's a push notification service." It's understandable how that could annoy some people. But for a moment, let's ignore the users — a relative minority of users are fully aware of the technical aspects of what they use; they've been conditioned to understand that "background means multitasking, multitasking is good, I want that." Sure, there are plenty of technical users out there, but what really matter at the moment are the developers, so let's focus on them.

Let's take a look at the kind of applications for which developers saw a need for background processes:

Of course there are other use cases, but that list covers almost all of the major ones.

Right off the bat, let's discount responding to requests from other devices, as with a web server. I'm sorry, but that shiny brick in your pocket is a phone, not an Xserve Mini. While creating an iPhone OS web server is an intriguing novelty, and certainly fun for a few minutes, there are very few real-world applications for a server that's always changing location and availability. Any other application that needs to respond to requests from other devices should have no need to do so when the app isn't running. People asking for this capability are essentially asking the question "why can't my Porsche hover in mid-air?" The simple answer is "because it isn't a helicopter."

Now I'll get to the last item — realtime streaming media — towards the end of the article, because that's the oddball here. But for the remaining three cases, what people are really asking for is a way to keep your user informed of some state without the application being frontmost. If you ask me, that's exactly what the APNS is designed to do.

When developers cry out for the ability to run background processes, they're talking about an implementation detail. The goal of an application is never "run a thread in the background for fun," it's "do X, Y, and Z without it being a center-stage event;" how that gets accomplished is relatively irrelevant. Good developers don't work in implementation details, they work in problems and solutions. Keeping users informed is a problem; a unified notification system is a relatively viable solution to that problem.

Calls Are More Important Than You

Every software developer has a bit of an ego. We all like to think that our application is the single most important piece of software that will ever grace our users' beautiful devices, but quite frankly, that isn't the case. For the iPhone, the most important pieces of software every user will have installed are Phone.app, and Messages.app.

Yes, the iPhone is an amazing device, and yes the iPhone can do many wonderful things, but the primary purpose of an iPhone is to be a phone.

Yes, the iPod Touch also runs the iPhone OS, but let's be serious here. Even on the Touch, it's still called the iPhone OS. The iPhone is the primary target here, as it rightly should be.

The point is, at any given moment, the iPhone MUST — ie, this is non-negotiable — be ready to respond to an incoming phone call or SMS/MMS message. This requires that the device have a certain amount of CPU power and memory available at all times. Run two or three apps in the background? You'll probably be fine. But give developers the power to allow any app to run in the background, and they will take advantage of it, likely in places where it is totally unwarranted (remember, a lot of devs coming over to the iPhone used to be Windows developers… *shudder*). Considering the average iPhone user has about 501 apps installed, assume that even 30%2 of apps run background processes and you've got a relatively congested device, enough to significantly diminish performance, if not to the point of not being able to receive calls.

And let's not even try to argue "but Apple vets the apps, so it can deny apps that too aggressively use background processes!" No, Apple peruses the apps and looks for blatant violations. The App Store has been a literal explosion, and if developers ever hope to get their apps out to the public, Apple simply cannot look at each application all that closely. It makes much more sense to put at least a portion of that control with each individual user (for example, allowing users to disable notifications on a per-application basis, no harm no foul; and before anyone suggests it, disabling background processes on a per-application basis is just asking for total crash-city chaos).

The iPhone is now, and will always be, primarily a telephony device. More importantly, a telephony device manufactured by a company obsessed with user experience. Simply put, that means the iPhone will provide the optimal experience for anything phone-related, even if it's at the expense of other tertiary functions. (Yes, developers, your applications are considered tertiary functions).

1 I made this statistic up.
2 That one too.

"The Notifications Are Ugly/Jarring/Undemocratic"

Cry me a river.

People complain that the notifications delivered as a part of APNS are everything from ugly, to flow-breaking, to offensive to their great aunt twice removed. It's time to just get over it. This is not a problem with the APNS, it's actually a problem both more macro and more micro. Disruption is inherent in the concept of "Notification" in and of itself (which… yeah, so what were your background apps going to do when they received new information? That's what I thought), and the specifics are tied to the iPhone platform itself, not the delivery medium.

Again, we quibble over implementation details. The exact style and mode of notification delivery is something that Apple can unilaterally change throughout the whole device, both to improve workflow, and more importantly, maintain consistency. Already you have three options when you deliver notifications to devices, and it's a system that will continue to be refined. Whether you agree with Apple's design decisions or not, there's something to be said for consistency — it's what makes the device as a whole so easy to use. Can you imagine what using an iPhone would feel like if every application had its own, slightly different way of communicating with its users? Tower of Babel, next stop, doors will open on the right.

And What About Streaming?

Ahh, yes, streaming media. That is the one category of application that appears to have fallen through the cracks. But that doesn't mean that background processes are necessarily the solution.

We've practiced this already, so this should sound familiar: problems and solutions, not implementation details. The problem is that I want to be able to listen to Pandora (or Last.fm, or AOL Radio, or whatever) while it isn't the frontmost application. The solution has yet to be found. While it may very well encompass background applications, it by far isn't the only option: what if, for example, the device had a unified "audio" server, to which you could pass a QuickTime/RTSP address, and it would continue to stream after the application quit?3 I'm just throwing out ideas here.

3 Incidentally, this is how Tempo, a very much pre-pre-alpha app I'm working on, plays music. Works great, with minimal resources.

Conclusion

APNS does not cater to every application that demonstrated a need for some kind of background activity. However, it hits the mark beautifully for a vast majority of applications, and just because it doesn't fit quite right for one particular type of application doesn't mean that the iPhone is to be decried immediately for not allowing background applications; it's likely that Apple is already at work on a solution that will cater to these types of applications in their own special way.

Any other complaints?