iOS 14 How to trigger Local Network dialog and check user answer?

Question

I\'ve seen this Q/A What triggers, but it\'s not what I want. I also read this Network privacy permission check, but there is no answer. I also search for any methods or cla

Answer 1

In my case it was accessing this variable for some internal device statistics:

ProcessInfo.processInfo.hostName

Accessing this variable caused the alert to appear. If it doesn't cover your case perhaps you can search source code for some references around the local network/host.

Answer 2

I did open DTS request and had conversion with Apple support team. Here is some important parts which I included below.

How to check is access granted or not

From support team:

For know, there is no such an API to check user permission.

From support team:

If the user declines, the connection fails. Exactly how it fails depends on the network API you’re using and how you use that API.

• By default the connection will fail with NSURLErrorNotConnectedToInternet.
• If you set waitsForConnectivity on the session configuration, the request will wait for things to improve. In that case you’ll receive the -URLSession:taskIsWaitingForConnectivity: delegate callback to tell you about this. If the user changes their mind and enables local network access, the connection will then go through.

Unfortunately there’s no direct way to determine if this behaviour is the result of a local network privacy restriction or some other networking failure.

---

How to trigger this popup

From support team:

the problem here is that the local network permission alert is triggered by outgoing traffic and you do not generate any outgoing traffic. The only way around this is to generate some dummy outgoing traffic in order to trigger this alert.

I’ve seen other developers in this situation and the absence of a direct API to trigger the local network permission alert is quite annoying. I encourage you to file a bug about this.

I’ve been discussing this issue with the local network privacy team and our current advice for apps in your situation — that is, apps that want to receive broadcasts but don’t send any local network traffic — is as follows:

• The system should do a better job of handling this. We’re tracking that as a bug rdar://problem/67975514. This isn’t fixed in the current iOS 14.2b1 release but you should continue to test with iOS beta seeds as they are released.

• In the meantime you can force the local network privacy alert to show by sending a message. We specifically recommend that you send a message that’s roughly equivalent to the message you’re trying to receive, so in your case that means sending an IPv4 UDP broadcast.

UPDATE

For iOS 14.2 - prompt is received for inbound traffic FIXED. Because of this you don't need below example for simulating traffic to triggering prompt.

---

Here is class for dummy outgoing traffic simulation: example

That traffic will never leave the iOS device and thus, even if the interface is asleep, it won’t wake it up. And even if it did wake up the interface, the cost of that is trivial because you’re not doing it over and over again, just once in order to trigger the local network privacy alert.

Answer 3

Apple has (late September 2020) published a Local Network Privacy FAQ which answers this, although it does seem that further changes to make this easier are likely.

There are Swift and Objective-C code examples for how to trigger the prompt by a workaround:

Currently there is no way to explicitly trigger the local network privacy alert (r. 69157424). However, you can bring it up implicitly by sending dummy traffic to a local network address. The code below shows one way to do this. It finds all IPv4 and IPv6 addresses associated with broadcast-capable network interfaces and sends a UDP datagram to each one. This should trigger the local network privacy alert, assuming the alert hasn’t already been displayed for your app.

And as for how to check result, keep your eye on this FAQ answer which says:

If your goal is to connect to a local network address using NWConnection then, starting with iOS 14.2 beta, you can use the unsatisfied reason property.