If the app generates them, the OS receives them. That's why the Signal app offers this setting.
Source? I don't think either OS implements notification syncing between devices, it's only one way, and as others have mentioned, the actually push notification doesn't contain any message content, only an instruction for signal to fetch and decrypt the message.
Can't speak for iOS and no idea if this relates to the above functionality, but Pixel lets you deduplicate notifications across Pixel devices.
iOS does. This is how you can receive Signal notifications on your Apple Watch and other Apple devices that don’t have the app installed.
I also didn't realize that Android stores message history even after I've replied or swiped them away. That's nuts - why!?
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 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.
The flip side of the coin: any possibly avenue to exfiltrate data and do (advertising) tracking by app developers will be used. The restrictions also protect my privacy.
And my phone battery.
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.
Receiving a ping from Firebase Cloud Messaging triggers the app to whatever it does in order to display its notification. In the case of Signal, that probably means something like fetching the user's latest messages from the server, then deciding what to show in the notification based on the user's settings, metadata, and message content.
Here's example code for using FCM to show a notification. In this case, the notification content also passes through FCM, but Signal does not do that. https://www.geeksforgeeks.org/android/how-to-push-notificati...
Looks like there is a way to bypass Firebase by using something like UnifiedPush which runs a perpetual background process that acts similar to Google Play Services to pick up notifications from the server and calls the local notification API.
That's unreliable though since some OEM Android builds will kill it for that even if the user disables battery optimizations. Those OEMs sort of have a point; if lots of apps did that it would drain the battery fast.
Source: https://mastodon.world@Mer__edith/111563866152334347 (Meredith Whittaker is the current CEO of Signal)
I can't link you rigth now to the actual code on their repo but it is verifiable.
You're angry about a huge amount of outright misinformation here.
Signal has this setting to tell the backend how much information to put into the push message. It can tell the backend to send a simple notification saying “new message” and not send information through APNS or enable it.
I am willing to bet Signal has a notification extension to handle edge cases where there is lag in settings to scrub the message metadata before it dings a screen alert.
Normally no notifications are shown for hidden apps, and even if you unhide the apps, prior notifications which were sent do not reappear IIRC. I'm curious if notifications like that are still hitting the phone into the notifications database, or get silently dropped, or something else.