As a developer, the annoying thing about the "Local Network" permission is that:
1) It's poorly implemented. Unlike other permissions, there's no way to explicitly trigger the prompt. It just pops up at Apple's discretion. There's no way to give it a "soft landing" for cases where it's necessary for core app features. And there's no way to check if the permission has been granted or not.
2) More importantly: Apple's own apps don't trigger this warning, which makes the playing field unfair. AirPlay etc. work seamlessly, whereas any competitor's tech doesn't. And as a developer, since you can't tell if this permission has been granted or not, you're left with a poor user experience.
I'm particularly fed up of (2). If Apple is going to introduce restrictions, they need to apply to their own apps as well. AirPlay and AirDrop need to each ask for Bluetooth and local network access. The Photos app needs to trigger the "Select photos, Allow All, Deny" prompt on launch. The Camera app shouldn't be able to write to the photo library without triggering the same prompt too.
That gives them an incentive to design the user experience around these restrictions well, and maybe be more creative with how to solve for this too rather than confusing dialogs.
Currently they have a disincentive to design this stuff well. Any iOS developer that's had to work with these APIs knows that they are designed absolutely awfully with arbitrary and unexpected limitations.
Not sure if this is what you mean, but there could be multiple apps installed that write to the device photo library. You may not want the developer of one camera app to be able to access all photos on the device.
But this raises a related point about how frustrating Apple's APIs are here: When an app is granted the "Write to photo library" permission by the user, it can only write. It can't read back what it's written, ever. You might expect that writing to the library might return a token that can be used to read that photo back. Nope.
Android, for all its faults, does a much better job here. The OS keeps track of the app that wrote the photo -- and that app can read that photo indefinitely, unless another app edits that photo (and thus becomes the owner). A much better design.
On iOS, to read back photos from the library, you have to ask for the "All photos" read permission, which few people will grant you. "Why does my camera want to read all the photos on my device?! Deny!".
And just like that, you can't compete with the built-in camera which shows thumbnails of recently taken photos and allows you to swipe through them.
Apple has no incentive to fix this either, because their own apps bypass this permission system.
No argument from me but regarding workarounds for (1), accessing ProcessInfo.processInfo.hostName has been a reliable pop-up trigger for me for a long time. Eskimo also offers some (esoteric) suggestions for how to notice if your network operation has been denied due to lack of permission: https://developer.apple.com/forums/thread/663852
1) It's poorly implemented. Unlike other permissions, there's no way to explicitly trigger the prompt. It just pops up at Apple's discretion. There's no way to give it a "soft landing" for cases where it's necessary for core app features. And there's no way to check if the permission has been granted or not.
2) More importantly: Apple's own apps don't trigger this warning, which makes the playing field unfair. AirPlay etc. work seamlessly, whereas any competitor's tech doesn't. And as a developer, since you can't tell if this permission has been granted or not, you're left with a poor user experience.
I'm particularly fed up of (2). If Apple is going to introduce restrictions, they need to apply to their own apps as well. AirPlay and AirDrop need to each ask for Bluetooth and local network access. The Photos app needs to trigger the "Select photos, Allow All, Deny" prompt on launch. The Camera app shouldn't be able to write to the photo library without triggering the same prompt too.
That gives them an incentive to design the user experience around these restrictions well, and maybe be more creative with how to solve for this too rather than confusing dialogs.
Currently they have a disincentive to design this stuff well. Any iOS developer that's had to work with these APIs knows that they are designed absolutely awfully with arbitrary and unexpected limitations.