That thing makes it annoying for the kind of applications my company does, that needs to communicate with other devices on the local network.

It's annoying because it's not like other permissions, where you can ask the OS to prompt the user, and check if the user granted it or not, but it's some special permission. If the user, by mistake because it doesn't know that it's needed, doesn't give it one time it's impossible to ask again, and the app doesn't have a way to know that the permission is not granted. It's just things that the customer service has to handle, and that is bad.

Sure, right to ask a permission, so make it like a regular permission as the location permission.

> It's annoying because it's not like other permissions

Normally if I want to use a permission, say location, I need to provide a value for given permission in my app's `info.plist` file, and if I don't and the app tries to grab the current location, it crashes with logs yelling at me to provide a description for the location privacy key.

With local network permissions it's different.

I've never had to do any local networking in my career as an iOS dev so downloaded Apple's peer to peer example app (https://developer.apple.com/documentation/network/building_a...) and removed the `Privacy - Local Network Usage Description` key/value pair from the `info.plist` file and ran the app on my device.

I fully expected a crash with a description telling me to add this key but iOS just filled in the missing description with a default value and asked away. I wonder why that permission is treated differently from the rest?

Probably because they introduced it afterwards, and thus to not break compatibility with all other apps they tried to make it transparent to the developer. Except it's not.

I get that Apple is going into the direction of forbidding local LAN communication because they want you to implement Homekit protocol in the hardware, except that is a pain, requires certification of the hardware and requires a physical chip inside the hardware.

If you're truly not being malicious then open source your app and get it added to the alpine repos so people can run it in ish.

I assume signal is udp hole punching to get around NAT.

Signal uses local networking for the account migration functionality: https://support.signal.org/hc/en-us/articles/360007059752-Ba...

You scan a QR code with one device and it transfers the entire account state to the new phone.

What's some good resources on understanding NAT and udp hole punching that explain it in an intuitive manner?

The simplest take on the concept is get a 3rd party with a public address to exchange the current port tuples used to connect to it between the 2 clients so the clients can then use this information to connect directly.

Beyond the basic take on it there really isn't an intuitive single explanation because "simple" things like "NAT traversal" quickly turn into "Full-cone NAT to Port-restricted NAT with UPnP behind CG-NAT" individual corner cases endlessly fighting the need to just go to IPv6.

Apple does require a string for location access motivation, hopefully they'll do that for this one as well. Ideally all of them.