Blog Post

Background Apps: They’re Not Just for Push


So Apple (s aapl) announced their push facility for iPhone OS 3.0 today. I think that’s great. Unfortunately, it’s only half a solution, and the other half is pretty important, too. At least it is to me. Let me explain.

If you want an app to let you know of something going one while you’re not looking — so you can do other things and stay informed — then push is great. In fact, I agree with Apple that keeping the whole app running in the background is overkill for this. In that regard, their push solution seems a great addition, keeping us from running numerous apps (and burning CPU cycles and battery life) for no other reason than we don’t want to lose touch. I’m with Apple on this solution all the way.

But sometimes it’s not about notification. Sometimes it’s just about switching.

Every single day I use NetNewsWire on my iPhone to read RSS feeds. I do this an hour or more each day. During that time I also stay in touch with friends and work via email and chat. Since I use Apple’s Mail and SMS apps, I already get background notification (further proof I know how necessary that functionality is). However, when I go to mail or chat to read/respond, I have to quit NNW. And when I go back to that app it must relaunch, and then I have to navigate back to where I was. This is frustrating enough that sometimes I delay responding until I hit a more convenient point in the text.

Why does it have to be this way? My point is that I don’t always want an app in the background for notification purposes. Sometimes I want it in the background because I’ll be switching right back to it. I’m only leaving for a few minutes; I’ll be right back. Why do I have to quit the freakin’ thing?

Push does nothing to address this usability issue. This is where allowing it to stay open in the background is a great solution.

To be sure, an app might be written to try to remember where it was, but even then I still have to relaunch it and let it figure that out. Why can’t I just switch to an app and back to another?

Way back when Switcher hit the Mac (and DOS before that), it wasn’t about background notifications. It was about not having to feel restricted to one app at a time, and not having to wait for an app to startup. I think those are still valid reasons for switching today. I wish the iPhone would allow it.

Make no mistake, the push facility is huge, and will be a great improvement. It addresses a critical portion of backgrounding in a better and more efficient manner. It also levels the playing field in giving third-party functionality that Apple’s apps already had. But it’s not the whole story, and it appears I’ll still be stuck with my switching problem even with a sleek new 3.0 iPhone.

19 Responses to “Background Apps: They’re Not Just for Push”

  1. johnnyc

    I have a question for you folks as well:

    What is the difference between the “new” wifi auto-connect, and the auto-connect that’s been built in since Day 1? I have multiple fav wifi networks that “connect when I arrive and disconnect when I leave” to paraphrase the “new” featured ability.

    What am I missing here?

  2. johnnyc

    I think it’s amazing that despite all of the improvements (to a device and platform still in it’s infancy compared to the competition) there are people focusing on gripes.

    I do understand the *wish* for BG processes, but I think it’s unrealistic considering the power needs of the iPhone. You have a large, bright high-res multi-touch display, with a fairly powerful processor, location services, 3G, Edge & Wifi, push, server refreshes, a telephone, and an iPod potentially all drawing power…

    Additional backgroud processes are still too premature to be rolled out widely. I your adamant, then jailbrake and deal with the potential hiccups. The iPhone is much better served by being a stable, reliable device.

    That said, backgrounding WILL COME. Who knows, maybe as soon as this summer with the hardware refresh, but definitely not on the current hardware.

  3. That could be handled by a wake-and-execute model, where the app requests a wake-up call from the OS.

    Are data transfers and voice not mutually exclusive? I know they are on my (oldish) BB.

  4. Even though the push service is great, it still only serves HALF the push problem. It’s great for server to client push, but what about when I want a client app to push data to the server while I’m on the phone or checking my email. For example, maybe I am going on a hike and I want my wife to be able to find me if I don’t come home… I could tell my app to run in the background (like blackberry) and it could then push my GPS location to a hosted service.

  5. Like mentioned, NNW could save its state. Some apps do this, and sometimes I don’t want it. I’d rather Mail open with the inbox every time then have it go back to the last mail I read.

    As far as just switching in/out vs. quitting, they’re not really that different. The iPhone has very little RAM, so if you switched out, it’d probably have to unload some stuff out of RAM and then bring it back in when you switch back. This would only split the lag between the switches instead of piling it up on a restart. Less intrusive, but probably not an overall gain.

    As far as apps putting up alerts themselves, I’m sure Apple could (if they haven’t already) add an API that allows an alert to be fired on a designated event, so the OS watches for the event and triggers the alert, asks if the user wants to switch to the app, and then does so. I think Apple is afraid of apps pushing them back to the front whenever they want. That’s one of my biggest peeves with Windows – IE pushes itself in my face whenever it feels like, as if I have no say in what gets my attention at that moment. Think about what that’d be like – 100 apps constantly throwing up alerts, it becomes unusable.

    I’m surprised there aren’t more complaints about the lack of spam filtering. I’d forgotten spam existed until I got a Touch.

  6. Brad Sterling

    A little followup on my previous comment. Android allows an app to wait on a notification. The app is not running thus uses no resources. If Apple can increment the number of notifications, it certainly doesn’t require anymore battery usage for the app to sit in limbo and be activated when the notification is received. I love Apple, but the 80% battery drainage is pure BS.

  7. Brad Sterling

    Surprised nobody mentioned that the push notification service is a developer’s nightmare. It requires any application using it to rollout a website which posts partial notification to the apple website which in turn posts to the device. Once the application is activated, the website must post the entire notification to the application.

    All of this is required, as opposed to simply running a background app which receives the entire notification from anywhere. As an example, suppose you want to play a game with another user. With background notification the devices can simply talk to one another (perhaps a lookup of the device would be necessary).

    This difference is huge.

  8. Why does it have to be this way? My point is that I don’t always want an app in the background for notification purposes. Sometimes I want it in the background because I’ll be switching right back to it. I’m only leaving for a few minutes; I’ll be right back. Why do I have to quit the freakin’ thing?

    Jailbreak, install Backgrounder. Allows you to run an app in the background and then return to it instantly from the springboard. It’s really neat.

  9. I definitely see your point about switching. I hope startup times can be improved and this issue may go away.

    Now, I want to listen to Slacker instead of my iPod and Apple doesn’t seem to want to allow this.

  10. One other reason to add to the list… let’s say I want to have my To Do list app remind me 2 hours before a task is due. So what happens Apple when I am in a bad reception area when the 2-hours warning time hits? I just miss it?? Why should a reminder type functionality need to have a whole server-side apparatus and internet connection just for something simple like this? Seems like massive overkill to me. For this particular purpose, it could be handled with some kind of ‘local’ notification process that would wake the To Do app up at the specified time.

  11. I think Apple should have just made a sort of virtual ‘shelf’ out of the bottom half of the iPhone screen. Kinda like the dock on Mac OS X. You don’t need a task manager. They could just put an “X” mark there for all running apps so you can close them when you don’t need them to run. Besides, they could also make apps run in the background only if the dev chooses it that way (as well as after user confirmation). Apple could have done all of this without creating a mess that is WinMo, but they choose to instead have push notifications.

    Am I the only one who hates those bubble notifications on our beautiful iPhone? They didn’t even make them a little more subtle like on the Pre.

    *I’m an iPhone lover, and think the new update is awesum!

  12. This is the beginning, middle, and end of why my iPhone is jailbroken. I could live without pretty much everything else but iRealSMS lets me respond to SMS messages without leaving the program I am using.

  13. Milind,

    “NNW could just as well save its state and resume from where it left off.”

    As I said, even when remembering their state, I still have to bother re-launching the thing. Much, much faster just to switch to it.

    As for your other examples, they’re all valid. My NNW example was by no means meant to be comprehensive. The point is there are other reasons for background apps besides push.

  14. I think you’ve got it upside down backwards. We do need background apps, but not for the purpose you’ve just mentioned. NNW could just as well save its state and resume from where it left off. Games do it all the time.

    BG apps are required for this like voice recording while reading notes, listening to internet radio while chatting, and your files being transferred without having to have the app open.

  15. It is a best practice for iPhone applications to save their “state” before closing or as they’re being interrupted by a phone call, etc. so that when opened again or after the interruption has been removed, the application can restore that state. A lot of applications don’t do this but it is recommended and supported by the iPhone SDK.