
Misconceptions About iOS Multitasking - JoelMcCracken
http://speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html
======
masklinn
> 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
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
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.

~~~
masklinn
> 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...](http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW49)

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

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

------
arn
Steve Jobs email addressed this in an email:
[http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multita...](http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multitasking_just_use_it_as_designed_and_youll_be_happy/)

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

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

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

~~~
keeperofdakeys
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
Also, Android opens all of this information up for developers via apis, so you
can only imagine the plethora of great task managers available...

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

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

------
swanson
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
The simulator can simulate a low-memory warning. To simulate an app being
killed, just kill the app from Xcode.

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

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

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

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

------
Brajeshwar
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/>

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

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

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

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

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

------
dools
I miss Symbian :(

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

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

------
buff-a
_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...](http://developer.apple.com/library/IOs/#documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html)

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

~~~
buff-a
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.

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

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

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

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

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

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

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

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

