18 ms·

Misconceptions About iOS Multitasking

205 points by JoelMcCracken 15y ago

arn 15y ago
Steve Jobs email addressed this in an email: http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multitasking_just_use_it_as_designed_and_youll_be_happy/ http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multita... “People shouldn’t have to understand multitasking. Just use is [sic] as designed, and you’ll be happy. No need to ever quit apps.” – Steve Jobs’ email, June 29, 2010 another email too: http://forums.macrumors.com/showthread.php?t=955236 http://forums.macrumors.com/showthread.php?t=955236 regarding quitting apps to save battery life: "You don't need to do that to save battery life. Trust the iPhone."
- glhaynes 15y ago
  Which makes it all the more infuriating that Geniuses are telling people to clear that stuff out. A directive needs to come from on high to stop that.
  - danellis 15y ago
    Indeed. I took my iPad in because it kept losing its wifi connection. The "genius" looked at all that apps along the bottom and declared that they were using so much memory that the OS was forgetting the wifi password.
    - chc 15y ago
      That's just weird. There's no supported way to tell what apps are actually in memory. The list in the bottom when you double-click the home button just shows all recently used apps, even if they've been purged.
    - glhaynes 15y ago
      Steve would have wept if he could have seen that happen.
  - ghshephard 15y ago
    Well, infuriating except for the fact that it works in a number of scenarios with very little risk. My advice would probably be simpler, "Just reboot your iPhone. "
    - glhaynes 15y ago
      I agree with "reboot your phone if you're having repeated troubles" but not with telling people to clear out the list — sure, there's very little risk of harm to the device, but because people (including authoritative ones) are telling people they need to clear the task switcher out, how many hundreds of thousands—if not millions—of people are spending minutes every day clearing the list out? Not to mention the extra mental "weightiness" to all those people of having one more thing in their lives that's constantly filling with cruft and needing to be emptied?
- MBCook 15y ago
  And he's right. I can take my parent's iPhone or iPad and the recently open app list is 5-10 screens, yet the device still works perfectly. My mother doesn't have to know to quit things, the OS just does the right thing. That said, there are a few cases where closing all the background apps makes a difference with a game. Some games (I've seen it on Worms: Armageddon, Angry Birds, and a few others) can lose their fluidity, I think the problem is memory allocations. Closing all recently used apps (thus forcing any that are suspended into the not running state) can fix this. This was much worse on my 3G. The problem is very rare on my iPhone 4. But for normal users, it's perfectly possible to use the phone for months and never need to close a single app manually.
  - masklinn 15y ago
    > This was much worse on my 3G. Which is why Apple did not enable it on the 3G in the first place. (did you jailbreak it, or are you talking about the 3GS?)
    - Macha 15y ago
      Apple default apps. At least when I had my iPod Touch 2G, some apps simply needed a device restart or they would not perform well at all. Simcity for example, was the one I always noticed.
      - MrFoof 15y ago
        To be fair, there's actually a large number of reports of crashes and freezes in the App Store. I wouldn't consider SimCity Deluxe for iOS to be a model citizen in terms of application stability. http://itunes.apple.com/us/app/simcity-deluxe/id380017992?mt=8 http://itunes.apple.com/us/app/simcity-deluxe/id380017992?mt... If I trawl through all my logs in Xcode, the number of app crashes I've seen with the iPhone 3GS, iPhone 4 and iPhone 4S from third-party apps can be counted using just the fingers on my hands. I think there was once an application that proved to be a bit unstable, and it ended up replaced by an alternative pretty quickly.
    - MBCook 15y ago
- r00fus 15y ago
  It would be nice to have some on-screen indicator that the app is capable of burning battery though. I wouldn't mind knowing, for example, to force-quit the Skype completely before leaving on holidays so I can have more battery life on the plane. Just a small badge would be nice.
  - potatolicious 15y ago
    There are some indications - if something is getting location data in the background your location icon stays on in the top bar. There's definitely no indication for "chewing up all your data in the background" though, but thus far I've personally found no need for it. An app that's chewing up data in the background is usually fairly obvious - Skype, Pandora, etc.
masklinn 15y ago
> You may think that, if an app is resident in memory, you have to somehow remove it to conserve memory. You don't because iOS does it for you. If there are Suspended apps lying around and you launch a memory-intensive app such as a big game, iOS will start to purge Suspended apps and move them to the Not Running state. That is, they will be completely removed from memory and will launch afresh the next time you tap their icon. This, however, is not "impact-less": when running truly memory-intensive games, they will experience performance degradation while the OS performs cleanup and shutdown of the various applications "hibernating". This is sensible on games like Infinity Blade. iOS also suffers from not allowing the user to make a distinction between "not running or hibernating" (no resource consumption) and "keeps your GPS or data connection active" (very high battery drain), and not providing a way for the user to know which application requested what (in the way the "Notification" settings let you control notifications rights for all applications, or iOS5's new "General > Usage" gives you a size estimate for the system's applications). I also believe this: > 5. Five classes of apps - audio, GPS, VOIP, Newsstand and accessory apps - and some built-in apps such as Mail may run indefinitely in the background until they complete their task. is partially incorrect in following 4.: these applications can all be killed as memory pressure on the system increases, however they have a "higher priority" (and thus will be killed last) compared to suspended applications.
- adamjernst 15y ago
  True. However I should point out that cleanup and shutdown is pretty minimal: it's killed without warning. (I don't know if you even get a signal handler called.) A hibernating app is not allowed to execute any code.
  - saurik 15y ago
    This only happens when memory has become critical and not enough applications can free memory fast enough; initially, applications get a low-memory warning and they have an opportunity to deallocate things they are not using in the hope that the system will not have to kill processes. This includes things the developer may not even have explicitly coded, such as dumping video surfaces and sqlite caches. I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all), but the default Apple-provided ("System") applications (such as Safari, Mail, etc.) definitely get this opportunity.
dvanduzer 15y ago
I really wish the article explicitly explained exactly what happens when you manually manage the multitasking bar. My anecdotal experience is that removing an app from "recently used" does have the effect of terminating it if it was in one of the semi-background states. While the advice to manually manage this is ham-fisted troubleshooting, it is unfortunately effective (cf. restarting Windows). I suspect (and would love to see more analysis on this) that some apps in the categories allowed infinite background time are behaving badly. It may only be one VOIP app running persistently in the background that drains the battery, but this advice would consequently solve that problem.
- RandallBrown 15y ago
  yes if you kill it from the multitasking bar it completely kills the process and the next time the app launches, it is from scratch. That is why force killing an app and restarting it will often fix little glitches in it.
- Codhisattva 15y ago
  It's a kill -9.
Brajeshwar 15y ago
Well, however, the 'killing the app manually' is useful while you're testing your app. We had a situation where the app is not the culprit but a middle-layer that authenticates through Facebook. As we've not yet taken care of the middle-layer failure, our iOS app was unable to figure out what to do but sent us in a Limbo. Killing it manually help us 're-start' the app so we can use it without doing the 'un-install' and 'install' all over again. Outlined in an article I wrote recently - http://brajeshwar.com/2011/kill-a-background-app-in-ios/ http://brajeshwar.com/2011/kill-a-background-app-in-ios/
RandallBrown 15y ago
This is a really well written article and does a great job explaining backgrounding on iOS. Unfortunately, I've seen a couple of apps that have somehow been able to abuse the background APIs and have killed my battery. The only way to prevent this from happening is to force quit the app from the multitasking bar. The app I've noticed this with is GroupMe. If I don't kill it after closing it, my phone gets really hot and my battery dies. I have location turned off for GroupMe.
- acidblue 15y ago
  If there are other apps such as this one people should talk about them more. Plus, give them a poor review on the AppStore and delete the application. There's no reason to have a poorly written application on your device.
ghshephard 15y ago
While the article may be accurate in "theory" - I can say that my iPhone 4 got significantly better battery life when I was careful to kill all but the currently running application. I think the issue is that some of the apps that I was running may have been abusing the "background" feature, and so switching to home didn't kill them - as evidenced by how hot my iPhone would get while on the home screen - which results in a pretty trivial stimuli/response strategy: If you have been on the home screen for 15+ minutes, and your iPhone is hot - either Reboot it or simply close down the "background/running" apps. Note - that lacking the built-in tools that the droid has to track things like CPU/Memory usage (and, in ICS - Battery Usage) - we have to resort to things like "Is my iPhone acting Slow? Is it Hot? " If I've been using my iPhone for a few days, and there are a zillion apps in the "Recently Used" bar, I simply reboot the iPhone - may take a couple minutes, but requires no effort as compared to playing whack-a-mole with the Launch Bar.
- Gorbzel 15y ago
  I'm sorry, but this "accurate in theory" junk needs to stop, it's this sort of meaningless reliance on inaccurate anecdotal accounts that allows the misinformation that the article talks about to spread. The article specifically points out that iOS doesn't allow apps to "abuse" background processing; you get 10 minutes and then the OS forces your app to standby. If an app uses the indefinite background processing for something other than what's permitted, then the app is rejected from the App Store, and they're very strict on this one. The Android/ICS model you talk about is exactly the kind of process management that Apple specifically avoided in iOS, and for good reason. IMO, that's the exact sort of thing that I'd never want to do on my smartphone. Your routine may keep you happy, but please don't respond to a well-researched and accurate article with the exact opposite of the truth; you're basically just plugging your ears and shouting "NUH-UH!" here.
  - ghshephard 15y ago
    I can't argue with the theory presented in the article - and I read it very, very carefully. All I can do is present the reality, and demonstrate it conflicts with the theory. The reality is that certain apps on IOS can continue to run in the background - whether that's because they are polling the GPS radio, waiting for a VOIP connection, or something else - I don't know. All I know, (And I'm speaking here as an owner of the Original iPhone, 3G, 3GS, 4, 4S who uses his iPhone multiple times, every waking hour) is that sometimes the iPhone gets hot, and the battery starts moving to 0 from a full charge in a matter of hours - when it does this, if I either (A) Reboot the iPhone or (B) shut down all of the apps listed in the "Recently used" task bar, then my iPhone is (1) No longer hot, and (2) experiences normal battery drain. I reference the Android/ICS model because at least in _that_ world (and remember - I'm a dedicated apple users) I could tell you which of the Apps was actually sucking my battery dry. If this were science, then it would be useful to collect a large number of observations that conflicted with accepted theory, to determine if (A) there was measurement error on the part of the observer - for example, perhaps I didn't wait 10 minutes after hitting the home button before waiting for the iPhone to cool down, or (B) There is a problem with the theory. My belief is that it's (C) The theory is accurate, it just doesn't recognize that Apps will sometimes run in the background using more CPU than the user is aware they are, or wants them to. I just wish I had a tool to tell me _which_ app it was - then I could just shut down that _single_ app, instead of my existing reboot/shut-them-all-down approach.
deleted 15y ago
[deleted]
- unlocal 15y ago
  It might help if you were to explain where "there" is, because what you're saying sounds like it might have been an interesting, albeit annoying, parallel universe. However, Fraser's article is correct in all the key areas, and your claims to the contrary are not.
- mikeash 15y ago
  No, the geniuses are definitely not right on this score. Maybe this technique works sometimes, but if it does then it's due to other reasons or pure luck.
swanson 15y ago
Is there a tool that lets you trigger some of these state changes (Suspended -> Killed, for example) for debugging/testing purposes? Trying to get the OS to forcibly kill an app due to memory pressure is something I've had trouble doing on Android and seems like it could be a problem on iOS also.
- jkubicek 15y ago
  The simulator can simulate a low-memory warning. To simulate an app being killed, just kill the app from Xcode.
  - gavingmiller 15y ago
    The key word there is simulate. There are cases (see my response) that arise that purposely triggering these state changes could really help with.
    - giesti 15y ago
      You could try to write a very simple app to run in background and waste memory on purpose (e.g. creating some shit in a loop) if you really needda replicate such a scenario w/o emulation. In my experience, as usually you can get away with ~30mb of "wasted" memory per each instance before iOS kills the daemon. So just launch a couple of those and enjoy.
- gavingmiller 15y ago
  I'm in this situation currently and would love a point in the right direction if anyone has one. My app loses the user's "current location", reports 0,0 from gps, and won't pick up a new current location unless the app is killed. Using the simulator's memory warning doesn't trigger the issue, only sitting on the device causes the problem to surface.
joelhaasnoot 15y ago
Isn't the exact same principle true of Android, with the slight distinction being that any app can multitask, not just the 5 classes of apps? Android may also kill any app whenever it wants (and prior to 2.1 or 2.2 actually did that very often, requiring always on apps to have ongoing notifications). It's just not as strict as the iOS scheduler.
- drivebyacct2 15y ago
  Yes.
- keeperofdakeys 15y ago
  Android has applications and services, services are application dedicated to running in the background. Android also provides a list of these services (Settings -> Applications -> Running Services). Normal applications, in regards to background computation, are handled in a similar way to iOS.
  - kefs 15y ago
    Also, Android opens all of this information up for developers via apis, so you can only imagine the plethora of great task managers available...
- yardie 15y ago
  In principal, yes. But in my experience without any real enforcement developers do whatever they want. It drives me nuts that I have to reboot my tablet every 3-5 days. Eventually the memory is fragged to pieces and everything, especially the browser, crawls.
nahname 15y ago
The skype app will run indefinitely in the background, killing your battery much sooner than normal. Killing it from the multi-tasking list does prevent this. It is the only app that I am aware of where this makes any difference.
- pudquick 15y ago
  That's because it's a VoiP app - which was listed in the article as being one of the classes of apps allowed to run in the background indefinitely. Skype is not unique. All VoiP-declared (has to register itself as such and Apple has to approve that classification for publishing on the App Store) apps act like this.
dools 15y ago
I miss Symbian :(
cschep 15y ago
If something is leaky, it's worth force killing it then, right?
deleted 15y ago
[deleted]
hamedh 15y ago
You can write a audio, GPS, VOIP, etc app that does more than just do audio, GPS, VOIP, etc in the background. For example, you may think the app is only playing audio or doing GPS updates, but it can be badly-written and updating UI and/or other intense stuff. Now granted, iOS will still kill those apps if they start taking up too much memory/resources while in the background. But I think the article is accurate, you shouldn't ever have to manage apps. iOS is night and day compared to Android's task management (where iOS is much better for users).
steve8918 15y ago
I'm fairly certain that if I run "Words With Friends" once, if I don't kill it after I'm done, it will kill my battery roughly twice as quickly as normal. Has anyone else seen this, or am I simply wrong?
DHowett 15y ago
I certainly wish iOS managed backgrounded apps better than the article purports it to. If you have a handful of applications suspended, and you're using MobileSafari, why does the application dump tabs that you're actively switching between before the OS dumps suspended apps? You're creating memory pressure in a foreground app and should therefore be given priority. That's sort of where this thing falls apart: "iOS does it perfectly. Don't argue it." except when it does not.
TechNewb 15y ago
Does continual, and/or static, RAM usage/storage not effect battery life? I know it would be minimal, but I imagine it would be potentially noticeable.
- fullsailor 15y ago
  Even when you free RAM by force-quitting the app its not deleted, only marked as free. I also don't think that unused RAM, (all 0s?) would use less power than used RAM.
- voyou 15y ago
  RAM doesn't use more or less power depending on whether or not it's been allocated to an application, so by itself continual/static RAM usage doesn't effect battery life at all. Now, if the OS needs to remove a suspended application from memory in order to free up RAM for a foreground application, that will involve the processor and so use some power, although I would imagine a small amount. If a suspended application is removed from memory and then needs to be restarted when it is next used, that will also use the processor (and the flash storage), which will require power. So leaving memory allocated for suspended apps can have an effect of battery life, although not directly because of the memory itself using power.
EGreg 15y ago
Not exactly true - for example I can force-quit apps using the multitasking bar.
robmcm 15y ago
My only exception to this rule is with the memory. Safari uses avaliable memory for caching web pages in tabs, which is understandably at a low priority. I often find that iOS will give priority to 'suspended' apps rather than 'suspended' tabs. In order to get safari to stop upnloading the tabs you need to free up memory manually. This however is an edge case.
buff-a 15y ago
There is one iOS "tip" that I keep hearing and it is wrong. I've never heard this "tip" from anyone. Ever. Any links or references to these "supposedly authoritative sources"? I'm finding it hard to take this article seriously when it says: "When you press the home button, iOS will tell the app to quit. In almost all cases, it quits..." Then, a few paragraphs later: "When you press the home button, the app moves from Active to Background. Most apps usually then go from Background to Suspended in a matter of seconds." Wait, I thought you said it gets told to quit? According to this [1], an app has to specifically request to be killed when the home button is pressed. "When the value of this key is YES, the application is terminated and purged from memory instead of moved to the background. If this key is not present, or is set to NO, the application moves to the background as usual." The information in the article about states is useful, but why open with factually incorrect information? [1] http://developer.apple.com/library/IOs/#documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html http://developer.apple.com/library/IOs/#documentation/Genera...
- jakobe 15y ago
  I have also heard that tip plenty of times, but it's difficult to give links and references to real life conversations :). Anyway, the UIApplicationExitsOnSuspend key is for legacy apps, and has nothing to do with the article. If that key is set to YES, iOS treats your app as it did before 4.0 and restarts the app every time you switch away from it and back again. The article explains how it works on iOS 4.0 and later.
- dextorious 15y ago
  """I've never heard this "tip" from anyone. Ever.""" And you're the golden standard of iPhone-related tips awareness, because?
  - buff-a 15y ago
    I have an android and an iPhone. I was recommended task killer for android by the guy in the verizon store. The next guy in the verizon store when I went back and mentioned battery life while I was buying a car charger. My friends with android phones. Teh Internet. I have purchased 8 iOS devices and I know more people with iPhones than android. This was the first I've heard of it. It was not my intention to suggest that I am the authority on iPhone tips. I was merely expressing my surprise that after hearing a similar suggestion practically every damn conversation I have about my Droid, that I had not heard such a thing about iPhone.
pbreit 15y ago
This article is at least disingenuous and probably flat out wrong. As many have pointed out, "running" apps are not impact-less. The author says as much himself. The author also acknowledges that being "well-written" matters which we of course know is not always the case. The author oddly brushes off the impact of long running background apps. And simply wrong is the contention that the multitasking bar is merely recently used apps.

205 points by JoelMcCracken 15y ago

arn 15y ago

Steve Jobs email addressed this in an email: http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multitasking_just_use_it_as_designed_and_youll_be_happy/ http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multita... “People shouldn’t have to understand multitasking. Just use is [sic] as designed, and you’ll be happy. No need to ever quit apps.” – Steve Jobs’ email, June 29, 2010 another email too: http://forums.macrumors.com/showthread.php?t=955236 http://forums.macrumors.com/showthread.php?t=955236 regarding quitting apps to save battery life: "You don't need to do that to save battery life. Trust the iPhone."

glhaynes 15y ago
Which makes it all the more infuriating that Geniuses are telling people to clear that stuff out. A directive needs to come from on high to stop that.
- danellis 15y ago
  Indeed. I took my iPad in because it kept losing its wifi connection. The "genius" looked at all that apps along the bottom and declared that they were using so much memory that the OS was forgetting the wifi password.
  - chc 15y ago
    That's just weird. There's no supported way to tell what apps are actually in memory. The list in the bottom when you double-click the home button just shows all recently used apps, even if they've been purged.
  - glhaynes 15y ago
    Steve would have wept if he could have seen that happen.
- ghshephard 15y ago
  Well, infuriating except for the fact that it works in a number of scenarios with very little risk. My advice would probably be simpler, "Just reboot your iPhone. "
  - glhaynes 15y ago
    I agree with "reboot your phone if you're having repeated troubles" but not with telling people to clear out the list — sure, there's very little risk of harm to the device, but because people (including authoritative ones) are telling people they need to clear the task switcher out, how many hundreds of thousands—if not millions—of people are spending minutes every day clearing the list out? Not to mention the extra mental "weightiness" to all those people of having one more thing in their lives that's constantly filling with cruft and needing to be emptied?
MBCook 15y ago
And he's right. I can take my parent's iPhone or iPad and the recently open app list is 5-10 screens, yet the device still works perfectly. My mother doesn't have to know to quit things, the OS just does the right thing. That said, there are a few cases where closing all the background apps makes a difference with a game. Some games (I've seen it on Worms: Armageddon, Angry Birds, and a few others) can lose their fluidity, I think the problem is memory allocations. Closing all recently used apps (thus forcing any that are suspended into the not running state) can fix this. This was much worse on my 3G. The problem is very rare on my iPhone 4. But for normal users, it's perfectly possible to use the phone for months and never need to close a single app manually.
- masklinn 15y ago
  > This was much worse on my 3G. Which is why Apple did not enable it on the 3G in the first place. (did you jailbreak it, or are you talking about the 3GS?)
  - Macha 15y ago
    Apple default apps. At least when I had my iPod Touch 2G, some apps simply needed a device restart or they would not perform well at all. Simcity for example, was the one I always noticed.
    - MrFoof 15y ago
      To be fair, there's actually a large number of reports of crashes and freezes in the App Store. I wouldn't consider SimCity Deluxe for iOS to be a model citizen in terms of application stability. http://itunes.apple.com/us/app/simcity-deluxe/id380017992?mt=8 http://itunes.apple.com/us/app/simcity-deluxe/id380017992?mt... If I trawl through all my logs in Xcode, the number of app crashes I've seen with the iPhone 3GS, iPhone 4 and iPhone 4S from third-party apps can be counted using just the fingers on my hands. I think there was once an application that proved to be a bit unstable, and it ended up replaced by an alternative pretty quickly.
  - MBCook 15y ago
r00fus 15y ago
It would be nice to have some on-screen indicator that the app is capable of burning battery though. I wouldn't mind knowing, for example, to force-quit the Skype completely before leaving on holidays so I can have more battery life on the plane. Just a small badge would be nice.
- potatolicious 15y ago
  There are some indications - if something is getting location data in the background your location icon stays on in the top bar. There's definitely no indication for "chewing up all your data in the background" though, but thus far I've personally found no need for it. An app that's chewing up data in the background is usually fairly obvious - Skype, Pandora, etc.

masklinn 15y ago

> You may think that, if an app is resident in memory, you have to somehow remove it to conserve memory. You don't because iOS does it for you. If there are Suspended apps lying around and you launch a memory-intensive app such as a big game, iOS will start to purge Suspended apps and move them to the Not Running state. That is, they will be completely removed from memory and will launch afresh the next time you tap their icon. This, however, is not "impact-less": when running truly memory-intensive games, they will experience performance degradation while the OS performs cleanup and shutdown of the various applications "hibernating". This is sensible on games like Infinity Blade. iOS also suffers from not allowing the user to make a distinction between "not running or hibernating" (no resource consumption) and "keeps your GPS or data connection active" (very high battery drain), and not providing a way for the user to know which application requested what (in the way the "Notification" settings let you control notifications rights for all applications, or iOS5's new "General > Usage" gives you a size estimate for the system's applications). I also believe this: > 5. Five classes of apps - audio, GPS, VOIP, Newsstand and accessory apps - and some built-in apps such as Mail may run indefinitely in the background until they complete their task. is partially incorrect in following 4.: these applications can all be killed as memory pressure on the system increases, however they have a "higher priority" (and thus will be killed last) compared to suspended applications.

adamjernst 15y ago
True. However I should point out that cleanup and shutdown is pretty minimal: it's killed without warning. (I don't know if you even get a signal handler called.) A hibernating app is not allowed to execute any code.
- saurik 15y ago
  This only happens when memory has become critical and not enough applications can free memory fast enough; initially, applications get a low-memory warning and they have an opportunity to deallocate things they are not using in the hope that the system will not have to kill processes. This includes things the developer may not even have explicitly coded, such as dumping video surfaces and sqlite caches. I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all), but the default Apple-provided ("System") applications (such as Safari, Mail, etc.) definitely get this opportunity.

dvanduzer 15y ago

I really wish the article explicitly explained exactly what happens when you manually manage the multitasking bar. My anecdotal experience is that removing an app from "recently used" does have the effect of terminating it if it was in one of the semi-background states. While the advice to manually manage this is ham-fisted troubleshooting, it is unfortunately effective (cf. restarting Windows). I suspect (and would love to see more analysis on this) that some apps in the categories allowed infinite background time are behaving badly. It may only be one VOIP app running persistently in the background that drains the battery, but this advice would consequently solve that problem.

RandallBrown 15y ago
yes if you kill it from the multitasking bar it completely kills the process and the next time the app launches, it is from scratch. That is why force killing an app and restarting it will often fix little glitches in it.
Codhisattva 15y ago
It's a kill -9.

Brajeshwar 15y ago

Well, however, the 'killing the app manually' is useful while you're testing your app. We had a situation where the app is not the culprit but a middle-layer that authenticates through Facebook. As we've not yet taken care of the middle-layer failure, our iOS app was unable to figure out what to do but sent us in a Limbo. Killing it manually help us 're-start' the app so we can use it without doing the 'un-install' and 'install' all over again. Outlined in an article I wrote recently - http://brajeshwar.com/2011/kill-a-background-app-in-ios/ http://brajeshwar.com/2011/kill-a-background-app-in-ios/

RandallBrown 15y ago

This is a really well written article and does a great job explaining backgrounding on iOS. Unfortunately, I've seen a couple of apps that have somehow been able to abuse the background APIs and have killed my battery. The only way to prevent this from happening is to force quit the app from the multitasking bar. The app I've noticed this with is GroupMe. If I don't kill it after closing it, my phone gets really hot and my battery dies. I have location turned off for GroupMe.

acidblue 15y ago
If there are other apps such as this one people should talk about them more. Plus, give them a poor review on the AppStore and delete the application. There's no reason to have a poorly written application on your device.

ghshephard 15y ago

While the article may be accurate in "theory" - I can say that my iPhone 4 got significantly better battery life when I was careful to kill all but the currently running application. I think the issue is that some of the apps that I was running may have been abusing the "background" feature, and so switching to home didn't kill them - as evidenced by how hot my iPhone would get while on the home screen - which results in a pretty trivial stimuli/response strategy: If you have been on the home screen for 15+ minutes, and your iPhone is hot - either Reboot it or simply close down the "background/running" apps. Note - that lacking the built-in tools that the droid has to track things like CPU/Memory usage (and, in ICS - Battery Usage) - we have to resort to things like "Is my iPhone acting Slow? Is it Hot? " If I've been using my iPhone for a few days, and there are a zillion apps in the "Recently Used" bar, I simply reboot the iPhone - may take a couple minutes, but requires no effort as compared to playing whack-a-mole with the Launch Bar.

Gorbzel 15y ago
I'm sorry, but this "accurate in theory" junk needs to stop, it's this sort of meaningless reliance on inaccurate anecdotal accounts that allows the misinformation that the article talks about to spread. The article specifically points out that iOS doesn't allow apps to "abuse" background processing; you get 10 minutes and then the OS forces your app to standby. If an app uses the indefinite background processing for something other than what's permitted, then the app is rejected from the App Store, and they're very strict on this one. The Android/ICS model you talk about is exactly the kind of process management that Apple specifically avoided in iOS, and for good reason. IMO, that's the exact sort of thing that I'd never want to do on my smartphone. Your routine may keep you happy, but please don't respond to a well-researched and accurate article with the exact opposite of the truth; you're basically just plugging your ears and shouting "NUH-UH!" here.
- ghshephard 15y ago
  I can't argue with the theory presented in the article - and I read it very, very carefully. All I can do is present the reality, and demonstrate it conflicts with the theory. The reality is that certain apps on IOS can continue to run in the background - whether that's because they are polling the GPS radio, waiting for a VOIP connection, or something else - I don't know. All I know, (And I'm speaking here as an owner of the Original iPhone, 3G, 3GS, 4, 4S who uses his iPhone multiple times, every waking hour) is that sometimes the iPhone gets hot, and the battery starts moving to 0 from a full charge in a matter of hours - when it does this, if I either (A) Reboot the iPhone or (B) shut down all of the apps listed in the "Recently used" task bar, then my iPhone is (1) No longer hot, and (2) experiences normal battery drain. I reference the Android/ICS model because at least in _that_ world (and remember - I'm a dedicated apple users) I could tell you which of the Apps was actually sucking my battery dry. If this were science, then it would be useful to collect a large number of observations that conflicted with accepted theory, to determine if (A) there was measurement error on the part of the observer - for example, perhaps I didn't wait 10 minutes after hitting the home button before waiting for the iPhone to cool down, or (B) There is a problem with the theory. My belief is that it's (C) The theory is accurate, it just doesn't recognize that Apps will sometimes run in the background using more CPU than the user is aware they are, or wants them to. I just wish I had a tool to tell me _which_ app it was - then I could just shut down that _single_ app, instead of my existing reboot/shut-them-all-down approach.

deleted 15y ago

[deleted]

unlocal 15y ago
It might help if you were to explain where "there" is, because what you're saying sounds like it might have been an interesting, albeit annoying, parallel universe. However, Fraser's article is correct in all the key areas, and your claims to the contrary are not.
mikeash 15y ago
No, the geniuses are definitely not right on this score. Maybe this technique works sometimes, but if it does then it's due to other reasons or pure luck.

swanson 15y ago

Is there a tool that lets you trigger some of these state changes (Suspended -> Killed, for example) for debugging/testing purposes? Trying to get the OS to forcibly kill an app due to memory pressure is something I've had trouble doing on Android and seems like it could be a problem on iOS also.

jkubicek 15y ago
The simulator can simulate a low-memory warning. To simulate an app being killed, just kill the app from Xcode.
- gavingmiller 15y ago
  The key word there is simulate. There are cases (see my response) that arise that purposely triggering these state changes could really help with.
  - giesti 15y ago
    You could try to write a very simple app to run in background and waste memory on purpose (e.g. creating some shit in a loop) if you really needda replicate such a scenario w/o emulation. In my experience, as usually you can get away with ~30mb of "wasted" memory per each instance before iOS kills the daemon. So just launch a couple of those and enjoy.
gavingmiller 15y ago
I'm in this situation currently and would love a point in the right direction if anyone has one. My app loses the user's "current location", reports 0,0 from gps, and won't pick up a new current location unless the app is killed. Using the simulator's memory warning doesn't trigger the issue, only sitting on the device causes the problem to surface.

joelhaasnoot 15y ago

Isn't the exact same principle true of Android, with the slight distinction being that any app can multitask, not just the 5 classes of apps? Android may also kill any app whenever it wants (and prior to 2.1 or 2.2 actually did that very often, requiring always on apps to have ongoing notifications). It's just not as strict as the iOS scheduler.

drivebyacct2 15y ago
Yes.
keeperofdakeys 15y ago
Android has applications and services, services are application dedicated to running in the background. Android also provides a list of these services (Settings -> Applications -> Running Services). Normal applications, in regards to background computation, are handled in a similar way to iOS.
- kefs 15y ago
  Also, Android opens all of this information up for developers via apis, so you can only imagine the plethora of great task managers available...
yardie 15y ago
In principal, yes. But in my experience without any real enforcement developers do whatever they want. It drives me nuts that I have to reboot my tablet every 3-5 days. Eventually the memory is fragged to pieces and everything, especially the browser, crawls.

nahname 15y ago

The skype app will run indefinitely in the background, killing your battery much sooner than normal. Killing it from the multi-tasking list does prevent this. It is the only app that I am aware of where this makes any difference.

pudquick 15y ago
That's because it's a VoiP app - which was listed in the article as being one of the classes of apps allowed to run in the background indefinitely. Skype is not unique. All VoiP-declared (has to register itself as such and Apple has to approve that classification for publishing on the App Store) apps act like this.

dools 15y ago

I miss Symbian :(

cschep 15y ago

If something is leaky, it's worth force killing it then, right?

deleted 15y ago

[deleted]

hamedh 15y ago

You can write a audio, GPS, VOIP, etc app that does more than just do audio, GPS, VOIP, etc in the background. For example, you may think the app is only playing audio or doing GPS updates, but it can be badly-written and updating UI and/or other intense stuff. Now granted, iOS will still kill those apps if they start taking up too much memory/resources while in the background. But I think the article is accurate, you shouldn't ever have to manage apps. iOS is night and day compared to Android's task management (where iOS is much better for users).

steve8918 15y ago

I'm fairly certain that if I run "Words With Friends" once, if I don't kill it after I'm done, it will kill my battery roughly twice as quickly as normal. Has anyone else seen this, or am I simply wrong?

DHowett 15y ago

I certainly wish iOS managed backgrounded apps better than the article purports it to. If you have a handful of applications suspended, and you're using MobileSafari, why does the application dump tabs that you're actively switching between before the OS dumps suspended apps? You're creating memory pressure in a foreground app and should therefore be given priority. That's sort of where this thing falls apart: "iOS does it perfectly. Don't argue it." except when it does not.

TechNewb 15y ago

Does continual, and/or static, RAM usage/storage not effect battery life? I know it would be minimal, but I imagine it would be potentially noticeable.

fullsailor 15y ago
Even when you free RAM by force-quitting the app its not deleted, only marked as free. I also don't think that unused RAM, (all 0s?) would use less power than used RAM.
voyou 15y ago
RAM doesn't use more or less power depending on whether or not it's been allocated to an application, so by itself continual/static RAM usage doesn't effect battery life at all. Now, if the OS needs to remove a suspended application from memory in order to free up RAM for a foreground application, that will involve the processor and so use some power, although I would imagine a small amount. If a suspended application is removed from memory and then needs to be restarted when it is next used, that will also use the processor (and the flash storage), which will require power. So leaving memory allocated for suspended apps can have an effect of battery life, although not directly because of the memory itself using power.

EGreg 15y ago

Not exactly true - for example I can force-quit apps using the multitasking bar.

robmcm 15y ago

My only exception to this rule is with the memory. Safari uses avaliable memory for caching web pages in tabs, which is understandably at a low priority. I often find that iOS will give priority to 'suspended' apps rather than 'suspended' tabs. In order to get safari to stop upnloading the tabs you need to free up memory manually. This however is an edge case.

buff-a 15y ago

There is one iOS "tip" that I keep hearing and it is wrong. I've never heard this "tip" from anyone. Ever. Any links or references to these "supposedly authoritative sources"? I'm finding it hard to take this article seriously when it says: "When you press the home button, iOS will tell the app to quit. In almost all cases, it quits..." Then, a few paragraphs later: "When you press the home button, the app moves from Active to Background. Most apps usually then go from Background to Suspended in a matter of seconds." Wait, I thought you said it gets told to quit? According to this [1], an app has to specifically request to be killed when the home button is pressed. "When the value of this key is YES, the application is terminated and purged from memory instead of moved to the background. If this key is not present, or is set to NO, the application moves to the background as usual." The information in the article about states is useful, but why open with factually incorrect information? [1] http://developer.apple.com/library/IOs/#documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html http://developer.apple.com/library/IOs/#documentation/Genera...

jakobe 15y ago
I have also heard that tip plenty of times, but it's difficult to give links and references to real life conversations :). Anyway, the UIApplicationExitsOnSuspend key is for legacy apps, and has nothing to do with the article. If that key is set to YES, iOS treats your app as it did before 4.0 and restarts the app every time you switch away from it and back again. The article explains how it works on iOS 4.0 and later.
dextorious 15y ago
"""I've never heard this "tip" from anyone. Ever.""" And you're the golden standard of iPhone-related tips awareness, because?
- buff-a 15y ago
  I have an android and an iPhone. I was recommended task killer for android by the guy in the verizon store. The next guy in the verizon store when I went back and mentioned battery life while I was buying a car charger. My friends with android phones. Teh Internet. I have purchased 8 iOS devices and I know more people with iPhones than android. This was the first I've heard of it. It was not my intention to suggest that I am the authority on iPhone tips. I was merely expressing my surprise that after hearing a similar suggestion practically every damn conversation I have about my Droid, that I had not heard such a thing about iPhone.

pbreit 15y ago

This article is at least disingenuous and probably flat out wrong. As many have pointed out, "running" apps are not impact-less. The author says as much himself. The author also acknowledges that being "well-written" matters which we of course know is not always the case. The author oddly brushes off the impact of long running background apps. And simply wrong is the contention that the multitasking bar is merely recently used apps.