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.
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.
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.
Are these the same people who use billion dollar corporations like Twitter just for receiving another type of notification from the same sources instead of native way?
"A significant performance improvement allowing faster and smoother IDE operation."
is the more relevant sentence, but they don't make a big deal about it, even though it's likely the single change with the greatest impact in this EAP release.
