@eskimo: Thanks for listening! (and it wasn't me, either) One last hint, because I DID implement an own authorization handler by the description I have given (and it works): You will be able to fairly reliably detect the presence of the authorization dialogue by listening to: UIApplicationWillResignActiveNotification and UIApplicationDidBecomeActiveNotification So if you are in the process of requesting network access, the app resigning active and becoming active again is a fairly good hint for the dialogue being shown and removed. After it has been shown and the user permitted local access, your ping will succeed. If it has been shown and your ping still fails, the user has very likely denied the request. Looking for a window, as suggested earlier, doesn't work. I'm open for improvement suggestions, as these notifications may also come up in the event of e.g. a call, or another system dialogue.

Update to my post: So pinging ourselves also triggers the network access dialogue (where localizing NSLocalNetworkUsageDescription doesn't work in XCode 12 GM / iOS 14 GM - be aware, fill out at least the English text in info.plist!). But pinging can at least confirm if the user has disabled the local network access AFTERWARDS. So you should probably go this way: Let the user confirm local network access, e.g. by doing such a ping. If you want to confirm that the user actually selected "yes", do the ping e.g every second until it succeeds. If you need to know if the user denied it, I think it's possibly to query the view hierarchy for the presence of a dialogue. Apple, you may read this: I'm not sure WHY such an API has been kept out. But as we need to find solutions, we need to do such hacks. Fortunately they work in most cases. But if the absence of such an API has the background to add some "fuzziness" about the user's intentions, you see that in the end it's possible to do it anyway. From my perspective, it is not understandable why such an API is missing and why we need to do several hacks to achieve what should have been part of the iOS 14 release. The absence of such an API is inconsistent with the other permission APIs, and as you see there are many reasons why such an API should also be part of the iOS 14 release. Giving that even the permission localization doesn't work leaves the impression of all of this thrown together in haste.

I've found an approach that might work for you as well: Get the local IP address of the iOS device. If you can't get it, you're not in WiFi. You will be able to get it even when no local network permissions are there! Now ping your own address. It will succeed in case of granted permissions. It fails to send the packet if there is no local network authorization. SimplePing is an example ping implementation and will fail with didFailToSendPacket: in such a case. I couldn't test a fresh install yet, but it's working properly when looking for disabled local network access. Hope this helps!

1... I am also in need for a permissions API. I have an app that controls Hue lights, and if the user revoked permission or never granted it, the app needs to be able to communicate this to the user. The absence of such an API is not only not in line with other permission APIs existing, it also means that we cannot inform our users about the actual issue nor give him information about how to work around it! Generic errors like having no internet connections are not sufficient! A blocked local network access is a third state and must be indicated. I agree that certain bad behaving apps need to get treated properly, but this is again a new API (background geofencing was the other) that is missing proper handling for certain valid cases. If you choose to add limited permissions, please work through all possible cases, and more importantly, please add and modify necessary functions BEFORE the golden master. That would be really helpful!

1... I am also in need for a permissions API. I have an app that controls Hue lights, and if the user revoked permission or never granted it, the app needs to be able to communicate this to the user. The absence of such an API is not only not in line with other permission APIs existing, it also means that we cannot inform our users about the actual issue nor give him information about how to work around it! Generic errors like having no internet connections are not sufficient! A blocked local network access is a third state and must be indicated. I agree that certain bad behaving apps need to get treated properly, but this is again a new API (background geofencing was the other) that is missing proper handling for certain valid cases. If you choose to add limited permissions, please work through all possible cases, and more importantly, please add and modify necessary functions BEFORE the golden master. That would be really helpful!