The link in the comment you’re replying to says which part is not true, but since you seem more willing to comment than to click a link and read, I’ll summarize:
The part about the Apple Push Notification service requiring less information that can identify an individual user than Google’s Firebase Cloud Messaging is not true. Both use a similar token system. Furthermore, it is possible to build android apps with notifications that do not use FCM.
Maybe they want that, but the statement on their website is not wrong on a technicality because it’s oversimplified; it’s wrong because it asserts a privacy difference between the two operating systems that does not exist.
It’s actually not possible to build a push service like FCM or APNS on Android and have it function at the same level as FCM. FCM has special permissions to bypass certain device states on the device to ensure message delivery that nothing else can match.
The best you can do is approximate it with an always active websocket and a foreground service always running with battery optimizations disabled, but good luck not having that foreground service shut down on occasion as well. Devices are hostile to them for battery saving purposes. You’d have the best luck with a Pixel device though for something like that. You could also do some sort of scheduled background polling, but the device can be hostile to that as well, and it would eat more battery.
It’s true that FCM will result in more reliability and a better UX than other ways to implement notifications. Doing something else is still the right choice for certain use cases, such as those where privacy or keeping the entire codebase open source are top priorities.
Yes, I used web sockets for Signal for a while. It drained 30% of my battery when the phone sat idle for a day. Absolutely bonkers. Made the phone almost unusable so had to revert to FCM or disable notifications.
I worked on an app once where delivery was critical, so we gave them the option of the active service+websocket, but for them the trade off was acceptable.
Pushes can be pretty flakey given all the shenanigans OEMs do on the device, even when marked as high priority correctly.
And the even worse part is when OEMs reset battery saving flags the user had set to help pushes get through and they stop working one day because of it.
The link in the comment you’re replying to says which part is not true, but since you seem more willing to comment than to click a link and read, I’ll summarize:
The part about the Apple Push Notification service requiring less information that can identify an individual user than Google’s Firebase Cloud Messaging is not true. Both use a similar token system. Furthermore, it is possible to build android apps with notifications that do not use FCM.
they probably want to also make it as easy as possible for those who aren’t technologically savvy or whose native language isn’t english, though
Maybe they want that, but the statement on their website is not wrong on a technicality because it’s oversimplified; it’s wrong because it asserts a privacy difference between the two operating systems that does not exist.
It’s actually not possible to build a push service like FCM or APNS on Android and have it function at the same level as FCM. FCM has special permissions to bypass certain device states on the device to ensure message delivery that nothing else can match.
The best you can do is approximate it with an always active websocket and a foreground service always running with battery optimizations disabled, but good luck not having that foreground service shut down on occasion as well. Devices are hostile to them for battery saving purposes. You’d have the best luck with a Pixel device though for something like that. You could also do some sort of scheduled background polling, but the device can be hostile to that as well, and it would eat more battery.
It’s true that FCM will result in more reliability and a better UX than other ways to implement notifications. Doing something else is still the right choice for certain use cases, such as those where privacy or keeping the entire codebase open source are top priorities.
Yes, I used web sockets for Signal for a while. It drained 30% of my battery when the phone sat idle for a day. Absolutely bonkers. Made the phone almost unusable so had to revert to FCM or disable notifications.
Ya, it can be brutal on battery.
I worked on an app once where delivery was critical, so we gave them the option of the active service+websocket, but for them the trade off was acceptable.
Pushes can be pretty flakey given all the shenanigans OEMs do on the device, even when marked as high priority correctly.
And the even worse part is when OEMs reset battery saving flags the user had set to help pushes get through and they stop working one day because of it.
Then don’t claim the reasoning is anonymity.