alt Hacker NewsIf your app needs to send a notification while it's not currently a running process, it must go through Firebase on Google's side and APNS on Apple's side. There is no way for a non running app to send a notification entirely locally, this is by design of both companies.
Replies
> this is by design of both companies.
I’ll note that whatever other reasons it’s also the only way to make this battery efficient. Having a bunch of different TCP connections signaling events at random times is not what you want.
Ideally the app also is responsible for rendering rather than having to disclose the message but that can be challenging to accomplish for all sorts of reasons).
> […] this is by design of both companies.
This is more of a fundamental technical limitation of operating systems and networks; I don't think it is possible to design distributed communication between arbitrary service provider infrastructure and end-user devices without an always-online intermediary reachable from anywhere (a bouncer, in IRC terms) that accepts messages for non-present consumers.
But there is a way to do this encrypted, so that when the notification is received on your iPhone, the process itself needs to decrypt it.
Except you need an entitlement for that, because it requires that your app has the ability to receive a notification without actually showing it (Apple checks this).
Your app gets woken up, decrypts the message, and then shows a local notification.
Signal developer here. Not entirely sure what you're saying. I'm only an Android guy, but FCM messages are certainly one trigger that can allow an app process to run, but it's not the only trigger. You can schedule system alarms, jobs, etc. And the notification does not need to be provided by the FCM message. In our case, the server just sends empty FCM messages to wake up the app, we fetch the messages ourselves from the server, decrypt them, and build the notification ourselves. No data, encrypted or otherwise, is ever put into the FCM payloads.