iOS does not provide a list of open apps, it provides a list of apps that you ran at some point and have not dragged away. Any app in that list might have already been killed so the OS could reclaim the RAM it was using and hand it off to another app.
A normal iOS app gets ten wall clock seconds to do thing in after it has been backgrounded by the user, after that it gets a SIGSTOP and it does absolutely nothing. The CPU scheduler ignores it. It consumes RAM, and it has a slot in the process table. When iOS runs low on RAM jetsamd looks at all the processes and decides which to kill to free up some RAM, and it always considers stopped processes first. If I recall correctly on iOS jetsamd uses signal 9 (SIGKILL) to inform a stopped process that it needs to go away so it will not be stopped, nor does the process get a last gasp to do anything “unclever” in.
If things are far gone enough that a running process “needs” to be killed due to RAM constraints it does actually get informed and has a brief window of time to reduce memory use (and the OS will automatically release ephemeral memory allocations for you, and I think NSCache has some interaction here…and you can register your own actions to try to help out).
So most apps only have ten seconds to bit rot in (plus the time you actually use them).
That is most. Some apps can get some background permissions, especially ones that play music for you, or accept phone-call-like things. Others can get permission to process server originated events for a few seconds per-event. Navigation apps get to run in the background as well. Unfortunately I don’t think it is actually super easy to tell what apps really get to run.
However app review does at least make sure that an app that asks for “audio app background entitlements” has some sort of audio functionality. I would prefer if anything “really running” were badged in the app list.
Sure, but you could be wrong, or the app could be so small that it doesn’t need to get killed for hours and when you do go back it is still in memory!
The goal has always been to let the user see the app and figure out what they want to do next in it…and the hope was to be loaded by the time the user actually attempts to interact. It would be nice if any touches before the app actually is ready to service the event loop caused some visible feedback, and that that was canceled when the event loop is being serviced. That way on success the illusion is perfectly preserved (and you get extra time to remember exactly what button you are ready to tap and aim at it…), and on failure you don’t have to keep guessing when the app is actually ready.
Every week or so isn’t going to cost you enough battery to notice. So if it brings you joy, go for it.
More over, for anyone that does this with whatever frequency, and actually enjoys it if you aren’t running out of power you don’t need to care about it. If you don’t enjoy it you can stop because you aren’t getting any real benefit.
