[AshamedCaptain]

There is no need for a global push service, either. Just some type of API that batches timer wakeups and network keepalives together is enough to guarantee very high battery life, and you can still keep as many connections as the user wants. Many platforms before Google/Apple worked like this.

Push services are a bit more convenient in that they require less infrastructure both in the server-side as well as client programs (e.g. they can even be shut down and still receive messages), but nothing really prevents having an ecosystem of multiple competing push services.

[NotPractical]

There clearly is a need. It needs to be as easy as possible to switch away from Google, or developers won't do it. Additionally, an ecosystem where each developer is encouraged to go wild and implement their own notification system is not ideal. Sure, some of them will be competent enough not to deplete the user's battery within a few hours, but others will not be, and each individual app that does this contributes to battery drain in a tiny way, which adds up.

> Many platforms before Apple/Google worked like this

Mobile devices are an entirely different beast with strict battery life and data usage requirements.

Another factor to consider is that Android will kill long-running background apps unless you disable battery optimization for said apps through a convoluted process (even if you show a persistent notification). [1] It would be really inconvenient for users to have to manually disable battery optimization for every app that wants to send push notifications.

[1] https://github.com/gotify/android#disable-battery-optimizati...