Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer?

It is not up to the OS to decide which apps the user needs running. Be it wifi scanner, vpn or some file sync process. All the user needs is a correct tool to know which app consumes what, and then there User must decide. Not some prick in google or xiaomi or samsung or whoever else.

> Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer?

Your macOS has an unacceptable battery life already despite having a massive 58WHr battery - about 3.5x the size of a normal phone battery. Phone users don't want to lug that size of a battery around just to get battery life that's worse than they get right now from a 15WHr one.

> Your macOS has an unacceptable battery life already

Heh, not true anymore with the new M1 lineup. I was skeptical but they are insanely efficient.

Noone will buy a mobile phone with a battery life of a M1 lineup laptop. Pixel 4 got trashed on reviews for having the double battery life of those.

In terms of screen-on-time (for comparable tasks like web browsing) they are pretty close to modern phones..

I’m not saying apps shouldn’t be allowed to run in the background. But for notifications specifically it’s an unacceptable solution. It just doesn’t scale to the number of apps the average user receives notifications from.

Nobody was saying that every app needs to run in the background to deliver you notifications. I was arguing that for some apps background functionality is essential, and such functionality is obstructed by OS vendors, who strive to tie all background work to push notifications.

Sure, I agree with you there, but background app permissions and push notifications seem like pretty separate issues.

They are totally not, because whenever you need an app do something, like, display a message sent to you, the 'official' way is to do it via push notifications. But if your user doesn't use Google Play services, you have to make the app run in the background, which is increasingly difficult in Android (and impossible in iOS).

Hypothetically, an Android vendor could build a notification service separate from Play Services and deploy it on their Android builds. Has to be a vendor (or, more broadly: "someone who controls the OS down to the kernel level") because the notification technology involves some heavy abstraction-breaking footsie between the physical link layer and the TCP stack.

But the two big challenges there are:

- odds are the first several iterations of it will suck, so they'll be competing with an already-working solution that most users have no concerns using (significant market uphill fight, with the only major value-add being "We're not Google").

- we've just traded one master for another. Ultimately, unless someone builds an open-standard at the Android distro level that includes an API to allow users to establish a notification source, the distro owner still owns the notification system (and there's no reason a priori to assume they're less evil than Google). And designing that API to be abuse-proof would be a challenge; do it wrong, and we're back to the bad old days of sub-one-day battery life on an idle phone.

It'd be a hell of a cool project for someone to take on though.