Apple's bizarre crackdown on multicast

At WWDC20, Apple announced there would be a new entitlement controlling access to multicast and broadcast. After the “Local Network” permission in iOS 14 this wasn’t too surprising. As a user I like the idea that an app can’t talk to other devices on the LAN without oversight.

When I saw that announcement I thought this would be something like the old App ID configuration where you tick the things you need, or you put some key in Info.plist. It would be another data point for the App Store. If your app switched on the multicast entitlement one day then it would signal the reviewer to have a closer look and understand why you’re using it.

It’s… not like that. There is a form. You have to be an administrator of an Apple Developer account to access it. Here’s a screenshot. (click for larger size)

Yes that’s right: if you want to send or receive a multicast datagram on your iOS device you have to explain yourself to humans at Apple, who will then decide whether your account is worthy of this privilege. Eskimo (bless his cotton socks) has an FAQ about how it all works now.

It’s possible that I lack perspective here but I find this pretty offensive. I’m developing an app of my own creation to install on a device in my own possession, and now I have to prostrate myself before some review committee to use a staple of TCP/IP? To enjoy the pleasures of peer-to-peer networking normally only entrusted to Apple internal developers? Look, I’d rather not.

No doubt a couple of readers will be thinking “well this is what Apple/proprietary software is like, what did you expect?” I’m extremely familiar with that argument and I don’t like it very much. Among the many restrictions on iOS which make life difficult for developers I can usually see a direct reason why this helps the end user in some way. Often it’s related to privacy or protecting their battery from runaway apps.

Did they make multicast part of the “Local Network” user permission? No. Did they let you flag the capability like they do for the Bluetooth background modes, which enable much more serious privacy violations? No. They went straight for the most power-tripping approach possible and I don’t see the benefit for the end user. If anything it’s a nett negative: standard, cross-platform networking protocols will be less supported when there is more friction to use them on Apple systems. Software that works great on a private LAN rather than via the cloud is less likely to be available.

In the scheme of things it’s a niche complaint. Probably few developers care about multicast. Users may not care about it directly but the in-app experience with good LAN comms can be pretty magical. It just sets a worrying trend, that Apple’s not bothering to weigh up the cost and benefits any more and just shutting down anything that doesn’t align with their prescribed vision. Next it’ll be “your app must declare all its BLE services in Info.plist” or “no more access to getifaddrs”. My bold prediction is that one day they’ll get rid of BSD sockets entirely. Not for a while but I believe the writing’s on the wall. If you want a platform that’s more than a funnel to the cloud I would be investing my energy pretty much anywhere else.

Update 25/8: I have noticed some readers are confused. This policy in this blog post is about using multicast groups directly from your app. Bonjour service discovery uses multicast DNS behind the scenes but it does not require this entitlement, only some configuration in Info.plist. Some applications of custom multicast could be reworked to use mDNS but they are not equivalent technologies.