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]

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...

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.

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.

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.