Still lists Sony as "toxic" for having an opt-in battery extension feature which warns you of the trade-offs (which I've found very useful when I really wanted to, well, extend battery life, e.g. when hiking or travelling). I told them this back in 2019, and that they got this so utterly wrong AND have failed to fix it leaves me rather distrustful of the entire page.
Where did you bring this up? It would be interesting to read their response. If you hadn't, I imagine their Github repo would be the best place to do so https://github.com/urbandroid-team/dont-kill-my-app
Yes, Dear app developers, different users want different things.
The primary uses of my phone are (1) multi-factor authentication, and (2) as a GPS beacon whereby family can locate me if I'm injured in the wilderness. I definitely value battery life over app snazz.
Longer battery life is consistently number 1 on any survey of mobile phone users you'll find, ahead of camera. It's far and away what people care about. It's not surprising that phone manufacturers will do anything they can to improve theirs vs. competitions, including killing apps that are sitting there sucking up battery.
Longer battery life was the clear winner with 73% of people picking it as the most enticing reason to buy a new smartphone.[1]
60% of surveyed mobile phone users stated they would switch phones if the battery life improved (China) [2]
61 per cent cited battery as the key consideration, just behind the smartphone camera (India) [3]
76 per cent of iPhone owners and 77 per cent of Android users listed longer battery life as something that will get them excited about buying a new phone (USA) [4]
Of course, those very same users then also want their chat messages and calls to actually work and work immediately. Their health data and step counters to sync. Their GPS trackers and location sharing to be SPOT ON and never lag behind the real world. Their music to keep playing and their chromecast controls to keep working. Their iCloud and Google Photos to sync if their phone gets stolen or dropped into a toilet.
But sure, it's the battery - it's just that the best way to save the battery (turn off the phone) isn't REALLY what's important ;)
And comments like yours are funny on this very site, because what this site complains is OEMs killing competition and choice by selecting apps that are allowed to be used - e.g. apps like Signal are the ones that suffer the most because they're not blessed by exceptions.
Battery Life is something measurable. It shows well on tech spec and marketing materials.
"Not killing apps", on the other hand, is hard to sell.
User may notice some apps become less responsive, load slower, notification are delayed, etc.. but then they would blame the app, not the OS.
So does GPS beacon then not qualify as an app? I guess here you can hope the vendor has an "official" beacon app that they grant battery-life exceptions for, but then you're screwed if you prefer a third-party beacon. Maps, those can be as safety-critical as a beacon too.. it would be a shame if someone cleared your map-cache because app-devs / mobile OS designers are optimizing for urban technophiles who have easy access to electricity. Or if that flashlight app breaks because it has an offline-mode that's insufficiently tested, and it chokes down when it's trying to load ads from an API it can no longer access! It's depressing to think about but bad UX, poor initial design, or just inevitable enshitification of perfectly fine working systems like this has no doubt actually killed people.
iOS apps are built around Apple's policies which are more or less uniformly enforced on Apple phones. iOS apps started with near zero background compute and that was only added later.
OTOH, Android apps started with near zero restrictions on background compute and it's been added on in bits here and there. Two different Android phones may have drastically different policies and not because the user chose it. App developers can have difficulty making sure things work on phones where the manufacturer sets policies that limit when it can run or how it stays resident.
It's not always easy doing that for Apple, but there's not ten different ways you have to do things for ten different manufacturers.
Sure, there's tons of apps out there that have no business running in the background. But for every one of those, there's stuff that really needs it to work and the user wants it to work; the page on Samsung says some firmware versions would kill background execution if you hadn't used an app in 3 days, so if you had a weekly alarm in the clock app, and don't load the clock otherwise, it would likely not fire. That's not reasonable, and it's not what the user wanted or expected.
> It's not always easy doing that for Apple, but there's not ten different ways you have to do things for ten different manufacturers.
It's why, I, as a user, chose to stick with iOS. At least it's the devil I know, with the behaviour and boundaries that I can accept - without having to figure out every kink everytime there is an update.
I understand that some people prefer to tinker with their phones, I do not.
Can't you close your apps when you don't want them to stay open?
The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map my search would be gone.
So no please, don't kill my app when I don't want you to.
Not sure what you meant by that - mobile apps don't have main() or exit(), they are driven by onThingsHappen(Event event) calls. When the OS decides to call `onYourAppIsResumedFromAltTab(context SwappedOutMemoryContent)` instead of `onYourAppWasJustLaunched(void)`, your app can resume functioning. The former is more likely to happen on devices with larger RAM space. You as an app developer don't have full control over it, unlike how it is(used to be!?) with Win32 apps.
As a user, I can swipe up and hold from my home screen (depends on your launcher probably) and "swipe away" the apps I want to actually close, as in remove from the background. Not all of them comply, though.
Unfortunately it doesn't work like this. You can close the app, but app will wake up on any event - timer, call from server, any system event, etc. etc.
Most apps on my phone were strong armed on me by trend-following (or outright data grabbing) businesses. 99% of them could've been just a website - but no, I can't reschedule my doctor appointment via website, because "our app is so much better and has so much more features!"
So fuck yeah, kill them all! And if they dare to start on their own, kill them more!
I've followed the Samsung instructions to try to keep it from killing SleepBot and Tasker, but I gave up and had to find workarounds instead. It should be easier to configure so you can make it not go to sleep for apps that set alarms or watch your other apps.
Sometimes i hate apple for being a walled garden. Sometimes i love them. This is one of those times i like the vertical integration appl has that keeps quality high instead of going the OEM route goog/msft went.
While nothing affects me personally (always been an AOSP user via Lineage/Cyanogen), I know that at least some apps struggle with vendor "enhancements" that go counter to what users want. DAVx5 (CalDAV/CardDAV sync) is one I remember having warnings about OnePlus (2nd worst here) during setup and how you need to take extra steps to ensure syncing actually works, which is pretty important for such an app.
On vanilla, simply allowing permanent background or not seems like a great solution, I’ll allow it only where I really need it, and done.
I'm a happy user of DAVx5 and my employer just recently issued one of the more aggressive killing phones.
I followed the steps suggested in the setup and it works just fine now. I'd much rather have a complicated opt-in to background activity than any form of opt-out.
I don't have much sympathy for this idea. The vast majority of apps don't need to do anything in the background, but almost every app thinks it's the only app on your phone and wants to be running and online 24/7 so it can constantly send you notifications, mine your personal info, and upsell you on crap you don't need.
This is why we can't have nice things. It's a tragedy of the commons where the commons is your battery and your data and your attention.
Phone manufacturers try to restrict this nonsense as they should, but the better solution is to give users complete control over background behavior, with the default being "none."
Many app need to keep state while they are in background though. Imagine your browswer tabs reloading every time you swotch to a different app and back.
Doesn’t mean your apps need to run in the background all the time. State restoration is a concept that has been present in Android/iOS from the beginning (or almost) and many apps implement it successfully. This is not why the “Don’t kill my app” author wants to run in the background.
Also Android has ongoing notifications which let your app stay running forever and iOS introduced Live Activities in iOS 16 which can be used similarly (e.g. Instagram uses it to finish uploads in the background). But what the author of “Don’t kill my app” wants is to run in the background without making it obvious to the user, which many would consider malicious.
I think many commenters supporting the "kill my app" behavior do not understand how bad using the affected devices can be.
The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map the app would reload. My search would be gone, and I would have to set my destination again.
I hope you can agree that this is terrible user experience. If I wanted to save battery, I could have just closed my apps manually, I don't need my phone to take the initiative.
I feel like this is how Android has been designed from the start.
Ages ago apps used to have a bug where form contents were cleared if the user switched from portrait to landscape orientation -- same problem: developers assumed they could store state in instances of input fields, when in fact these would be re-instantiated when the view was significantly re-rendered.
This specific case seems like a continuation of that misunderstanding and a difference in intuition between Android architecture and PC developers, rather than an actual fault with Android.
Rotating your device or plugging in a keyboard should cause the UI to be torn down: it makes for a horrible UX and it's behavior that dates back to a phone that had 192MB of RAM.
It should have been ditched ages ago but in typical Android fashion lived on so long that now it can't really be changed and instead the SDK tries to work around it by providing developers with primitives to work around it.
Because it costs resources the developers are unwilling or unable to spend.
They might also be lacking competence. My local bus authority’s application is barely able to keep track of its state while it’s running.
An other common situation is an applications getting in an irrecoverably broken running state. If the application preserves state on shutdown you might not be able to get it out of the broken state.
I think Android dev is unnecessarily designed in a way that makes saving data require a lot of code. If you know what you're doing, you can mmap a file, put all your working memory in there, and let the OS save it for you. No serialization or parsing necessary and memory access is exactly the same as usual with no overhead. You'd think that using a managed language would make it easier to abstract and support this kind of thing but seems they'd rather require all app devs do manual saving and reloading of their app data.
Because developers don't keep track of possible state changes that follows a callback? Mobile apps are not like C code with an entrypoint, you can't like dump all virtual memory to disk and write back to resume. It's all callbacks and object instantiations, and listing all objects is already a best-effort task.
It won't be impossible to architect an app so that there would be an instance of a class that store all relevant states and load on creation, of course, and I'm guessing that level of competence is mid-six-figure quality in app world.
These phones go much farther the already absurd limitations of standard Android ("we know what apps a user doesn't care about so we'll kill them without asking, at any time").
Most developers are not aware of them, and in any case it's very hard to constantly save all the state
Hardly any previous system in the history of computers has ever required it, and Android's developer documentation doesn't highlight enough how much it's required.
Most of all it's the fault of these phones' extreme, undeclared, undocumented and absurd behavior anyhow.
The expectation in mobile environments is that you store whatever information you need to resume from cold in response to the app leaving the foreground, since the OS may kill it with little further warning at any time thereafter. This recommendation occurs prominently in the lifecycle docs for both iOS and Android.
This somehow seems to have become an inevitable reality of mobile phones. I had to upgrade from my iPhone 7 because it had essentially become a “single-process OS” where even switching to Google Translate to help me compose a message would have the messaging app killed in the background.
And now I am experiencing similar issues, although not as severely yet, with my iPhone 12 Pro Max. Restarting the phone seems to help but there seems to be some battery and/or memory pressure that causes iOS to kill the non-active apps.
Happened to me many times browsing restaurants / using a map during recent trip with 13 mini. Sucks to suffer a map reload when you're on roaming data with few bars.
iOS actually kills apps in the background FAR less than it used to. If your apps are not preserving state across being killed, it’s because they’re not doing the work to make sure the app death is transparent. Perhaps they’re more tempted to forego the work because it’s somewhat _less_ essential than it used to be.
I despise that this still happens today on a phone with 8GB of RAM. EIGHT GIGABYTES. That's what they sell the MacBook Pro with, but Android, built for low memory devices from the ground up, can't consistently keep a single application in memory in the background for just a few seconds. You can literally switch for five seconds and the last app has to reload.
What's worse is when the task switching app and/or the home screen app have to be restarted. My phone only has 4 GB ram, cause it's nearly 3 years old and low cost, but still... I feel like windows 95 could run (poorly) on 4 MB and the start button and the task bar never swapped out. (Well explorer.exe did crash from time to time)
I have to admit I haven't fact-checked this on my own but I have it on fairly good authority that several versions of Windows could swap themselves out, sometimes resulting in a bluescreen.
The start button and the task bar are part of explorer.exe, although if I'm not mistaken the File Explorer windows have always been run in a separate instance of explorer.exe .
I'm pretty sure that the task bar and start button could get swapped out btw, but they're quick to reload (except for the start menu and the tray icons)
I kind of understand manufacturers getting aggressive about rogue inefficient apps wasting cpu cycles and making their battery life look bad.
But it’s weird and lazy that on an 8GB phone they kill the app rather than just suspend it (to stop it using any cpu)?
On iOS, even in low-power mode, and on a phone with far less RAM, apps rarely have to reload unless you’ve force-quit them or have gone for days without using them.
8 GB of memory on a laptop is pathetic in 2023 and everybody knows it. And you're either using a very broken Android OS implementation or very unusual apps, it should not behave that way.
Yeah. It's supposed to be like 8 thousand UNIX computers. It just has to be insanely enormous bloat.
Hence my personal belief: GUI operating systems must evolve to slow down to match user-expected frequency of stimuli. Too fast and users leave, so they add crufts and weights until it's slow enough.
The most egregious problem caused by this that I've encountered is an almost complete inability to use email 2FA on websites because my phone will kill the browser as soon as I switch to my inbox, and when I go back to the browser I'm back on the login screen which will generate a new one-time-password and make the one I have in my clipboard worthless. I've also encountered the exact same problem with 2FA using an authenticator app, though since the codes are valid for ~30 seconds or so, if I manage to enter my credentials fast enough or they auto-fill, at least the code I copied is still valid.
It is quite common for the OS to suspend apps when they're in the background or when the device is under low memory/power conditions. The fact that you as a user are experiencing it in the form of degraded functionality is a bug with the app itself and should be addressed by the developer.
As a reference, check iOS apps where the system monitors and controls each app's resource usage much more aggressively and a user is never aware of this.
While suspending may be the first state, the OS can choose to fully evict the app from memory if it needs it for other tasks. So a "good app" saves state before being suspended so that upon resume, it can restore from disk even if it was "killed".
Yes, but in practice almost all apps don't do it always with the complete state,; and on phones that don't kill them so easily most of the times you can switch between apps without problems.
That's indeed a terrible user experience, and the fact that the alternative isn't used (apps saving state even in trivial cases like which paragraph you're reading or a search query) adds to it. Wasting battery seems easier, so I'd also prefer to be able to configure to allow it rather than have all the apps killed and lose state, after all, it's my battery to waste
I don't understand why Samsung is up there, at least on mine there's options to let it run things in the background when you need to. And otherwise, I'd rather not have apps hogging the battery in the background.
> As a company, we develop a library that collects sensor and location data from the device, sends it to our platform, and transforms it into meaningful information about the user (user habits, routines, etc.).
> Over the past years, it has been painfully difficult to support Chinese OEM devices (Huawei, Xiaomi, etc.). These OEMs are modifying Android in ways that break core functionality. The default behavior of these devices is to forbid newly installed apps to send/receive broadcasts, acquire wakelocks, start services, set alarms, etc. in certain conditions (e.g. screen off), unless the user explicitly whitelists the app.
Honestly, I would prefer such an app stay broken. I don't need the app collecting that data in the background. If the attitude of Android developers is that they should be permitted to run in the background and collect this kind of information without explicit background permission from the user, then it's a no-brainer for OEMs to push back in order to preserve battery life.
It's weird how this can be an issue in both directions.
There are times when I don't want the OS to kill an app, and the OS can often fail in this aspect, causing loss of control.
However even more frustratingly, I've increasingly noticed that apps I only need rarely, maybe once a day, once a month, once a year, will still run in the background even with setting the app's battery settings in the OS to restricted.
There is _nothing_ I can do to stop them from running, except uninstall them, but that's a pain for apps I have no choice but to use, even if rarely.
This is a problem even on GrapheneOS which increases user control. You could temporarily disable apps, but it is such a tedious process that uninstalling might be easier.
Perhaps the OS recognizes those apps you use less as the ones that historically cause the least impact on battery, hence allowing them to run on background? If that is the case, this is pretty dumb.
Honestly, it's not just Android. iOS exhibits the same issue, and of-course Safari is exempt from this policy.
When you're in Edge, switch apps, and go back, the amount of times Edge RELOADs the page is staggering. And of-course, reload means re-fetch from the server which isn't necessarily idempotent.
Yelp & HikingProject (REI): Same issue...
And given Apple's control over the ecosystem it's quite weird that tombstoning (what it was called on Windows Phone) isn't enforced, even though it's one of the most jarring experiences of using 'apps'.
And frankly, that would cover 99% of all battery life issues. The only reason these apps want to stay alive is to maintain state. State that can perfectly be serialized & restored.
83 comments
[ 3.4 ms ] story [ 145 ms ] threadI'm not sure if it's been updated since then.
Still lists Sony as "toxic" for having an opt-in battery extension feature which warns you of the trade-offs (which I've found very useful when I really wanted to, well, extend battery life, e.g. when hiking or travelling). I told them this back in 2019, and that they got this so utterly wrong AND have failed to fix it leaves me rather distrustful of the entire page.
There seems to some updates, https://dontkillmyapp.com/samsung shows update from 2021
The primary uses of my phone are (1) multi-factor authentication, and (2) as a GPS beacon whereby family can locate me if I'm injured in the wilderness. I definitely value battery life over app snazz.
Longer battery life was the clear winner with 73% of people picking it as the most enticing reason to buy a new smartphone.[1]
60% of surveyed mobile phone users stated they would switch phones if the battery life improved (China) [2]
61 per cent cited battery as the key consideration, just behind the smartphone camera (India) [3]
76 per cent of iPhone owners and 77 per cent of Android users listed longer battery life as something that will get them excited about buying a new phone (USA) [4]
1: https://9to5mac.com/2021/03/19/iphone-buyers-want-battery-li...
2: https://www.gizchina.com/2023/05/08/do-you-have-mobile-phone...
3: https://www.businesstoday.in/technology/news/story/long-batt...
4: https://www.scmp.com/magazines/style/tech-design/article/218...
But sure, it's the battery - it's just that the best way to save the battery (turn off the phone) isn't REALLY what's important ;)
And comments like yours are funny on this very site, because what this site complains is OEMs killing competition and choice by selecting apps that are allowed to be used - e.g. apps like Signal are the ones that suffer the most because they're not blessed by exceptions.
"Not killing apps", on the other hand, is hard to sell. User may notice some apps become less responsive, load slower, notification are delayed, etc.. but then they would blame the app, not the OS.
Don't get me wrong. I enjoy longer battery life.
OTOH, Android apps started with near zero restrictions on background compute and it's been added on in bits here and there. Two different Android phones may have drastically different policies and not because the user chose it. App developers can have difficulty making sure things work on phones where the manufacturer sets policies that limit when it can run or how it stays resident.
It's not always easy doing that for Apple, but there's not ten different ways you have to do things for ten different manufacturers.
Sure, there's tons of apps out there that have no business running in the background. But for every one of those, there's stuff that really needs it to work and the user wants it to work; the page on Samsung says some firmware versions would kill background execution if you hadn't used an app in 3 days, so if you had a weekly alarm in the clock app, and don't load the clock otherwise, it would likely not fire. That's not reasonable, and it's not what the user wanted or expected.
It's why, I, as a user, chose to stick with iOS. At least it's the devil I know, with the behaviour and boundaries that I can accept - without having to figure out every kink everytime there is an update.
I understand that some people prefer to tinker with their phones, I do not.
The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map my search would be gone.
So no please, don't kill my app when I don't want you to.
So fuck yeah, kill them all! And if they dare to start on their own, kill them more!
Now of course that can come back to haunt us.
On vanilla, simply allowing permanent background or not seems like a great solution, I’ll allow it only where I really need it, and done.
I followed the steps suggested in the setup and it works just fine now. I'd much rather have a complicated opt-in to background activity than any form of opt-out.
This is why we can't have nice things. It's a tragedy of the commons where the commons is your battery and your data and your attention.
Phone manufacturers try to restrict this nonsense as they should, but the better solution is to give users complete control over background behavior, with the default being "none."
Also Android has ongoing notifications which let your app stay running forever and iOS introduced Live Activities in iOS 16 which can be used similarly (e.g. Instagram uses it to finish uploads in the background). But what the author of “Don’t kill my app” wants is to run in the background without making it obvious to the user, which many would consider malicious.
https://developer.apple.com/documentation/uikit/view_control...
https://developer.android.com/topic/libraries/architecture/s...
The reason I first discovered "don't kill my app" is that my apps would close as soon as I switched to another one, in most cases. For example if I used maps and switched to a call / browser tab / Telegram chat, when I got back to the map the app would reload. My search would be gone, and I would have to set my destination again.
I hope you can agree that this is terrible user experience. If I wanted to save battery, I could have just closed my apps manually, I don't need my phone to take the initiative.
Ages ago apps used to have a bug where form contents were cleared if the user switched from portrait to landscape orientation -- same problem: developers assumed they could store state in instances of input fields, when in fact these would be re-instantiated when the view was significantly re-rendered.
This specific case seems like a continuation of that misunderstanding and a difference in intuition between Android architecture and PC developers, rather than an actual fault with Android.
Rotating your device or plugging in a keyboard should cause the UI to be torn down: it makes for a horrible UX and it's behavior that dates back to a phone that had 192MB of RAM.
It should have been ditched ages ago but in typical Android fashion lived on so long that now it can't really be changed and instead the SDK tries to work around it by providing developers with primitives to work around it.
But I'm not an app developer so there is presumably a reason for that. Data exfiltration?
They might also be lacking competence. My local bus authority’s application is barely able to keep track of its state while it’s running.
An other common situation is an applications getting in an irrecoverably broken running state. If the application preserves state on shutdown you might not be able to get it out of the broken state.
Please don't do this.
It won't be impossible to architect an app so that there would be an instance of a class that store all relevant states and load on creation, of course, and I'm guessing that level of competence is mid-six-figure quality in app world.
Most developers are not aware of them, and in any case it's very hard to constantly save all the state
Hardly any previous system in the history of computers has ever required it, and Android's developer documentation doesn't highlight enough how much it's required.
Most of all it's the fault of these phones' extreme, undeclared, undocumented and absurd behavior anyhow.
https://developer.android.com/guide/components/activities/pr...
The expectation in mobile environments is that you store whatever information you need to resume from cold in response to the app leaving the foreground, since the OS may kill it with little further warning at any time thereafter. This recommendation occurs prominently in the lifecycle docs for both iOS and Android.
And now I am experiencing similar issues, although not as severely yet, with my iPhone 12 Pro Max. Restarting the phone seems to help but there seems to be some battery and/or memory pressure that causes iOS to kill the non-active apps.
This drives me absolutely nuts.
Android and iPhones thought they'd look cooler if they didn't, resulting in a decade of endless frustration for many users.
I'm pretty sure that the task bar and start button could get swapped out btw, but they're quick to reload (except for the start menu and the tray icons)
But it’s weird and lazy that on an 8GB phone they kill the app rather than just suspend it (to stop it using any cpu)?
On iOS, even in low-power mode, and on a phone with far less RAM, apps rarely have to reload unless you’ve force-quit them or have gone for days without using them.
Hence my personal belief: GUI operating systems must evolve to slow down to match user-expected frequency of stimuli. Too fast and users leave, so they add crufts and weights until it's slow enough.
It is quite common for the OS to suspend apps when they're in the background or when the device is under low memory/power conditions. The fact that you as a user are experiencing it in the form of degraded functionality is a bug with the app itself and should be addressed by the developer.
As a reference, check iOS apps where the system monitors and controls each app's resource usage much more aggressively and a user is never aware of this.
So the map app is buggy… my expectation would be that it should be fixed.
> As a company, we develop a library that collects sensor and location data from the device, sends it to our platform, and transforms it into meaningful information about the user (user habits, routines, etc.).
> Over the past years, it has been painfully difficult to support Chinese OEM devices (Huawei, Xiaomi, etc.). These OEMs are modifying Android in ways that break core functionality. The default behavior of these devices is to forbid newly installed apps to send/receive broadcasts, acquire wakelocks, start services, set alarms, etc. in certain conditions (e.g. screen off), unless the user explicitly whitelists the app.
Honestly, I would prefer such an app stay broken. I don't need the app collecting that data in the background. If the attitude of Android developers is that they should be permitted to run in the background and collect this kind of information without explicit background permission from the user, then it's a no-brainer for OEMs to push back in order to preserve battery life.
There are times when I don't want the OS to kill an app, and the OS can often fail in this aspect, causing loss of control.
However even more frustratingly, I've increasingly noticed that apps I only need rarely, maybe once a day, once a month, once a year, will still run in the background even with setting the app's battery settings in the OS to restricted.
There is _nothing_ I can do to stop them from running, except uninstall them, but that's a pain for apps I have no choice but to use, even if rarely.
This is a problem even on GrapheneOS which increases user control. You could temporarily disable apps, but it is such a tedious process that uninstalling might be easier.
On Google Pixels, apps get aggressively killed in extreme battery saver mode. To spare an app from this, designate it as an essential app. No brainer.
When you're in Edge, switch apps, and go back, the amount of times Edge RELOADs the page is staggering. And of-course, reload means re-fetch from the server which isn't necessarily idempotent.
Yelp & HikingProject (REI): Same issue...
And given Apple's control over the ecosystem it's quite weird that tombstoning (what it was called on Windows Phone) isn't enforced, even though it's one of the most jarring experiences of using 'apps'.
And frankly, that would cover 99% of all battery life issues. The only reason these apps want to stay alive is to maintain state. State that can perfectly be serialized & restored.