Criticism and praise for Apple’s Push Notifications

The topic of background applications is a hot one among iPhone enthusiasts. …

The iPhone is a powerful device with a rich software platform and tremendous potential. While the inability to run applications in the background has been a much-criticized drawback, Apple is finally countering with Push Notifications in the coming iPhone OS 3.0. The feature is not a perfect solution, however; its promises and pitfalls are up for debate across the web. What follows is a point and counterpoint from two Ars writers: one is disappointed that background applications did not appear, the other is fine with living by The Push.

Apple recently announced a slew of refinements to be unleashed upon the iPhone faithful this summer. There's lots of good news in there—I keep pinching myself to make sure that copy & paste support isn't just a cruel dream. But there's also a big disappointment: the lack of background applications.

Scott Forstall explained how having applications run in the background would keep the iPhone or iPod touch from going into its lowest power sleep mode, reducing standby time for the iPhone by as much as 80 percent. I'll concede that point: if the phone must be able to receive incoming TCP/IP packets, it needs to be at least somewhat awake, and wakefulness takes power. For instant messaging applications and the like, I can go along with Apple's reasoning.

Unfortunately, going with push notifications in lieu of allowing background applications leaves other classes of applications in the cold. Those would be music streaming and GPS tracking applications. For instance, if I want to play a podcast in RSS Player (much improved in the recent version 1.3) or stream music with the Last.fm application, I can't browse the mobile web with Safari or type an SMS without interrupting the audio playback. Or, when I'm tracking my travels with one of the GPS applications, I can't hop into the iPod application to change my music without creating a gap in my GPS track.

With these types of applications, battery life isn't an issue. If I can't run the application in the background, I'm still going to run it, but in the foreground where it uses up the same amount of power, if not more. Here, the issue is one of functionality and usability. An iPhone that forces me to keep listening to the same playlist while tracking my location--or to stop listening to streamed music when sending an e-mail--is fundamentally less useful than one that allows these things to happen in the background so the device's other functionality remains available.

Apple's position makes sense for one class of applications, but its solution doesn't address another important class of applications. Especially with audio streaming apps, there seems little risk in allowing backgrounding, as the user will be aware of the fact that the application is running. Perhaps Apple can come up with some other solution that makes it possible to use a streaming or GPS tracking application without being locked out of the rest of the iPhone's features. For instance, the company could make it possible to leave such an application running after exiting the app, but that after 60 seconds of inactivity, the streaming or GPS app comes back into the foreground.

I can't argue against the utility of being able to use any music player, or a GPS tracker that can log every twist and turn, in the iPhone's background. But just as users once clamored for an iPhone 3G then cried out over the torture that the device wrought on their batteries, the potential of background apps on such a popular phone could quickly backfire. There are over 25,000 apps in the store now—do all of them, or even a significant portion, need to run in the background?

A distinction must be made in the debate over background applications. There are apps—such as music players and GPS trackers—that indeed need to�run in the background�to be of much use. This is why Apple grants a handful of its own apps, including iPod and Clock, that freedom. But then there are apps like IM and task managers that, from a user's perspective, really only need to�idle in the background. They aren't doing anything immediately useful while running, but they need to start quickly when a new message arrives and save progress when a user switches to a different app. Many apps, such as Tweetie, have already mastered these challenges quite well, and they don't need to run in the background to do it.�

An IM app is the perfect example of one that does nothing useful in the background, which is why Push Notifications is an ideal solution. Instead of allowing this IM app to waste CPU cycles and battery life while listening for messages, a server does the listening instead. Companies that plan to harness Push Notifications simply need to focus on building lean, capable apps that respond quickly when users act on a notification.�Call me a Vulcan, but I'm interested in the needs of the many when it comes to devices like the iPhone. At the end of the day, the many (including myself) need a phone that just works when it matters most, and battery-gobbling background processes are a direct threat to that need.�

There's an additional caveat, too. If Apple—the only (legitimate) iPhone application gate keeper—opened the flood gates for apps to run in the background, the review process could become exponentially longer. If too many apps destroy an iPhone's standby time while vying for attention, users�would undoubtedly flood Apple's customer service with questions on why their phones don't perform as well. Even if Apple granted background privileges to a handful of third parties, everyone from fart peddlers to productivity pushers would be clamoring for the same rights.

It makes sense to want background applications on such a powerful and convergent device as the iPhone. But through a combination of platform popularity, hardware, and battery constraints, plus the fact that many processes do not need to run in the background on the device in the first place, Apple's compromise makes the most sense.

I'd like to see a system like this:Developers can call a NSPowerManager* method like -(BOOL)registerForBackgroundPermission which would ask if it can run in the background, with a proper warning about the battery. (Sort of like asking about using your location) The answer to this is stored in a Settings panel named Power or Background Applications, or something similar, and returned to the caller.

This Settings panel allows you to revoke your permission later should you decide that "My Awesome Background App" isn't all that awesome, using Yes/No switches so you can turn it off when you really need to save power, and back on later when power is more readily available.

It would be ideal if their line in the pref panel were removed on app uninstall, but that's not my problem to work out.

I think there is room for Push AND Background. Allowing background apps is the easier task to accomplish by far, I think everyone would agree on this, but it would bring the above mentioned pain along with the pleasure.

Once we have background capability, no-one will bother to use notifications - what's the point? Well, the point is that taking the easy method isn't always the best solution. If we all started running apps in the background, then everyones experience will be blighted by both the extra drain on resource and user experience. Do I want to have to cycle through all my apps to see which is the hog when Bejewelled 2 runs like a dog? Do I want to have to use a task manager and start monitoring memory usage, and CPU idle times? These things are fine (in a way) for those of us that understand these things, but for the vast majority of people who just roll up to O2 or AT&T and buy the phone without having a background in technerdery like us it will be overly complex.

All of this would provide as many detractions to the experience as improvements. In the meantime they are developing the Push as an alternative. The fact that they are doing this FIRST is important. Push is elegant, if used what what it is intended for. IM chat, SMS, calendar items, stuff that you might want to be informed of but not necessarily for immediate action. Take the eBay app - I would quite like to be informed when an auction closes, or I am outbid (Yes, I know it emails you, but it's a good analogy). Would I want the ebay app running for 7 days nonstop to capture this info?

Providing developers with the ability to use push properly rather than just being lazy and allowing background will enable the developers to create better apps.

For a large proportion (I'd say most for my usage demographic) of apps, there is no benefit to background apps at all. Simply saving state on exit and restoring it on a restart is good enough. A smaller portion of my apps would make good use of notifications, and finally I have 2 apps that I would like background apps for - A music app, and a GPS app.

I think background will come, but only when the available power and capacity are sufficient to enable it to run without causing too much user impact on performance. Until then, I can see Apple providing a 3rd way for certain types of background uses. Why not have a GPS logger that can run in the background, and then supply it's data to a GPS app so when it starts it has all the data it would have missed through not running? Same with music, maybe a way can be found to allow an audio overide to a single application at a time, allowing it to work like the ipod app.

There are other considerations too - so I've got my background radio station playing, and a game or 2, and am IM app and a GPS app that beeps when I get close to a waypoint. Then the phone rings - how are these apps going to be told to mute?

This sort of thing that takes a lot more thinking about would be better than a lazy carte blanche backgrounding of everything.

I'm confused. How will this push notification system work? Isn't it also preventing the phone from going into deep sleep by listening for incoming TCP/IP packets all the time? What is it's effect on standby battery life? Does it require a working internet connection? Does is work over EDGE and other 2G connection protocols?

When I turn on push notifications for my Exchange or MobileMe accounts, by battery life drops considerably. Isn't the push notification service going to do the same thing?

There are some accelerometry applications like StepTrakLite would really benefit from having background support. Of course they would use up more power from needing the accelerometer to be on and running their analysis.

The current restrictions on the accelerometer use are actually even worse than the backgrounding restrictions. The accelerometer is disabled when the phone locks even if the app in the foreground want to keep using it. Thus these type of applications are dimming the screen to almost minimum and then disabling the auto lock, causing them to burn even more power than they need to due to the restriction.

Apple is really limiting innovation in this space with these restrictions as platforms like Android can easily handle this.

Apple could implement backround processes as a callback delegate. I register my method callMeBack with the iPhone backround service [NSBackgroundRequest callback:callMeBack]. Then, when the phone feels like it, it fires up my application and calls the call back. Apple doens't have to guarantee how often this will happen, or anything, only that occasionally your app will get some processor time.

This won't work for streaming or GPS, but it would work for IM clients, twitter, task managers, etc.

HitScan's solution isn't a bad one. If they are really concerned about it, only allow one app to run in the background, with an icon in top bar (like Bluetooth does). Then support is simple. "My battery life sucks." "Do you have this symbol at the top?" "Yes" "TURN OFF BACKGROUND APPS DOFUS!"

Its not a hard problem to solve- Apple is just being dumb and stubborn.

I'm going to sound like a broken record, but I'm going to keep posting this as widely as possible.

> For instance, if I want to play a podcast in RSS Player (much improved in the recent version 1.3)> or stream music with the Last.fm application, I can't browse the mobile web with Safari or type> an SMS without interrupting the audio playback.

A wide variety of these problems, but not all, could be solved if Apple allowed plugins in the existing three special apps - Phone, Messages (nee SMS) and iPod.

In this particular case, Last.fm would have a plugin in iPod instead of being a separate app. A separate app might still exist, but that would primarily be a UI for controlling the internal setup. One might select a station in the Last.fm UI, but that would simply pass information off to iPod. Inside iPod, the Last.fm streamer would be running.

This instantly gives Last.fm all the goodness that iPod already has. It will stop playing when a call comes in and resume when you hang up. It will keep playing when you turn off the screen. Exiting to type an SMS message will no longer interrupt playback.

The advantages within Messages are similar, and gives us the Adium-like single point of IM that we all really wanted in the first place. Incoming messages can (optionally) pop-up on the screen just like SMS, even when we're not running "the program". In this case, the existing push system might prove invaluable.

But it's in Phone that things become the most interesting. Apple could take the entire GSM stack and offload that into a plugin. Then they could write a UMA plugin and offer to install that on the phone for their partners, white labeled. If you're unfamiliar with UMA, go take a read about it on the wiki. Skype, Truphone, SIP, all of these would be plugged into Phone and get all the Phone goodness.

The one tough part here is that it requires a centralized presence system. Many of these plugins need to keep themselves alive on the network - including GSM. This is the part that MIGHT eat battery life, but my guess is that if this code is well isolated and only that code is run, periodically, I don't think it would be anything even remotely like keeping the whole app running.

Better yet, the plugins could include information to tell the presence system what resources they need to work - so when you walk away from your home WiFi router and UMA is no longer capable of being used, that module is called once to log out -if it can- and then no longer called. If and when the WiFi comes back, or optionally another one becomes available, the module is called again to log back in. That way the polling is dramatically reduced, mostly to those periods when the networking status changes, or on a timer than the code sets when they are logged in. One might imagine all sorts of resources that might want to turn the polling on or off.

I believe this would solve the battery life problems, solve most of the interactivity problems, and offer real value to the end user. No, it doesn't solve the GPS mappers and such, but it does hit a lot of the big ones.

Of course, all of this battery life excuse is complete BS. Or rather than complete BS, it shows that Apple really is not up to par with other operating systems in terms of battery performance. Plenty of Windows Mobile and Blackberry phones provide adequate battery life while running background applications.

As I see it, there are three types of applications in terms of background processing:

1. Applications that require user attention at all times, such as games, converters, etc. These should be suspended when switched away from, with absolutely no hit on battery life (but with a hit on memory).

2. Applications that need to run in the background. These include media players, browsers (background loading of pages), GPS apps, etc. These can be put to sleep when idle.

3. Applications that need to sleep in the background until woken up by an event, such as instant messaging programs and alarms. These can be suspended when switched to the background, and can set up event triggers and callbacks. This can also be done without a significant hit on battery life (again there will be a hit on memory, but that is a given when talking about multitasking).

The vast majority of apps can effectively sleep in the background with very little influence on battery life, and for most of the apps that fall in the second category it would be quite obvious to the user that they are running in the background when active.

I don't buy their current excuse, and the lack of background processing is the main problem I have with the iPhone right now.

Although background apps would be cool, I have experience on how much it kills battery time on a smart phone. This can take time between charges from 2 days down to 4 hours!!

If applications left the iPhone with only four hours on a single charge, I can imagine outcry from all users. Apple has plenty of history of people complaining about charge time, even when that charge time was two days. Until battery technology improves and CPUs can provide most bang per watts, then I am going to defend Apple on this one.

Can anyone give me examples of smart phones that are able to background well and have two days battery life, while offering 3G connectivity?

We may see background applications in the future, but not before Apple can create a sandbox or API that can limit how much backgrounding the application can do. In this case I would imagine an application having a flag indicating that it needs to background, and then the system ensures that application is not overusing the CPU. This is probably simple in concept, but complicated in implementation?

Edit: If the user really needs to background, then there is always jail breaking, which Apple should cast a blind eye to, yet monitor to see what sort of experience users are getting from it.

It's paternalistic of Apple to take on this battery life issue. Here's my suggestion: Introduce a new class of applications that will be allowed to run in the background. On the app store, clearly identify them as "potentially causing excessive battery usage". Let the end user decide for themselves. For applications that want to avoid this tag being applied to them, that don't *need* background processing, they will use push notifications or whatever. For applications that *need* it, they have it, and the user is made aware of this potential problem.

The next thing would be to develop an application (by Apple) that would monitor background usage, and help to identify, again to the end user, what applications are causing the most battery usage, and again, let the end user decide, not Apple, whether the battery life loss is balanced against the usefulness of the application that is causing it.

The article suggests an either/or when it comes to background apps. Does it have to be that way?

I'm no programmer, but I would assume it's possible to quit a program, but at the same time relay a key function to the OS, to keep it running in the background of other programs.

Take the GPS scenario. I don't know the iPhone's libraries. But I assume there are libraries in use when the apps accesses the GPS. So, why cannot the app hand over the library call to the OS while it's gone?

There can be a new App icon called "background tasks" on the launch screen. Then, when the user taps this icon, she is notified what apps are being served, either by GPS tracking, audio streaming or whatever. Included in this "relay of functions to the OS" can be rules for when to notify the user. E.g. "notify user when she has run (moved) another 4.5 km).

This way, Apple could allow "crucial" background functions while having full control to fine tune power management.

I'm sure this has been on mr. Forestall's drawing board for years already.

Would easily answer every single complaint that I have ever heard about running processes in the background with the exception of listening to the radio. Considering that to Apple, FM radio (regular or Internet varieties), is pretty much garbage, I don't see them bending over backwards for Last.fm.

All the things mentioned by the "con" person above can be fixed with the new push notification support including the GPS tracker or are third party solutions for core functionality already offered by Apple in the same or slightly different way.

With all the efforts and money Apple has dumped into propping up PodCasting, why would they screw up the iPhone just so as to provide support for a third party podcast app?

With all the money and effort they have dumped into iTunes, why would they screw up the iPhone to support Internet radio?

Personally, I would rather face a few constraints and have the device last as long as possible versus face the likelihood that it'll run out of gas when I need it most. I guess the big question is need vs. want. Is running in the background a need or is it merely a want? It's like wanting a sportscar to drive back and forth from work. Sure all that horsepower is great, but do you really need it.

If you want to see what having background apps is like then you just need to stop by the android dev forums and read all the threads where people are complaining about their apps not performing or crashing because of other apps sticking around in the background stealing processor cycles and memory from the foreground app.

It's already an issue on the iphone just with mail, safari and the phone running in the background - how many games do you see that suggest the user reboots their phone before trying to play the game?

1) apps that are intended to receive constant input (games, web browsers, etc) get shut down and never backgrounded. A "return state" is already offered for these apps (many games resume exactly where you left off). This is not done by sleeping in the background, but actually by saving a state to disk (flash) and then gracefully quitting leaving the memory state. (remember, RAM costs power, flashRAM does not).

2) Apps that require providing a user with a constant stream of information (audio, FM receiving, GPS tracking, etc). Well, getting the GPS chip to log and receive information in the background is a good thing. I'm sure the notification engine would be used to display the alerts. i doubt voice feedback would be possible from the background, but even when on a call, getting GPS data to interupt so you don't miss a turn should be possible on some level. As far as user initiated backgrounding, say because you got a text and wanted to respond, it should background the app only until you kill the interrupting app, and then auto return. Anytime you exit the app to open another on your own, it should not suspend, but terminate and resume later manually like any other app. An app with this kind of function would need to be carefully coordinated with Apple, from the inside. Companies like TomTom and Garmin are rumored to be doing exactly that. I expect such a thing might require updated hardware.

As for music apps, backgrounding should only be permitted if wifi or cell data is not a requirement of the backgrounded app. Playing music through the iPod interface sounds like a good idea until you realize that backgrounding LastFM means killing the battery in 2-3 hours tops due to the heavy use of 3G power draw. If the file is on your device already, it should have been imported through the iPon/iTunes interface and therefor can be played in the background normally. Streaming servcies should not be backgroundable. I'd be willinging to accept that they could be when docked, expect I've tried using one while docked on a 4 hour trip and the battery charging could barely keep up with the screen on. (Battery was 50% charged when I got in the car, about the same 4 hours later... This is MASSIVE draw. (and the phone got HOT!) Running LastFM and GPS at the same time? I don't think it could handle it... Running just the iPod, with the screen on, it can charge from 10% to full in about 2 hours... Considdering the draw, I'm guessing playing music over the cell network uses about 4 times the power of the iPod app. ...and I'm on 2G, 3G uses more power, nearly double the juice of the 2G netowork...

3) Any app that only sporadically needs to bring something to the user's attention: no bancgrounding. Use the push notification system.

I think many people miss the thing Apple has evidently noticed. There's a tragedy of the commons waiting to bite, here. It's in the developer's interest to make something even if it sucks a lot of power. The consumer buys it, and notices that his phone use is degraded. Now he doesn't throw the app out and think "stupid developer" because it's incremental - he liked the app, and the other one, and the other one, but at some point his phone has started to suck. So he says, "too bad about iPhones the idea is great but the battery life sucks."

I'm not arguing against allowing background applications, but I am going to argue for Apple's PNS...

Push notifications allow for a much better experience to the end user as it allows the user to receive notifications from a multitude of services without needing to have ALL of the clients open and running (in the background or not). The point of having a mobile device on us at all times is to stay in touch and keep up on the things that matter most to us.

If there are five different services that I follow, on current platforms I'd need to have those five different clients running and watching for incoming updates or I'd have to manually launch the client and check for any pending updates. I understand that it isn't very difficult or time consuming to have to manually check, but needing to do so adds a bit of inconvenience to a device that supposed to add convenience to our lives.

Needing to have those five clients running hinders the performance of the device in three areas... First of all, they take up memory in devices where memory is fairly limited. They also eat up CPU cycles, even if only a few, it would still affect performance. Third, needing to use the device's radios will inevitably drain the battery.

Combined, that all leads to a poor user experience with the device; worse performance, less battery life, and forced user app management. Now just imagine if there's 10 or 15 services you subscribe to? There's a level of utility and user convenience in PNS that simply cannot be overlooked.

When the platform (hardware) matures a bit more, Apple will eventually allow third party applications to remain running in the background, but I'm going to guess the user will have to specifically request or allow it. This will force users to remain aware and responsible for what's running on their devices and not need to worry about rogue processes taking over. Probably a method similar to the way applications have to ask for permission to find the current location.