Misconceptions About iOS Multitasking | Hacker News Reader

Misconceptions About iOS Multitasking

speirs.org

205 pointsJoelMcCracken86 comments

> 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.

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.

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.

> 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)

According to the iOS Application Programming Guide[0],

> Suspended apps are not notified of termination but f your app is currently running in the background state (and not suspended), the system calls the applicationWillTerminate: method of your app delegate.

(this is the iOS5 doc, but the iOS 4 version essentially said the same thing)

So a suspended app is killed immediately, a running (backgrounded) app gets the standard applicationWillTerminate: message.

[0] http://developer.apple.com/library/ios/#documentation/iPhone...

I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory.

Because of that, the likely effect of informing swapped-out processes that they will be killed is an avalanche of suspend/unsuspend events, resulting in an unresponsive sytem, similar to the effect of VM trashing.

> I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory.

Even more so as a suspended application already got a message indicating that it was suspended, so it already had the opportunity to perform operations it needs to perform (mostly persisting state).

> Because of that, the likely effect of informing swapped-out processes

iOS does not swap, the VM only ever uses real memory, suspended processes live fully in real memory.

I know the Pandora app will sometimes delete playing history between times when I have it active. I have always assumed this was because of some memory early-warning system.

I feel like part of the point of this comment went un-understood: my "I'm willing to believe" aside was meant to downplay the importance of user applications; the fact that system applications do not get randomly killed when suspended means that the low-memory notification system is actually much more expensive than "kill some processes" (which, honestly, is still quite expensive, given that the detection is done asynchronously in a different process and requires a bunch of context switches, page-table flushes, and zeroing in order to reclaim that memory).

You don't get a signal handler; there's no opportunity to execute code.

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".

I'm not 100% sure, but I think this is mostly due to how memory warnings are staged.

I think the sequence is: OS sends a level 1 memory warning to any running applications. Then it starts killing backgrounded apps. If it kills 'em all and memory is still tight, running apps get level 2'ed. Then it starts killing running apps.

So a well behaved game that's running close to the capabilities of the device is likely to do a bunch of stuff that will impact its performance when it gets that level 1 warning. It's going to purge caches and otherwise free a bunch of memory, and you'll see stutter. Furthermore if Mail.app and friends are running, they are probably also going to get warned and eat some time cutting memory use.

Again, I don't know the exact cost, but I think killing suspended processes is pretty cheap and it is really the memory warnings that cause a stutter.

> Again, I don't know the exact cost, but I think killing suspended processes is pretty cheap and it is really the memory warnings that cause a stutter.

Might be, my point is mostly that iOS's application management is not as painless and transparent as TFA makes it sound, there are (edge) cases where "not managing background tasks" impacts the experience even when all applications are correctly coded and well-behaved.

Exactly. The management of background apps is FAR from being impact-less as the author gives the impression. Try leaving Skype connected and see what it does to your battery (even when you DON'T want to receive skype calls in the background).

While he's correct in stating that the multitasking bar does NOT show apps currently running (just the apps that were recently used, regardless of state), he fails to point that deleting the apps there WILL indeed move the apps from Background or Suspended to Not Running, effectively freeing memory and CPU.

And this is exactly the intention of those "authoritative sources" that he criticizes. The recommendation to kill background/suspended apps is an effective (and the only official) way to manually solve battery drain or memory on the 5% of cases that iOS can't do by itself.

When your location is being found, e.g. by the TomTom app running in the background, a purple arrow appears on the top of the screen near the battery meter. In my experience, it's pretty obvious what app is using the background GPS.

Steve Jobs email addressed this in an email: 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

regarding quitting apps to save battery life: "You don't need to do that to save battery life. Trust the iPhone."

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.

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.

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.

Steve would have wept if he could have seen that happen.

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. "

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?

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.

> 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?)

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.

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...

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.

You're right. I didn't jailbreak, but I remember having the same kind of issues. I found that Worms would run much better if I restarted the phone first, I assume because it was easier to allocate contiguous blocks of memory.

But it's a game by game thing. I don't remember ever having problems with Flight Control or Peggle. Even some fancier games don't seem effected, while Angry Birds would hit the problem. Interestingly, Angry Birds would get better if you went to the level select and then back into the level.

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.

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.

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.

Yes.

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.

Also, Android opens all of this information up for developers via apis, so you can only imagine the plethora of great task managers available...

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.

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.

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.

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.

It's a kill -9.

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.

The simulator can simulate a low-memory warning. To simulate an app being killed, just kill the app from Xcode.

The key word there is simulate. There are cases (see my response) that arise that purposely triggering these state changes could really help with.

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.

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.

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.

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.

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.

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.

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/

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.

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?

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.

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.

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.

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).

I miss Symbian :(

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

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

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/Genera...

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.

"""I've never heard this "tip" from anyone. Ever."""

And you're the golden standard of iPhone-related tips awareness, because?

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.

Really? Really?!

It’s correct. In almost all cases when you press the home button the app quits (i.e. gets suspended). End of story.

Yes, this definition of "quits" as "gets suspended" is what I have a problem with. "Quits" used to mean "terminates". I guess in the new apple world, especially given what happens on Lion, "quits" doesn't mean what I think it does.

We are not interested in meanings here, we are interested in consequences. When it comes to battery life and slowing the OS down, quitting and suspending have exactly the same consequences: both don’t do it.

You are making a distinction without a difference that’s not relevant for what the article is talking about.

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.

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.

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.

> 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.

This article is not, repeat NOT, presenting "theory". This article describes the way iOS is actually built to work -- it is a factual description of all and only those behaviors that iOS engages in. It is a complete, and accurate, description of iOS's behavior because it is a recapitulation of the behaviors that iOS's designers built it to exhibit.

The only contrast here is between the reality of the way iOS works (the article) and your misunderstandings of reality.

My understanding of reality is pretty straightforward - "Over the last 3-4 years, I normally get 36-48 hours of casual use out of my iPhone, or 24 hours of really aggressive use, but, for some reason, on some days, while my iPhone is at the home screen, it is really hot and the battery is draining to zero quickly. Shutting down all of the apps in the task bar, or, rebooting the iPhone, immediately fixes that."

Couldn't we allow for the possibility of a bug in IOS that results in a deviation from the behavior explained in the article? Or, more likely, an application that is using IOS as designed, but in a way that results in extended background processing and CPU drain?

The good news is that another contributor posted a link to "Instruments" - which should let me get a diagnostic trace off my iPhone and determine which of the apps is actually pulling down the battery. I then have the options of (A) figuring out if there is a pref in that App to cause it to stop using battery when backgrounded, (B) Contact the application writer and let them know they have a poorly behaving App, and (C) (most important for me) - Reduce the number of applications I need to shut down to just the misbehaving ones.

Until then - count me in that category of users who believes (through experience) that the advice the Apple Geniuses are giving, that is, to terminate applications when you have an iPhone that is performing differently than when it is initially booted up, is good advice and is a real-world fix to this class of problem. (Though rebooting your iPhone accomplishes the same thing in my experience as well)

> Couldn't we allow for the possibility of a bug in IOS that results in a deviation from the behavior explained in the article?

No, because there is absolutely no reason to believe this is the case and no one has ever observed a non-privleged app store approved app outliving its OS-mandated termination deadlines.

> Or, more likely, an application that is using IOS as designed, but in a way that results in extended background processing and CPU drain?

ie) there's a bug in a background process that causes it to eat CPU? Yes, this is what you are actually experiencing, and this is 100% compatible with the facts presented in this article. Accepting this means you've entirely moved away from your previous "theory vs reality" nonsense.

> Until then - count me in that category of users who believes (through experience) that the advice the Apple Geniuses are giving, that is, to terminate applications when you have an iPhone that is performing differently than when it is initially booted up, is good advice and is a real-world fix to this class of problem. (Though rebooting your iPhone accomplishes the same thing in my experience as well)

Indeed rebooting your phone will terminate all processes running on the phone. This should be pretty obvious. Clearing out a list of previously run applications willy nilly is, on the other hand, superstitious hokum. You need to specifically target only those apps with infinite background privileges, which are few and far between.

Okay - I yield msbarnett. You win.

What is your guidance when my iPhone is in battery-draining/Hot mode while at the home screen and I need to fix it? If I'm engaging in superstitious hokum by terminating all the apps in the MRU/Multi-Tasking bar, what is your advice to fixing my problem? Keep in mind, that if I've been only using the iPhone for a day or so since I last killed/removed all the apps - terminating everything in the MRU bar takes about 30 seconds versus a minute or so for a reboot.

Thanks for taking time to provide your insight on this topic - I'm looking forward (honestly) to your advice.

I'd identify the particular app that's causing your issues; instead of mass clearing out the recents list, or rebooting, slowly signal to the OS that you're done with each app, one at a time, and determine whether your phone continues to run hot and drain battery after each closure.

Eventually you'll narrow it down to the app with background privileges that's causing you grief.

Kick that app off your phone, or otherwise stop running it. If you can't live without it, then the next time your battery life goes to hell, go into the recents list and remove only the troublesome app in question, so that the OS knows you're done with it and kills its (presumably crashed or busy-looping) background thread.

Desist worrying about how many apps are in your recents list in general, because that's not a really related to the underlying problems you're experiencing.

Yes - I've tried that a number of times - the problem is you always _think_ you got the right app, but you are never 100% certain. And you are always worried that you just happened to have shut down an App, at the same time that the poorly behaving background app decided to Idle a bit.

Better solution will be for Apple to just tell us how much power each of the running apps have used in the last 1,5,10 minutes.

I agree 100% that the user _shouldn't_ have to worry about that, but when they do, it's annoying that it's so difficult to track down the problem.

Re: "Indeed rebooting your phone will terminate all processes running on the phone. This should be pretty obvious."

Not so obvious. When you reboot OS X version 10.7, it restarts all of the processes that where running when you rebooted it (and loads all of the files you were looking at) - so in that operating system, the only way to shut down an errant application is to track it down and kill it.

> Not so obvious. When you reboot OS X version 10.7, it restarts all of the processes that where running when you rebooted it (and loads all of the files you were looking at) - so in that operating system, the only way to shut down an errant application is to track it down and kill it.

Not really. 10.7 relaunches the app, but doesn't load up an image of the previously-loaded executable image and restore the program counter or anything -- after a reboot you don't get restored right back into an infinite loop bug; the program has been restarted, and the OS just asked it to re-open any files it was using before.

Yea but no program is perfect ..!! A developer could be doing something completely weird/wrong causing his app to hang and slow down IOS. The real problem are the bugs in the software not the sales guy at the Apple store. The Geniuses are just giving a "non-developer" solution to the problem.

The problem has nothing to do with theory vs reality, but rather emphasizing the wrong aspects of reality.

1) All the discussion of memory usage isn't terribly relevant. There's some stuttering while iOS kills background apps when the running app requires it, but this is not a huge problem in practice.

2) Battery life is a huge issue (which iOS still handles better than anyone else) for the average user. The article lists five classes of apps in theory and in practice can contribute to significant battery drain, yet seems to believe that's proof that this isn't a problem.

I still agree that it's bad advice from the Apple Store techs. From a technical aesthetic perspective, it would probably be better to just tell people with battery life problems to reboot the phone.

And then fix the problem. This seems to be a regression from iOS4 to iOS5. Perhaps there's a bug that's been introduced in the scheduler, or perhaps there's better logic that can be applied. There's no reason that iOS couldn't detect background processes that are exceeding a threshold of CPU usage.

The principle that users shouldn't have to manage background tasks is correct. However the fact that the technique is, in fact, effective, means that it isn't going away as a tool in the Apple tech toolbox.

Not sure why you are being down-voted. I've experienced the same thing on my iPhone. I suspect it's because a bug in one of the applications that is allowed to background indefinitely causes it to start eating up the CPU. Not sure which one, but I do occasionally need to reboot my phone when it starts getting hot and draining battery by itself.

There's no argument that an app with infinite background privileges is incapable of getting itself into a 99% CPU eating infinite loop, but that's perfectly compatible with the very accurate technical over-view of the situation given by this article and does nothing to support ghshephard's weird insinuations that the article is merely a "theory" and that iOS "in reality" behaves differently than described.

The theory I took issue with is this:

"Here is the advice - and remember it is wrong:

All those apps in the multitasking bar on your iOS device are currently active and slowing it down, filling the device's memory or using up your battery. To maximise performance and battery life, you should kill them all manually.

Wrong. Wrong. Wrong. Wrong. Wrong. Wrong. Wrong."

I am saying that in order to maximize performance and battery life you should kill all those apps in the multitasking bar manually. Or reboot your iPhone.

Anybody who complains about very bad battery life, this is the _first_ advice I give to them, and 95% of the time, it fixes all their problems. Note that very-bad battery life is defined by a battery-life measured in a few hours, and is different from the suboptimal battery life that can be remedied by double checking your bluetooth, 3G, wireless, etc... settings. It is poor battery life that can't easily be explained by user behavior.

> The theory I took issue with is this:

Again, that is not a theory.

> I am saying that in order to maximize performance and battery life you should kill all those apps in the multitasking bar manually.

Again. You are wrong. That is not a multitasking bar. Most of those apps are consuming no CPU and no memory. They are simply apps that you had, at some point previously, run. This is only solving your problem because, in the midst of superstitiously clearing out this stuff, you're stumbling across the app that is misbehaving and signalling to the app that you're done with it, at which point it kills off its own misbehaving background thread.

You're doing the equivalent of throwing out all of the food in your house when the milk goes bad; it works to eliminate the problematic food-item only by coincidence, and not for whatever magical-thinking reasons you happen to hold.

"you're stumbling across the app that is misbehaving and signalling to the app that you're done with it, at which point it kills off its own misbehaving background thread."

Yes - this most likely is precisely what I'm doing. And it works. Consistently.

I'm not sure whether you are upset that (A) I have an iPhone in which shutting down all the apps on the Multitasking/MRU/Task Switcher bar fixes its battery/CPU problems or (B) that I disagree with Speir's when he states that "To maximise performance and battery life, you should kill them all manually." is wrong, wrong, wrong.

I suspect that it's mostly (B) - I hope you'll grant me my own observation of (A).

I actually agree with 95% of your last statement - particularly the part about throwing out all of the food in the house when the milk goes bad - but I don't really have an option - no (easy) way to figure out which app is sucking all the battery.

The "Magical Thinking" statement was a bit over the top though. I think we can avoid the ad-hominen on HN and keep the discourse at a higher level.

I don't get it, are you misunderstanding intentionally so you can smugly accuse people of magical thinking? The 'theory' is that closing all the apps is a no-op. It doesn't matter that most of the article is correct, that everything it describes about mechanisms is accurate. The thesis is not properly supported by the facts.

ghshephard is not some fool performing rituals to cleanse his phone. The milk has gone bad but all the other food is useless suspended junk anyway, so it's simple to throw it all out. Yes it's overkill but it works.

Don't make the mistake of thinking that because someone is acting in overkill that they believe overkill is the only valid path. It may just be the simplest.

> I don't get it, are you misunderstanding intentionally so you can smugly accuse people of magical thinking?

I don't get it. In what sense of the word theory is an exact regurgitation of the official documentation of all and only those behaviors of a process's lifecycle a "theory"?

The great-to-the-nth-grandparent was clearly trying to discredit a factual explanation of the situation by referring to it as a theory, because said facts contradicted his anecdotal misunderstanding of the OS's operation.

Anecdotes trumping facts, and cargo cult behavior engaged in because it coincidentally produces a result are the definition of magical thinking.

The n-grandparent was not trying to discredit the facts of the article. He was discrediting the thesis that it is useless to close all applications.

The facts of the article were correct.

The thesis of the article was not correct.

The facts listed in the article said that some applications are able to run in the background.

Some application is causing battery loss. Not 'all of them', like people who are actually mistaken think, but some, like people who know the facts think.

I don't know how to explain it in a clearer way. The n-grandparent is not a cargo-culted ignorant who thinks there is a need to kill all the apps. He has one or two apps that are abusing background permission, but doesn't know which one or two. There is no 'anecdotal misunderstanding'.

You yourself agreed that the concept of a broken background app can coexist with the facts of the article. But you are conflating the thesis, the theory, with the facts. They are not one and the same. Insulting the thesis is not an attempt at discrediting the actual facts.

I apologize for ranting but redundancy can sometimes help make a point clear.

There are built-in tools to measure CPU, memory and battery usage, you simply need to have a Mac (or a 3rd party app)to get at the data. For example, here's how to get rather detailed energy diagnostic information:

http://developer.apple.com/library/mac/#documentation/Develo...

Reply on news.ycombinator.com