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.

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.

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.

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

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.

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.