Local area network push notifications

For a while I’ve had a theory that Apple’s push notification policies have a weirdly significant effect on open source software architecture and how successful projects can be. This is most challenging for free-as-in-beer and decentralised models. If an iOS chat app wants to monitor the server for realtime updates, it’s prevented from holding a TCP connection open in the background. It’s also prevented from polling for updates with any consistency. Its only reliable way to get those realtime updates is through APNs, an internet-based Apple service. The only person who can trigger those updates is the creator of the app. If your architecture means that different people are responsible for the client app and for the server containing your data, this creates a range of undesirable consequences. If you don’t find a satisfactory solution you’re effectively locked out of the iOS market. I discussed this in detail a few years ago in the context of how Matrix works around it.

It’s been this way for so long that I did a small double take when I spotted a certain WWDC20 video. It claims that in iOS 14 you can “deliver notifications from your application server to devices on networks without an internet connection”. Hold up—this means APNs is out of the picture and there is now some self-hosted way to deliver reliable push notifications. Is this carte blanche for every XMPP and fediverse server to implement their own push notifications on the side? No way! There has to be some catch.

Of course there’s a catch. The main limitation is that it only works when you’re connected to a WiFi network. If you only have cell internet then you’re back to APNs only. The other is that you have to be able to specify, in code, the list of network SSIDs where local push notifications will be active. Perhaps you’re thinking you could fill in this information dynamically? Well, maybe, but getting the currently connected SSID can be a problem in itself.

They say repeatedly in the video that it’s targeted at very specific use cases, messaging apps on cruise ships in particular. In this context the restrictions make sense. It’s just enough wiggle room to solve the problem and not much more.

What did surprise me was how much freedom the App Extension gets. While I haven’t tested the beta myself, it appears it gets to run the whole time you’re on that SSID and it can implement whatever protocol it wants to talk to your proprietary server. That’s a pretty significant carve-out in the protection against apps draining your battery. It requires an entitlement, which I assume will be a flag for special attention at the App Store. Otherwise I could imagine a nefarious app that already has location access using CNCopyCurrentNetworkInfo together with this new feature to track whenever a user is at home, work, etc., without actively using the location permission.

It’s possible that decentralised projects will find niche uses for this. If you had a service self-hosted on your home LAN, you could absolutely build a client that gives you push notifications while you’re at home. However if such an app lets you type in your SSID, there’s nothing to say it will pass App Store review, unless you happen to live on a cruise ship.