Embed Notice

@CosmicTrigger

It's funny you ask because I was actually just delving deeply into this topic for the Android chat app I'm working on!

Most desktop notifications that I'm aware of work by each individual app that wants to have notifications setting up a background process that starts at boot and just polls or listens for new notifications from its respective server and then displays them when there are any to display. So for instance Discord sets up a little startup process that just sits in the background and whenever the Discord servers tell there are new notifications for you it displays those notifications. That's why whenever you're able to receive notifications for Discord you'll notice a little Discord icon in your system icon tray.

On the other hand, push notifications on mobile have a very different architecture. In order to preserve battery life and processing power, how they actually work is that applications register with a single central notification distributor that runs as part of the operating system (or pretty close thereto), telling the notification distributor the special key that refers to notifications specifically directed at that app and the fact that they want to be alerted of any new notifications. Then the notifications distributor listens to a centralized push notification relay server specific to the platform — FCM on Android, APNs on iOS — for all of the notifications relevant to that user, receiving all the notifications for all of the apps that are subscribed for notifications itself as one centralized place, and when it does receive any, it deals them out over inter-process communication to the relevant subscribed apps. So what the app developer has to do then is register whatever server they have actually producing their notifications with the centralized push notification relay server for the platform and then in their app put a little file saying that they want to register for notifications originally from that server.

As you'll notice, there's a layer of indirection and centralization here that is completely unnecessary, since you could just have your app tell the distributor what server it wants to listen to directly and then the distributor could just listen to all the different servers the applications want to listen to, without a push notification relay server (since after all there's actually a well-known open standard for subscribing to and producing push notifications over the Internet so the distributor could just understand that standard and then the applications servers could just produce that standard).

Additionally, although the actual content of the notifications is passed through this process entirely encrypted it still raises some privacy concerns.

That's why a lot of free and open source and privacy focused Android apps actually use the desktop notifications model (that's what my chat app does) instead, even though Google goes to great pengths to discourage it because it can impact battery life.

The other thing is that for Google the notifications distributor is actually not part of the operating system at all but part of their proprietary and closed source spyware called Google Play Services, which is why custom ROMS of Android can struggle with delivering notifications if they want to fully deGoogle because they lose the ability to do push notifications. It also means that any application that wants to deliver timely notifications and doesn't want to set up a long running background process has to include some closed-source proprietary code with it for Google Play services to work.

Oh, and did I mention — doing the desktop notifications model on Android is actually a violation of the Play Store rules?