Apple Reiterates: Force Quitting iOS Apps Doesn’t Help Battery Life

[tomsamson]

Sad to see Craig put out such nonsense.
In his case i can see why he does it (it sounds better), but i find it horrible that now many Apple Sites reiterate this as if it was a fact.
It's total nonsense, of course Apps in the Background cost resources, as any halfway informed developer could tell you.
How many and which types of resources they need while in the background depends on whether an app uses a UIBackground mode or not and if so which one.
In iOS an app can specify it needs to use one of several UI Background Mode features, like VOIP, location, music playback etc and then can run tasks while in the background, too.
Some of those are infrequently run or only run for a short while and cost few resources, others can cost a lot of resources.
Among apps which use such ui background modes are of course app types most popular among most iOS users, like music/podcast apps, messenger/voip apps and many others.
So yes, shutting those down can considerably reduce ressource usage and hence also preserve battery life.
Then there are other aspects like even for frozen apps (ones not using such ui background mode features) keeping a memory image "alive" (so the app can be resumed from the state it was last in) takes away resources (even if not much battery usage in that case).

Besides those general technical reasons, there are also app and usage specific reasons why it is a good idea to shut down apps in the background fully in between. Like for example many newspaper apps, another app category used a lot by usual users, especially parents have wonky content download features and in between then for example the download of the latest newspaper content fails and then in many such apps there isn't even a feature to manually restart the download attempt fresh, so then the app would remain in that fail state and even be restored to that same failstate when returned from the background of course unless one fully closes the app so then one can start it fresh and trigger the download attempt fresh again. So it is actually the most common support case that when someone is stuck with such a state to just fully shut down an app so it restarts fresh again next time.

So yeah, i find it annoying Craig puts out such nonsense, and really bad that Apple sites like this one reiterate that as if it was a fact while the obvious is very clear, in many cases it is good for reducing resource usage to fully close apps in the background and in many cases it is also useful for other reasons.

 

[pappy53]

I'll take Craig's word over yours.

 

[vertsix]

Well.

I usually close all apps all the time and I decided to go a full day testing this out.

I actually got slightly worse battery life and, yes, Background App Refresh is off and usage activity stayed relatively the same before and after the test.

By closing all apps, I usually get 9-10 hours of usage.

During this test, I got 8 hours and 29 minutes.

Logically speaking, the margin of error should be around 15-30 mins considering usage is not exactly the same in both tests, but even then it is significant.

Not saying Federighi is wrong, but it's just thought it is important that I note this out because other factors can weigh in. I'm just gonna do another test without keeping any apps in RAM and confirm this.

 

[vmachiel]

Well, I'd first try to cut it off from background app refresh. Much less work than to constantly having to kill it.
[doublepost=1457657287][/doublepost]
Because you allowed the app to do background app refresh (and/or background location services access).

No I didn't allow that. I have that off for all apps.

 

[C DM]

Sad to see Craig put out such nonsense.
In his case i can see why he does it (it sounds better), but i find it horrible that now many Apple Sites reiterate this as if it was a fact.
It's total nonsense, of course Apps in the Background cost resources, as any halfway informed developer could tell you.
How many and which types of resources they need while in the background depends on whether an app uses a UIBackground mode or not and if so which one.
In iOS an app can specify it needs to use one of several UI Background Mode features, like VOIP, location, music playback etc and then can run tasks while in the background, too.
Some of those are infrequently run or only run for a short while and cost few resources, others can cost a lot of resources.
Among apps which use such ui background modes are of course app types most popular among most iOS users, like music/podcast apps, messenger/voip apps and many others.
So yes, shutting those down can considerably reduce ressource usage and hence also preserve battery life.
Then there are other aspects like even for frozen apps (ones not using such ui background mode features) keeping a memory image "alive" (so the app can be resumed from the state it was last in) takes away resources (even if not much battery usage in that case).

Besides those general technical reasons, there are also app and usage specific reasons why it is a good idea to shut down apps in the background fully in between. Like for example many newspaper apps, another app category used a lot by usual users, especially parents have wonky content download features and in between then for example the download of the latest newspaper content fails and then in many such apps there isn't even a feature to manually restart the download attempt fresh, so then the app would remain in that fail state and even be restored to that same failstate when returned from the background of course unless one fully closes the app so then one can start it fresh and trigger the download attempt fresh again. So it is actually the most common support case that when someone is stuck with such a state to just fully shut down an app so it restarts fresh again next time.

So yeah, i find it annoying Craig puts out such nonsense, and really bad that Apple sites like this one reiterate that as if it was a fact while the obvious is very clear, in many cases it is good for reducing resource usage to fully close apps in the background and in many cases it is also useful for other reasons.

As this thread shows it's pretty far from nonsense--it might not cover all cases, but it addresses the common/general one as it relates to whether or not it is "necessary".

 

[mpe]

Craig is right. Just bear in mind that he has been asked two questions:

1) does he kill multitasking apps frequently?
2) is killing of apps necessary for battery life?

he answered no and no. Both answers make sense to me.

Perhaps should he had been asked if running a poorly written app (Facebook) can have a measurable impact on battery life when run/not-run in the background he would have given a different answer.

 

[sirdir]

Still, sometimes when an app keeps crashing at start, closing some other apps helps...

 

[chriscrowlee]

If you actually read the article, you will see that what you say has already been debunked.
You are assuming that your quitting action is "free". But it is not. You are forcing the system to do some housecleaning, which 1) itself needs processing, 2) is absurd in the case of well-behaved (non-Facebook) apps that you might relaunch after a while: you kicked them out just to bring them in afterwards.

And in the case of annoying/malwarish apps like Facebook ;P, they have ways to try to come back anyway (geofences, background refresh, who-knows-what-next).

The problem I see is that once a bad player appears, like Facebook once more, then it's understandable that users get paranoic and try random things, even if it's still useless. Let's be thankful that there is no PRAM reset and Fix Permissions in iOS ;P.
Apple should really do something against the Facebook case; both closing those loopholes at the OS / App store level, and at the kicking-FB-out-for-a-while level.
[doublepost=1457685793][/doublepost]

Don't worry, you might still learn a couple more things to help you make sense of it all.

The article is written based on the comments of the email, not any facts. The comments of the email were not what the article led people to believe. This is typical yellow journalism.

"I don't support Hillary Clinton" ... so you write an article how I'm a Socialist for supporting Bernie Sanders. I never said I supported Bernie, but you assumed it as fact since the article led your brain to think if not a, b.

 

[C DM]

However small, there most certainly is benefit. Killing an app ends the process that second. By leaving it open, there is a fraction of a second where it continues to use the processor, and some apps are known to sneak in the background (ie Facebook).

The article is written based on the comments of the email, not any facts.

http://lifehacker.com/quitting-apps-in-ios-actually-worsens-battery-life-1560086834

 

[milo]

Well, somebody has to decide whether to purge older Safari tabs or older apps from memory. Somebody might prefer that when Safari is open, all other apps are purged completely from memory when needed. Others might prefer that older Safari tabs are purged instead of a recently used app (which you would have to wait to start over from scratch when you switch back to the app).

It makes sense to use "older" as a major factor, and iOS obviously has times where it doesn't do that.

I can switch back to a tab I was in seconds ago and it reloads. Then I open the app switcher and there are apps I ran a month ago and haven't touched since. When I manually quit those, then the tabs in Safari don't reload. There certainly may be cases where it's a judgement call, but iOS absolutely has times where it is favoring things that haven't been touched in ages over things that are extremely recent.

Really? You never switch back to an app used earlier and it essentially starts afresh instead of showing you exactly what it had on-screen when you left it?

I'm not saying it never quits any apps, I'm saying there are situations where it should quit apps but doesn't. And then when those apps are quit manually there's a visible performance improvement.

The question is what do you gain by keeping free memory around (on OS X you might save the time it takes to swap out existing memory when you need new memory and don't have any free memory but iOS doesn't swap out memory to disk it just deletes it)? What you loose is that if you need anything that was cleared from memory again, you have to wait for it to be read from disk, downloaded or computed.

Who's talking about keeping free memory around? I gave a specific example. When I'm switching between two tabs they reload every time. When I manually quit other apps (all of which have been used much less recently) then the tabs stay reloaded. The implication is that Safari doesn't have enough memory available to keep both tabs, and that is happening because instead of actually quitting background apps and freeing up that memory, those apps are holding onto it for whatever reason.

Apple executives can claim whatever they want, but it's hard to take seriously when actual real world use contradicts those claims. It's hard to imagine the advantage of keeping the game I played three weeks ago when that requires dumping the tab I looked at five seconds ago. It's kind of amazing this is even being debated. Just have it quit the apps that were used least recently, and keep the stuff that was used most recently. Yet it doesn't do that.

 

[mpe]

Federighi did not make any claims about memory consumption. He was answering a question about power consumption.

Of course in case of a memory pressure it could happen that an app purge its caches even before OS had a chance to kill apps in the background. That could explain the issue you see in Safari.

 

[C DM]

It makes sense to use "older" as a major factor, and iOS obviously has times where it doesn't do that.

I can switch back to a tab I was in seconds ago and it reloads. Then I open the app switcher and there are apps I ran a month ago and haven't touched since. When I manually quit those, then the tabs in Safari don't reload. There certainly may be cases where it's a judgement call, but iOS absolutely has times where it is favoring things that haven't been touched in ages over things that are extremely recent.



I'm not saying it never quits any apps, I'm saying there are situations where it should quit apps but doesn't. And then when those apps are quit manually there's a visible performance improvement.



Who's talking about keeping free memory around? I gave a specific example. When I'm switching between two tabs they reload every time. When I manually quit other apps (all of which have been used much less recently) then the tabs stay reloaded. The implication is that Safari doesn't have enough memory available to keep both tabs, and that is happening because instead of actually quitting background apps and freeing up that memory, those apps are holding onto it for whatever reason.

Apple executives can claim whatever they want, but it's hard to take seriously when actual real world use contradicts those claims. It's hard to imagine the advantage of keeping the game I played three weeks ago when that requires dumping the tab I looked at five seconds ago. It's kind of amazing this is even being debated. Just have it quit the apps that were used least recently, and keep the stuff that was used most recently. Yet it doesn't do that.

Are you saying that a game you played weeks ago is still keeping the memory that was allocated to it when it was used weeks ago, in particular when other apps are in need of more memory?

 

[lkalliance]

Actually, force-closing apps that you aren't using (that aren't running in the background anyway) might HURT your battery life; it takes more juice to relaunch the app than it takes to wake it from its frozen state.

 

[IJ Reilly]

If I run Tetris and then I swipe it to close it then it's closed. If I run Facebook and I then swipe to close it from the recent app list then it's closed. Those apps are not running or doing anything in the background or anything like that at that point.

Not really. Those apps are just as "closed" if you tap the home button. If you use the home button, the apps enter a saved suspended state, but if they include background processes that are allowed to continue, those processes will not necessarily be killed, and that is the case whether you delete the saved suspended state or not. Swiping them "closed" only forces your device to forget where you left off the last time you used that app. You can easily prove this to yourself with an exercise with Mail that I have described at least twice already.

 

[lkalliance]

I conducted some testing myself and this seems to be accurate.

- Disabling Background App Refresh <- does nothing
- Disabling Notifications (these could trigger the app to run at any time) <- does nothing
-> Facebook grabs 5-10% Battery life when used like 5 minutes during the day.

- Killing FB in Multitasking switcher directly after use + Disabled Notifications + Disabled Background App Refresh: FB uses 0% Battery Life in Background... overall down to ca. 2% with my specific usage pattern

A long time ago I just stopped using the FB app, and use my browser instead. Immediate and dramatic improvement in battery life.

 

[IJ Reilly]

Are you saying that a game you played weeks ago is still keeping the memory that was allocated to it when it was used weeks ago, in particular when other apps are in need of more memory?

Depends on what you mean by memory, but essentially, yes. iOS saves as many suspended states as it can, dumping them only as needed to make space to run other apps, prioritizing the saved states based on how often you use an app and how much space it is occupying (I believe). This is the custodial feature of iOS that you are overriding by swiping apps in the picker. Federighi says users should leave it alone and let iOS do the job for you.

 

[manu chao]

It makes sense to use "older" as a major factor, and iOS obviously has times where it doesn't do that.

I can switch back to a tab I was in seconds ago and it reloads. Then I open the app switcher and there are apps I ran a month ago and haven't touched since.

Purging an app from memory does not result in its removal from the app switcher. What you see in the app switcher is a list of recently used apps including a screen shot of the last view of the app (which can vary in size from less than 100 kB to maybe 500 kB). You cannot tell from the app switcher whether an app is still in memory.

 

[C DM]

Not really. Those apps are just as "closed" if you tap the home button. If you use the home button, the apps enter a saved suspended state, but if they include background processes that are allowed to continue, those processes will not necessarily be killed, and that is the case whether you delete the saved suspended state or not. Swiping them "closed" only forces your device to forget where you left off the last time you used that app. You can easily prove this to yourself with an exercise with Mail that I have described at least twice already.

If an app is performing a background task and you swipe it closed it will stop performing that background task. Your example of Mail references a system service/process and not a general app, which is fairly different, and certainly doesn't dismiss the examples that I have provided.
[doublepost=1457714383][/doublepost]

Depends on what you mean by memory, but essentially, yes. iOS saves as many suspended states as it can, dumping them only as needed to make space to run other apps, prioritizing the saved states based on how often you use an app and how much space it is occupying (I believe). This is the custodial feature of iOS that you are overriding by swiping apps in the picker. Federighi says users should leave it alone and let iOS do the job for you.

And thus my question to the poster I was replying to.

 

[milo]

Are you saying that a game you played weeks ago is still keeping the memory that was allocated to it when it was used weeks ago, in particular when other apps are in need of more memory?

I'm saying that when that game I played weeks ago appears in the app switcher, tabs reload. And When I quit out of that game, tabs don't reload. I can only speculate what is happening under the hood, but whatever is going on, I consistently have better performance when I manually quit that game. Manual handling of it is working better than what iOS is supposed to be doing automatically. Consistently.

Purging an app from memory does not result in its removal from the app switcher. What you see in the app switcher is a list of recently used apps including a screen shot of the last view of the app (which can vary in size from less than 100 kB to maybe 500 kB). You cannot tell from the app switcher whether an app is still in memory.

Whether it's in memory or not, the OS is doing something under the hood such that when it appears in the app switcher it negatively affects performance of an app I'm actively using. Frankly I don't care if the cause of that is memory or not, I just see in my actual use that manually quitting that app improves my user experience.

 

[coolfactor]

LOL @ thinking iPhones can't be hacked. EVERYTHING is capable of being hacked. Nice to know iPhone fanboys are still trying to smear Android. Christ, it's pathetic.

I think you misunderstand this topic that you are trying to defend. It's broadly accepted that Android is generally far easier to compromise and "hack", as you put it. You don't see the FBI taking Google to court, do you?
[doublepost=1457715970][/doublepost]

The "app quitting" myth will never die if even the article claiming to debunk the myth insists on using the term "quit" to describe what happens when you drag the app out of the picker. The app is not quit, you are deleting its saved suspended state. It's something iOS does automatically as needed even if the user never intervenes. You are likely not killing any background processes either, since apps that run many background processes will continue to do so after the saved state is deleted. If you refuse to believe it, try "quitting" Mail and then sending yourself an email from another device. Ding.

All that being said, if any given app honks up and become unresponsive, deleting its saved state is often the solution.

I think Mail is a poor example. It's an Apple app that's deeply integrated into the system. A better example would be a third-party email application.

Furthermore, the Push Notification "ding" that you speak of is part of the OS, not part of the app.

 

[IJ Reilly]

I think Mail is a poor example. It's an Apple app that's deeply integrated into the system. A better example would be a third-party email application.

Furthermore, the Push Notification "ding" that you speak of is part of the OS, not part of the app.

Test this with another app then, though it won't be quite as straight forward. Give Waze permission to track your location then delete the app's saved state and determine if it is still tracking your location. I bet iOS hasn't forgotten that you gave Waze permission to track you. In fact, if deleting a saved state terminates an app's location access rights, then that's going to happen randomly all the time because iOS deletes saved states routinely. This would effectively defeat the purpose of giving developers access to these core iOS functions.

 

[C DM]

Test this with another app then, though it won't be quite as straight forward. Give Waze permission to track your location then delete the app's saved state and determine if it is still tracking your location. I bet iOS hasn't forgotten that you gave Waze permission to track you. In fact, if deleting a saved state terminates an app's location access rights, then that's going to happen randomly all the time because iOS deletes saved states routinely. This would effectively defeat the purpose of giving developers access to these core iOS functions.

Yes, Waze will stop using location services if the app is closed. Same goes for Facebook for example where it can easily have a fair amount of background usage which woule stop if the app is closed.

 

[IJ Reilly]

Yes, Waze will stop using location services if the app is closed. Same goes for Facebook for example where it can easily have a fair amount of background usage which woule stop if the app is closed.

It sure does not stop in my experience, which is why I used Waze as an example. In fact Waze chewed up my iPhone battery mercilessly even though I never used it -- until I turned off its location services permissions, which it was happily using constantly, even though the app was never "open." The message here is we need to stop using terminology like quit, open, or closed for iOS apps, since the concepts do not actually exist in iOS.

The best plain-language explanation I've read:

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

 

[C DM]

It sure does not stop in my experience, which is why I used Waze as an example. In fact Waze chewed up my iPhone battery mercilessly even though I never used it -- until I turned off its location services permissions, which it was happily using constantly, even though the app was never "open." The message here is we need to stop using terminology like quit, open, or closed for iOS apps, since the concepts do not actually exist in iOS.

The best plain-language explanation I've read:

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

Perhaps there's something else in play in your scenario, but for most people closing Waze will stop it from running in the background as well. And certainly goes for most other apps, as we've certainly seen demonstrated by many in relation to Facebook, for example, in various threads where its background process has been discussed and that closing the app would stop it.

We can also look at yet another article about multitasking at http://appinstructor.com/blog/2014/background-app-refresh-explained that has excerpts from Apple's own support information about it all, which, in part, mention the following:

"If you force an app to quit by dragging it up from the multitasking display, it won't be able to do its background activities, such as tracking location or responding to VoIP calls, until you relaunch the app. "

[doublepost=1457725096][/doublepost]

Does anyone at MacRumors actually use Apple products or know anything about them? Force Quitting is a very specific function in OS X for quitting an app that has frozen, crashed, or is otherwise unresponsive. This article, conversely, is about simply quitting an app in iOS instead of letting it stay open in the background.

Using "Force Quit" in this context makes no sense.

Neither my iPhone 6s or my iPad Pro will show me battery usage anymore. It just tells me it will do so after using the device for a few minutes. BS. It NEVER shows battery usage. Why??



Because it's ridiculous to scroll through every app you've ever opened when going to a task switcher. As noted by another commentator, the design of the app switching is self-defeating.



Thank you!! This terminology usage bugs the crap out of me and people just don't care to be accurate.



Same experiences here.

https://support.apple.com/en-us/HT201330

 

[Wolfpup]

Does "background app refresh" actually DO anything useful? I've just kept it off, as I don't really want things sucking CPU/RAM/data in the background for no reason. I'm seriously unaware of ANYTHING useful about it.

I'm really glad for this article-I don't know how many times I've heard the claim that you should "close" background programs, and I'm like unless I'm massively misunderstanding something, they're already closed or as good as closed. Although the example about Facebook shows a poorly coded program may actually need to be closed...though in that case I guess you can find that out just by looking at the battery usage every now and again.
[doublepost=1457728739][/doublepost]

I'm not too familiar with how VoIP backgrounding works, but I believe the actual process of checking for incoming calls is handed off to iOS which then suspends your app and reawakens it when data is pushed through the channel it is expected. I think...

Edit: Yep:

Okay, yeah, that's how I thought iOS worked... A question though-are all those types of things going through Apple's notification servers? Or is it just the OS (iOS) handling the monitoring of a particular connection to a VOIP server, then waking up the proper program?