Misconceptions About iOS Multitasking

http://speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html

by JoelMcCracken • 15 years ago

205 84 15 years ago

arn• 15 years ago

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

glhaynes3• 15 years 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• 15 years 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.

ghshephard9• 15 years 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. "

MBCook2• 15 years 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.

masklinn5• 15 years 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?)

r00fus• 15 years 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• 15 years 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.

masklinn5• 15 years 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• 15 years 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.

saurik2• 15 years 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.

phil2• 15 years ago

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

phil2• 15 years ago

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.

masklinn5• 15 years ago

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

MaxGabriel• 15 years ago

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.

dvanduzer2• 15 years 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.

RandallBrown2• 15 years 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• 15 years ago

It's a kill -9.

Brajeshwar• 15 years 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/

RandallBrown2• 15 years 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.

ghshephard9• 15 years 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• 15 years 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.

ghshephard9• 15 years 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.

ryannielsen• 15 years ago

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

swanson• 15 years 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• 15 years ago

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

gavingmiller2• 15 years 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.

gavingmiller2• 15 years 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• 15 years 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• 15 years ago

Yes.

keeperofdakeys• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years ago

I miss Symbian :(

cschep• 15 years ago

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

hamedh• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years ago

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

robmcm• 15 years 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-a3• 15 years 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/Genera...

jakobe• 15 years 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• 15 years ago

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

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

buff-a3• 15 years 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.

ugh2• 15 years ago

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-a3• 15 years ago

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.

pbreit• 15 years 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.

Misconceptions About iOS Multitasking

Related Stories