This requires paying about $10/month to Apple and doxxing yourself with a lot of PII.
It also requires that you as a homeserver sysadmin a) have a Mac, b) install Xcode, c) know how to modify and compile iOS applications, d) want to deal with rebuilding and reuploading and re-seeking app approval on major API changes because long-un-updated apps are not allowed in the App Store, etc...
Security, Convenience, and Speed will always be in constant tension.
If you start by assuming that a perfect solution will always be unattainable, deciding on what tradeoffs are acceptable becomes easier.
Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.
This comment makes it seem like Apple's anticompetitive stance on sideloading is a basic force of nature instead of something dreamed up by control freak hippies and implemented deliberately in code.
The problem is iOS's privacy-hostile design (in service of their locked down revenue model), not some unbreakable iron triangle.
On Android, messaging apps can run in the background and periodically talk to their homeserver without an intermediary.
Agree 100% about Apple being anti-consumer, but the Android thing is not quite that simple.
Background tasks on Android can pretty much be killed at any time. I believe only apps with a persistent notification and the native google notification service can remain active at all times. But yes, they can connect to any server while they are running.
> Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.
Once you're going to push encrypted data through a centralized service, you might as well just run Signal and skip running the homeserver too.
