the main reason I'm switching to Android

You may be interested in reading this comment then: https://www.reddit.com/r/signal/comments/ap9lin/comment/eg7v...

Likely, iOS version of Signal uses the same “empty ping” technique, so you don’t have to worry about Apple reading your texts, unless you’re concerned with metadata leak. But unless they’re spoofing a websocket with fake packets, it will leak anyway.

First, that “server” is Signal server itself. When a message arrives at it, it simply commands Apple to wake up your app, for it to call home, and that’s it. It is preconfigured to do that (and GCM as well).

Second, all Signal messages are end to end encrypted and neither of Apple, Signal, Google, your ISP, any server on the route of it NEVER know its content, because the only mean of decrypting it resides in a memory of your client app. There is basically no way to see the contents before your client receives the message, by design. Even if that were not the case, various IM servers don’t have to send your texts to Apple, only if they want the text to be shown on a notification itself.

The only theoretical concern here may be that Apple can somehow pick the decryption key out of the app’s memory (because ios is a supervisor, obviously). But that can’t be the main reason someone swithces to android, which is a supervisor itself, and where the same issue exists.

In a centralized system where the mobile app is made by the same people as the IM server, of course the IM server can send a notification to the app (such as is done in e2e stuff like Signal, or in non-e2e such as Telegram).

That falls apart when you're talking about, say, ActivityPub on an instance you run yourself, or one not operated by the vendor of the IM app. The developer's server can't know when to send you a notification without having some knowledge, from your own e.g. IRC, ActivityPub, or Matrix server, that you have received a new DM.

The Matrix/Element people have addressed this by running one centralized notification service for every single client of the Matrix/Element iOS app.

Sorry, I misunderstood that.

The main reason for the restriction to apple-only for notification services is battery life, and they've been proven right by bad behavior demonstrated on android.

Interestingly, if your a VOIP app you can actually circumvent a lot of the background networking restrictions, but it's still hard to do when you don't have an active call in place. You also have to be an actual VOIP app to get approved with that entitlement. Which wouldn't be hard to get approval for if you made a fork of signal for example, since it does have real VOIP capabilities inside.

Either way the battery life of your device would be worse with your custom VOIP app always keeping a connection open vs. apple's native OS notification system.

These APIs were removed a while ago. As an example, pure SIP clients (without a SIP<->APNs proxy operated by the app developer) are no longer possible for iOS.

Android seems to be headed the opposite direction from Apple when it comes to background service execution and network connectivity. I wouldn't be surprised if background network connections are the next thing to go.

> which means that federated stuff is basically out without providing your login details to the developer

It's definitely possible to support federated push, although it's admittedly more work for app/protocol developers: The app developer would have to set up a "push proxy" server that accepts push notifications addressed to a specific iOS device.

It would be nice if Apple was to allow optional sourcing of "anonymous" pushes for such use cases, but that doesn't seem to be in line with their desired level of control.

Could you expand on this? I did a quick search but I don't see anything relevant that's more recent than 2016.

It's still relevant.