Public Service Announcement: You Should Not Force Quit Apps on iOS (daringfireball.net) 285
John Gruber, writing for DaringFireball: The single biggest misconception about iOS is that it's good digital hygiene to force quit apps that you aren't using. The idea is that apps in the background are locking up unnecessary RAM and consuming unnecessary CPU cycles, thus hurting performance and wasting battery life. That's not how iOS works. The iOS system is designed so that none of the above justifications for force quitting are true. Apps in the background are effectively "frozen", severely limiting what they can do in the background and freeing up the RAM they were using. iOS is really, really good at this. It is so good at this that unfreezing a frozen app takes up way less CPU (and energy) than relaunching an app that had been force quit. Not only does force quitting your apps not help, it actually hurts. Your battery life will be worse and it will take much longer to switch apps if you force quit apps in the background. [...] In fact, apps frozen in the background on iOS unfreeze so quickly that I think it actually helps perpetuate the myth that you should force quit them: if you're worried that background apps are draining your battery and you see how quickly they load from the background, it's a reasonable assumption to believe that they never stopped running. But they do. They really do get frozen, the RAM they were using really does get reclaimed by the system, and they really do unfreeze and come back to life that quickly.
Baloney (Score:4, Insightful)
Re:Baloney (Score:5, Informative)
Or so they say
In practice, people who didn't know how to quit apps had shitty battery life... which stopped when they started closing apps.
Maybe newer iOS versions are better, however it has been very obvious through experimentation that closing apps helps performance.
Re:Baloney (Score:5, Interesting)
5 or so years ago, it was definitely clear that leaving apps open was causing battery drain, and I obsessively closed everything as soon as I was done.
About a year ago I heard someone from Apple suggest it wasn't necessary any longer, and for the most part I leave things up and it seems to be true that they're not tremendous battery hogs.
Except Google Maps, of course. That burns through something like 1% of my battery every minute, and definitely keeps working even in the background. I will look stuff up, kill it, and repeat as necessary many times over rather than leaving it open any longer than I need to.
Re:Baloney (Score:5, Informative)
You can turn this behavior off in the settings so it will not continue running and using GPS when not in the foreground. So check the settings and be free! :D
Re: (Score:2)
Does anyone know why activating the iPhone's GPS receiver causes such a significant battery drain?
(In my naive imagining, it shouldn't take a lot of power to simply receive a GPS signal -- rendering an animated map could be expensive, of course, but Google Maps doesn't need to do that if it's running in the background)
Re:Baloney (Score:4, Insightful)
Why there have beeen tremendous amounts in rendering speeds and all kinds of image processing, but not in the calculation of these GPS coordinates, that is a mystery to me as well.
Re:Baloney (Score:5, Informative)
The calculations aren't processor intensive, they're really quite easy. The battery drain is from the radio receivers, which are amped up to distinguish the really weak GPS signal from all the noise with the really small antennas built into the phone.
Re:Baloney (Score:5, Informative)
Because:
1. it needs to power a separate radio to receive the GPS signals.
2. GPS sends out almanac data (rough position information) and ephemeris data (orbital information)
3. Your device needs to calculate the tragetory and position, and lock on to 4 satellites (3 for psotion, 1 for time) using this data
4. You device then needs to calcutate the total time-delta, to the nanosecond, between the time each satellite sends a message, and when you receive it.
5. ** Using this time delta, you can calculate your exact distance to each satellite.
6. Solve three overlapping sphere equations to triangulate your position at the ground.
7. Solve another equations using 4 satellites to calculate the equivalent atomic clock time.
Your device is processing dozens of messages per second, to keep the locks on each GPS satellite, to switch active satellites as you move out of view of any given satellite, and to keep your calculated position, and delta position (speed) all in sync.
It's very computationally expensive, and thus takes power to operate the chipset doing all this work.
In addition, if you're in a city, without clear line-of-sight to enough satellites, it can boost the power and try to make sense of fainter data, or try harder to calculate which satellites are in theory overhead, and then to obtain a lock on each satellite and it's orbital trajectory and speed. Net result: GPS uses more battery in cities than in countryside.
Re:Baloney (Score:5, Insightful)
My old hand held gps could run over 60 hours tracking my position, recording it along with the precision, number of satellites used to receive it, and some other data to my SD card, sometime displaying the local map and my recent track, all while only using 2 1.5V 1600mAh batteries, using 12 years old technology. iPhones & android devices GPS positionning is much less precise than this old device, and use much more power. WTH.
Re: (Score:2)
My guess is that the hand-held GPS had a larger, more sensitive, frequency specific antenna than your phone does. As such it needs a much smaller (or even no amp) to receive the GPS radio signals.
Re: (Score:2)
And yet, my u-Blox NEO-M8T module can receive GPS, GLONASS, and Galileo signals simultaneously, compute a fix, and provide a timing signal +/- 50ns, and still draws less than 67 mA as an absolute maximum. GPS ASICs use surprisingly little power.
Assuming the iPhone battery is 2000 mAh and isn't using other power (a poor assumption, but we'll go with it), the battery has enough energy to power such a GPS receiver for over a day.
Let's say someone uses their iPhone enough to drain the battery in 12 hours. That'
Re:Baloney (Score:5, Informative)
Utter bullshit. A GlobalTop FGPMMOPA6H standalone complete GPS module (as used in, e.g., the Adafruit Ultimate GPS breakout) draws 25 mA at 3.3 v during acquisition, and 20 mA at 3.3 v while tracking. And it does all those same things you list. "Very computationally expensive", my ass. All the analog and digital stuff is run off a single tiny MediaTek chip MT3339, which includes a radio and an ARM7EJ-S core. The processor clock runs at no more than 98 MHz.
If you have a 2000 mAh battery, it ought to run the entire GPS load, minus display mapping, for 100 hours. You shouldn't be able to detect any effect at all in "minutes".
That's a lot of extrapolation there. (Score:4, Insightful)
"Dozens of calculations per second" hasn't been considered computationally expensive for about _40_years_.
The iPhone 7 contains a motion coprocessor chip that performs these calculations and tens of thousands more every second, using a vanishingly small amount of power. Positional data from wifi networks, cell towers, GPS, GLONASS, the compass, and the inertial sensors inside the phone is combined when and where available automatically. What isn't needed is powered down.
Even if getting accurate GPS data is harder in cities, it is irrelevant, given that cities contain way more cell towers and way more wifi networks, and the iPhone knows its position from those automatically in the course of normal operation without even needing to query GPS. ... which it does anyway because the power involved is, again, miniscule. Seriously: If the phone can detect three cell towers - practically a given in any good-sized city - it knows where it is just by being a phone. Ten years ago cell towers didn't provide the necessary positional and timing information for this to be so. Now they almost always do.
Let's all have some more humility here. Knowing something about GPS does not make us experts in the design of the most bleeding-edge mass communications tool on the planet, and/or the networks that drive it.
Re: (Score:2)
The iPhone has a BCM4774 [techinsights.com] chip to handle the GPS. It's a low power GPS chip [broadcom.com].
There has been a specific GPS chip since the iPhone 3G.
Re: (Score:2)
Nothing to do with the iPhone. GPS receivers are active receivers that do a LOT of signal processing. The GPS signals were designed to beam through the atmosphere to fixed ground devices usually with very chunky or permanent supplies.
Power use didn't feature in the design conditions. A lot of modern EM design puts a lot of effort into the low-power portion of how to transmit, receive, encode and decode signals.
Re: (Score:3)
Nothing to do with the iPhone.
Indeed. I have a Samsung Galaxy V, and it sucks power when the GPS is on. I only turn on GPS with I am actively using the map app.
Re: (Score:2)
It is not the GPS signal, it is an App running wild and hanging in the background doing some nasty JavaScript shit.
The GPS chip is build in into the cellular network chip, so it is basically running all the time if you have a cellular network on your iPad/iPhone or its no true GPS but resting on WIFI/WLAN scanning.
Re: (Score:2)
I don't know about iOS, but the Android phones I've used definitely don't have a GPS lock going all the time. In fact, I've seen it take a minute or two to get a lock, and even then it keeps chatting with the satellites to narrow down your location. That's got to be power hungry by itself, but in the meantime, Google Maps is undoubtedly using WiFi and cellular triangulation to get a preliminary result. All that network traffic is bound to burn some battery.
Re: (Score:3)
As phones became more powerful, applications were using more battery. So people were all over the manual ways to preserve battery life. Software development on the relatively new phone OSes matured, and thus was able to move on to tackle "later" generation features like power-saving and efficiency (and the hardware became more efficient too, like the BT and GPS chipsets.)
Users usually lag behind stuff like this, and end up with habits of things they used to have to do long after the problem has been largely
Re: (Score:2, Informative)
Early iPhones didn't run apps in the background AT ALL. SO they definately couldn't waste power. When Apple introduced background processing it was under very tight constraints. Very limited things they could do. Any attempt to just keep running resulted in the app being terminated by the OS after a few seconds.
A few cheated by keeping themselves open in the background supposedly streaming audio when they weren't. But Apple jumped on that pretty quickly.
There's never bee a problem with background apps eatin
Re: (Score:2)
There's never bee a problem with background apps eating up batteries on iOS.
Never say never.
My iPhone 4 showed terrible battery life a few weeks after I received it. I was having to charge it far more often then when I first had it. Then I discovered that EVERY SINGLE APP I EVER OPENED WAS STILL IN THE BACKGROUND! I had dozens of apps 'frozen', because I tired every app that came with the iPhone, and downloaded several more. Force quitting dozens of these apps solved the battery problem.
And lest you think that was some 'placebo effect', I also had an issue with some apps tha
If an app *may* be wasting resources -- (Score:2)
then I have to treat it like it will and will force quit it. Unless I have a way to know that the app is definitely for sure not actively using resources, which currently I don't.
Re: (Score:3)
It still is. It only makes no difference on the majority of apps, but a few apps are allowed to do things in the background and are very battery costly to not close. How are people supposed to know which apps are effectively frozen and which are hogs?
Re: Baloney (Score:2)
>how are peole supposed to know which apps
settings>general>usage>battery
More to the point.. Tracking.. (Score:3)
The reason we keep being told 'dont force close you apps' is that if you do, they cannot continue to do 'their thing' quietly in the background.
Their thing is often reporting things back to their developers - your position, actions, etc, etc..
THAT is why every now and then they remind us how foolish we would be not to keep them running.
Re: (Score:2)
I don't believe it's that cut and dried. I've had too many experiences where I get a warning, long after I stopped actively using a particular app, along the lines of "Waze still using your location in the background - do you want to let it continue?"
I expect that Gruber's description accurately depicts how it is supposed to work - and how it does work most of the time. And perhaps there indeed are people who "force quit" iOS apps on a regular basis for no good reason. But the few times I've seen someone do
Re: (Score:2)
My girlfriend is one of those people that habitually closes everything on her phone. She then complains when the "smart lock" on my front door won't open for her, because the app that controls it is no longer running, and can't make a Bluetooth LE connection to the lock to verify the crypto key.
Don't know how many times I've told her not to close all the apps - it's unnecessary since about iOS 7 except for badly behaved apps, and things actually work better if you don't.
Re: Baloney (Score:2)
Re: (Score:3)
Apple has a few categories of apps that don't completely freeze up - e.g., apps that are VoIP related, audio related, location related. For these apps, iOS will let them run a background thread so they can continue to listen for calls (or handle the current call in progress), continue t
Re: (Score:2)
In the case of iOS it means that they're given 0 CPU cycles by the scheduler, and they're marked as available to be jetsamed from RAM on an LRU basis.
Re: (Score:2)
Re: (Score:2)
* jetsamed
It's a technical term on iOS meaning killed due to being in the background and there being a need for memory.
Re: (Score:3)
Re:Baloney (Score:4, Interesting)
You would be imagining incorrectly then.
iOS has not had to "fake" multi-tasking for quite a few versions now. Why base your imaginings on that?
iOS now selectively freezes applications on a per-thread basis, depending on the services identified as being handled by each thread, and orders the app to save state preparatory to being potentially killed shortly after is has been backgrounded in the UI. This effectively makes most apps flash-frozen in RAM, and all apps instantly killable on-demand if memory pressure demands it.
Going into the app switcher and "killing" them just wastes your time, and your device's battery, sending deallocation commands to things that are only there because the RAM hasn't been requested for anything else yet, or even worse, just loading the saved thumbnail images of the last seen state of an app that has ALREADY been deallocated (eating up some of your RAM as it does so) so you can flick your thumb upward on them and remove them from the list. There is honestly no point to this exercise except to indulge your OCD.
The real savings is in the designated threads for designated services: They are policed. A thread that is allowed to continue running in order to keep playing you music, for example, is actually disallowed from claiming more than a certain percentage of CPU time, and disallowed from accessing certain frameworks.
That said, some applications try to abuse this. A few versions and iOS updates back, there was a furor over the way Facebook behaved when it was backgrounded. It actually spun up a fake "music" thread, playing dead silence, and used it to fetch more network data than it was otherwise allowed, which in turn drained battery faster.
If you suspect there are apps doing nefarious crap like this, go to settings > general > usage > battery and look at the statistics. The culprit in your declining battery will be shown right there. If you want you can hit a few switches and deny that app all background activity.
Re: (Score:3)
No data, no point.
Re:Baloney (Score:5, Insightful)
The purpose to kill the apps may not be to save battery life, but to limit spying.
Re: (Score:2)
They ARE frozen, just with some exceptions. Like some download apps are allowed to stay awake for a limited time. Music apps are allowed to play (duh, or you couldn't listen) and some GPS apps are allowed to track you on their map. So for most apps, they are utterly frozen. But some classes of apps are not. But the advice in the main article is mostly right.
Re: Baloney (Score:2)
Why do they care? (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Because then you'd be using resources to open every single app, many of which you may not ever end up using, which would also be wasteful of battery power.
Re: (Score:2)
There's something to be said for doing this when the user does have the spare storage space to handle it. If the storage space becomes needed, the OS can freely kill processes that never ran in the first place to recover storage.
Re: (Score:2)
Because I boot my jone only once or twice a year and have about 200 Apps on it?
When I reboot it, chances are: I need it! And don't want to wait for 200 Apps to load.
Re:Why do they care? (Score:4, Interesting)
In my experience, iOS' "Low Power Mode" works extremely well in terms of extending a phone's remaining battery life. Of course, one of the things it does is stop the background execution of most apps.
Re: (Score:2)
Re:Why do they care? (Score:5, Insightful)
It's not saying they don't want you to. It is saying that the reason you are doing it, may not be as valid as you might expect.
Re:Why do they care? (Score:5, Insightful)
If you're killing apps to save battery life, you're probably right--it's not making much of a difference.
If you're killing apps because they insist that they need to know where you are--even when they are not the foreground app--then it's certainly making a difference.
Re: (Score:3)
Just set permissions. Every app that uses GPS has an entry in the system settings/privacy/location services list. The options are Always/While-using/Never.
There is no reason to quit apps in the backgroud.
Re: (Score:2, Informative)
Re-opening it takes more power than unpausing it from the background. Like, the difference between hibernating and rebooting your entire computer. Applications do a lot of work when they are booted from an initial state vs coming back from sleeping. I guess your argument is that they should be designed to boot from initial state as efficiently as possible. In general, that's going to be a goal of the developer, but it'll never be as efficient as coming back from a state when some of the work performed when
Re: (Score:2)
Re: (Score:2)
Not really. But what's important is that you do whatever helps you *feel* good, because lord knows that users always know better. ;)
Re: (Score:2)
Really? There are some apps that take a good 10 seconds or so to become useable. It's assumed that it's not just on a 10 second timer, but actually doing things - running something on the CPU, moving information across a network, SSD I/O, etc.
Unpausing doesn't do this for the most part, and is usually rather instant on modern hardware.
Re: (Score:2, Interesting)
Force quit is there because sometimes you need to do it.
The OS is good, but it's not magic. It can't always tell if an app somebody else coded is in an inconsistent or errored state.
There's a lot of uninformed computer voodoo that users buy in to. One of them is that force quiting background apps is a good idea. If there's any real benefit it's in their head.
iOS is /really/ good at suspending apps. I've had apps keep their state /between iOS upgrades/ - Exited a game, and came back to it weeks later after a
Re: (Score:2)
And don't forget to wear a tin-foil beanie whilst using it. Can't be too careful after all.
Re: (Score:2)
Why have a non-frozen closed state at all?
For apps you don't use. What's your insinuation here, that every app you have installed you use at least once during one powered on cycle of your phone?
Re: (Score:2)
If iOS is SO good at managing memory & other resources such that an app in this 'frozen state' uses 0 resources why not just 'auto launch' ALL apps when the device is rebooted to put them in this state?
It's the difference between RAM and "disk" (SSD) storage... you almost certainly don't have enough RAM to have all your apps loaded into it at once.
Re: (Score:2)
Virtual Memory is a 1960's invention.
Where's Task Manager for iOS? (Score:3, Funny)
I was going to press control-alt-delete to bring it up, but I couldn't figure out how to plug in a keyboard... ;)
Re: (Score:2)
I was going to press control-alt-delete to bring it up, ...
It's an Apple product, so that should be command-alt-delete. :-P
Re: (Score:2)
Actually it is command+alt+ ESC.
Distinctly untrue, despite the hype (Score:5, Interesting)
Re:Distinctly untrue, despite the hype (Score:4, Interesting)
Sometimes an app doesn't seem to be suspended completely and parts of it keep running. A few years ago the Facebook app was notorious for this: if you didn't force-quit the app it would often suck the battery dry in a couple of hours. This would happen sometimes even with apps that were not designed to run in the background, i.e. track your location or keep an ear out for certain events. But those few cases aside, the guy is right: in almost all cases it makes no sense force-quitting an app; just going back to the home screen will make it suspend all activity. And over the years iOS has gotten a bit better at suspending apps.
App developers have to do very little to make this happen: threads are stopped automatically after a while, the app gets notified so that it can wrap up stuff and save the device state, free up memory if possible, and so on. And even if you don't free up that memory like a good little boy, the phone will do it for you... pretty much by force-quiting your app when needed. Not ideal, but as a developer you have the choice of either releasing memory or just let the app die when the phone needs it.
Re: (Score:2)
Turns out location sensing has nothing to do with RAM usage, so your comment is a non sequitur.
Re: (Score:2)
Yeah, I agree. Apps in the background may be largely frozen most of the time, but they can still be doing some stuff. They might be using the GPS. They might be downloading stuff. In fact, there was a bit of a dust-up a year or two ago because Facebook had designed their app to constantly download what was basically an empty file. I don't know all the technical details, but by constantly downloading a file, it kept the app from really freezing in the background, which meant that the app was able to upd
Use a mock location app set to your preferred loca (Score:2)
Use a mock location app set to your preferred location, this is what I do on Android, works fine for me and no battery hassles.
Re:Distinctly untrue, despite the hype (Score:5, Informative)
This is the number one reason I force quite an apps. A bunch of location-using apps I use must be force-quit in order for them to stop using my location.
Go to Settings -> General -> Background App Refresh and disallow any applications which you don't want to let run in the background... which is probably most of them.
It's a bit irritating that, for most apps, running in the background is enabled by default. There are very few which really need to do that.
Oh, and you may need to occasionally do that again. I've seen all those toggles get re-enabled after certain updates.
The struggle for battler life is real. (Score:2, Funny)
Mr. Gruber must not actually own an iPhone.
Re: (Score:3)
Gruber has owned and I believe still owns, every generation of iPhone.
He just hasn't fallen for the placebo that you have. There really is no benefit to routinely killing background apps. It's pure ignorance of how iOS works.
Re: (Score:2)
Gruber has owned and I believe still owns, every generation of iPhone.
He just hasn't fallen for the placebo that you have. There really is no benefit to routinely killing background apps. It's pure ignorance of how iOS works.
Unless it is a map app, or app playing music, or app recording........ So it is a placebo for most apps, but for an important handfull of apps it is really important that you close them or they will use a LOT of power (GPS is costlyin battery).
So... You have fallen for the emperors new clothes and never realized everybody else was right.
Whatever.... (Score:3)
Re: (Score:2)
I think I've got a grand total of two apps which are enabled for background app refresh.
Re: (Score:2)
I'll bet you keep Grindr and the Chick-fil-A coupon app going, right?
Close but not cigar. Kindle [amzn.to] and email.
Don't tell me what to do (Score:2)
Re: (Score:2)
The list is ordered based on how recently you have used the app. If you don't use an app much, then the apps you use more often move to the front of the list automatically.
Performance lies (Score:2)
There might be a discussion for bootups eating battery, but if you want an app to have performance RAM (and everyone writes their "mobile" bloatstains to waste plenty) you'll need to close recent apps. Not older ones, since iOS will silently kill those sessions (the slot in Recent becomes a placebo) as it desires. Hope it wasn't anything important.
This only matters for limited cases, say a phone game. And probably affects you less if you're overpaying (either for a laughable contract or the $800 iSubscripti
Re: (Score:2)
'if you want an app to have performance RAM (and everyone writes their "mobile" bloatstains to waste plenty) you'll need to close recent apps. Not older ones, since iOS will silently kill those sessions (the slot in Recent becomes a placebo) as it desires. '
If the foreground app needs more RAM, iOS will suspend more and more old apps anyway. The different is that if you do it manually you also kill the running state of the app so when you reopen it you have the restart the app from the beginning.
No worries about RAM and CPU (Score:2)
Asinine (Score:2)
This is asinine. And it's made worse by the fact that when you do use the app-switcher to switch to an open-in-the-background app, it's actually showing you a screenshot of the app as it was sometime prior to it getting frozen. When I reactivate the calculator app (not from a force-click, but open in the background), it shows a screenshot of calculator and I start tapping the numbers, but then the app actually becomes active and many of my taps were missed. I'd like it better if it showed a loading scree
Re: (Score:2)
it's amazing how computers got 1000x faster in the last 20 years, yet GUI elements seem to have the same lag profile as a generation ago :-/
Twenty years ago, a handheld device was a Game Boy Pocket. Nowadays, people expect more out of a GUI:
Proportional (not monospace) fonts
Scalable fonts
Languages with larger character sets than US ASCII
Higher pixel densities and bit depths than ~96dpi 2bpp grayscale
Gradients as cues for what can be pressed
Slide and zoom animations to reinforce the relationships among different activities rather than reliance on cutting from one screen to the next
Why can't the user have control? (Score:5, Insightful)
I use an Android phone. Aside from some small, personal apps I wrote for myself a while ago, I am not really an app developer and don't have an in-depth understanding of the issues.
But my annoyance is this: there are apps that I only use once a month and others not even that. I definitely don't need them running in any form, even with the lightest footprint and some of them are consuming power. They keep coming back the instant I killed them. Why do the modern OS vendors assume they know best? I would like to have control over the execution policy, not the app developer. In Windows, I could remove entries from the startup, task scheduler etc. In Unix, I have full control. Why can't I do that in modern operating systems? Yes, I am aware there are startup editors in Android. I found them unreliable or inadequate.
I as the user, have much better context information on how my apps need to run. Sure, people can shoot themselves in the foot, but provide a means to restore defaults when custom configurations aren't working, but don't take away control altogether.
Every commercial app developer wants his app to be ready to go. In Windows that meant far too many developers would add their apps to system startup. With enough such entries, it made a large proportion of consumer machines to go sluggish by swapping and many systems were upgraded just because the users did not know how to clean up their startup items. Sure, the modern systems prevent all that, but that does not mean I should not have any control. The lesson here is that developers cannot be trusted to be respectful of shared system resources (and so the OS takes over more control), not that the users cannot be trusted. At least, let the apps be better controlled in developer mode. It took what 5 or 6 versions before Google started allowing users to rescind permissions? I want more permissions (and with better granularity) to rescind.
Well, that was my rant. If I missed any obvious solutions, enlighten me.
Re:Why can't the user have control? (Score:5, Insightful)
This is about iPhones, not Androids. They work completely differently as regards background apps.
Measure it (Score:4, Interesting)
Battery life is no problem (Score:2)
I'll just hook my iPhone up to this power outlet at the gas stat--BOOM! MacGruber!
Anyone else use the Shopify POS App? (Score:2)
Another example to doubt this claim: if anyone uses the Shopify POS App, you probably see that as you do more transactions with the swiper, the app gets slower and slower...and if you close and restart the app, it works fine again. Maybe this is true with some Apps, but I don't think you can say with all Apps...
Bull. (Score:2)
I call bullshit. Leave Slack - which has NO notifications enabled, nor any other features allowed, alive overnight and check battery usage the next day and explain how a "frozen" app can take that much electricity.
ALWAYS force-quit Slack and other energy-hungry apps when you're not using them.
This is true for EVERY modern OS (Score:2)
Sure, for older OS versions, you may have found a hack or trick that improved your experience. So you got used to using it. But guess what? Over the years the developers have been iteratively improving their products. And they are aware of the issue you had in the first place, and probably fixed it a long time ago. Plus you now have better hardware than you did, relaxing many of the limits you were running into before. Trust that the designers of operating systems aren't relying on you to go and do manual p
That's what they all say (Score:4, Informative)
The same basic advice has been peddled and widely ignored by end users who know better across all major mobile platforms. The reality is this is only true for apps don't take advantage of facilities to sidestep background execution restrictions.
Many app intentionally seek to run continuously in the background to enable persistent stalking and download ads as these activities yield profits for app vendors. It should go without saying facilities exist across all major platforms to accommodate.
https://developer.apple.com/li... [apple.com]
Absolute garbage advice (Score:3)
Back when I got my first iPhone (4), started trying out all of the apps it came with, and downloading a few new ones. After about a week or two, I noticed that the battery wasn't lasting as long. This is when I discovered how to view all of the apps that were still... frozen?... in the background. There were dozens of these. I force quit them all, made sure to force quit when I was done with an app, and the battery life went back to normal.
A few years later, I started using some workout apps that time rests and breaks in my routine. I usually used these at night before bed. Over time, I noticed that if I ever left these apps open, the battery would be dead or near dead the next morning, even if the battery was full when I went to sleep.
Apple needs to stop tell us that those background apps don't need to be closed, because they sound like idiots every time they say it.
BULLSHIT (Score:2)
The very second you load Apple Maps and put it in the background, the GPS is still sucking the fuck out of your battery life, navigating somewhere or not.
That alone proves Apple is full of shit and lying.
ALWAYS kill your maps application after you're done using it, or you're going to quickly find yourself with far less battery life than you thought you had.
Same in Windows 8 (Score:2)
SIGKILL (Score:2)
Three years ago, out of curiosity, my colleague and I had a look to see what iPhones were doing from the OS BSD perspective. One thing we found was that to maintain stability processes were sent a SIGKILL to terminate them. It seemed like a hack, however probably reasonable for CPU bound processes. That's why it is good.
The rules remain that if these processes are blocked on I/O the will be unkillable and consume resources until it is restarted.
Re: (Score:2)
How is it a hack to kill processes with SIGKILL? That's the completely correct way to kill a process on UNIX.
Re: (Score:2)
How is it a hack to kill processes with SIGKILL? That's the completely correct way to kill a process on UNIX.
Did you even read what I wrote: It seemed like a hack, however probably reasonable for CPU bound processes. I said it for a specific reason because whilst reasonable, it is not the correct way.
The correct way is to use SIGTERM first to give the process a chance to clean up, flush i/o and exit so the process does not become a zombie. After that, if the process does not respond, you apply SIGKILL.
A) BS B)This is about privacy (Score:2)
I hate that I have to use facebook messenger to communicate with certain people. I 100% do not trust that crap to run in the background and not pul
You SHOULD Force Quit Apps on iOS (Score:2)
It is good practice for consistence.
If even a single app broke the frozen state or took resources from the iphone, the reason to not force quit apps is already null. Not to mention that older iOS version might not be able to do that at all.
In addition, most users who don't keep force quit apps maintain a FULL running app list of all of their apps. Unless the iOS can ensure none of them will affect the user iphone performance, it is not good practice to tell users not force quit apps.
Re: (Score:2)
The point was don't force quit apps to save battery life. If you want to force quit apps because you're paranoid, then go for it.
Might as well turn the phone off tho - how do you know force quitting apps actually stops it? How do you trust anything at all on your phone if you don't trust that an app does what the developer publishes that it does?
Re: (Score:2)
And that misbehavior has nothing to do with the RAM usage. Th epost is about the claim that you need to manually kill apps to manage RAM usage.
Re: (Score:2)
Attempting to mirror every single RAM write to an SSD within 100 ms would wear out an SSD fairly quickly and dramatically slow down certain common computations. Watch any game for an Xbox console become a slideshow, for example.
Re: (Score:2)
With which apps have you noticed this? If you can narrow it down to one, have you tried turning off the app's background sync or location use permission in Settings?