We have a similar issue with recording from the microphone, where also a buffer size of 1024 is requested - and callbacks come with a 1104 sized buffer. I might be wrong, but it appears that data exceeding 1024 bytes is actually garbage or empty.

Having the same issue without solution. Dear Apple, users should be able to use a different email address for security reasons.

@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!