They’re trying to stop people from listening for all multicast traffic, presumably because it stops someone from fingerprinting based on the things on your network.

The restriction doesn’t stop you from using the NetService API (or friends) from listening for or advertising specific named mDNS services. You can continue to do that today without any extra entitlements. What it stops you from doing is listening for wildcards and sucking up everything — sadly, restricting multicast traffic on regular IP sockets is basically an extension of that.

Instead of trying to define a guideline that says “may not use multicast for this, that, blah”, apps instead just have to request it and explain why. It’s probably not a topic that the usual review team can consider without extreme levels of training beyond what’s necessary, and it’s a specialty network skill with lots of privacy traps. It also allows Apple to see who doesn’t request the permission but uses multicast anyways, because they might be using some sort of framework that is unknowingly tracking people, and then they can identify and start rejecting that framework storewide.

“How can we ensure every request for multicast escalates to someone qualified to make a decision that we can stand behind?” An essay question is a great answer, even if people hate the uncertainty. Better that than a new guideline!

Multicast can wreak havoc on a WiFi network. Clients that are further away from your AP require sending data at a slower rate and APs will try to send the data slow enough so that all clients can receive the traffic. In practice this means a 1mbps multicast stream will take far more than 1% of a 100mbps network and in some cases I have seen it shut down a network entirely. At my day job we disabled receiving multicast (IPTV) feeds over WiFi years ago because we have never seen it work well enough to be worth it.