31

What actual method calls, excluding Bonjour, triggers the "would like to find and connect to devices on your local network" permission notification on iOS 14?

This is the screen shot from the WWDC session on this new permission. Which is only somewhat helpful as an overview. I'm more interested in figuring out what all method calls trigger this.

enter image description here

William GP
  • 1,252
  • 1
  • 14
  • 29

8 Answers8

26

If you're using react native with a debug configuration, then you are including all the code responsible for communicating with your dev machine so you can probably ignore this message.

However it's best to check you have no other libs that require access too. To do this just build a Release version and see if the message persists.

James Trickey
  • 1,322
  • 13
  • 21
8

In a nutshell, Bonjour. Its use is no longer "transparent". See https://developer.apple.com/videos/play/wwdc2020/10110/ for more information:

If your app interacts with devices using Bonjour or other local networking protocols, you must add support for local network privacy permissions in iOS 14.

Even an existing app is subject to this rule; the first attempt to use Bonjour triggers the authorization alert.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • 5
    It's a pity, really, because it scares the user. The first time I saw this, I denied authorization — thereby completely crippling the app I was using. After a while I realized what had happened...! – matt Aug 21 '20 at 14:49
  • 2
    More than just Bonjour is triggering this though – William GP Aug 21 '20 at 15:03
  • Yup, that's why I said "in a nutshell". For more details, watch the video. – matt Aug 21 '20 at 15:39
  • I watched the video, but all it told me was that the sample app did not immediately trigger it. It didn't tell me what specific feature prevented the notification upon launch. – PhoenixB Sep 04 '20 at 18:12
  • @matt We have got the multicast entitlement. Since then, UDP packet reception started to work spuriously. We never got the authorization dialog and our app is not authorized in Privacy/Local Network. We tried to trigger the dialog sending data with: a) TcpSocket class b) GCDAsyncSocket sending TCP packet c) GCDAsyncUdpSocket sending UDP packet to joinMulticastGroup d) GCDAsyncUdpSocket broadcasting UDP packet e) reusing the example from Apple sending multicast packets with NWConnectionGroup None of the above actions are triggering the authorization dialog. Would you have any idea? – Daniel Mavrakis Oct 10 '20 at 17:23
  • @DanielMavrakis Please don't piggy-back on someone else's question/answer to make some other point. If you have a new question (and it sounds like you do), please ask it as an actual question. – matt Oct 10 '20 at 17:25
  • @matt Ok will do – Daniel Mavrakis Oct 11 '20 at 19:50
  • @matt just done it at thanks for your advice. – Daniel Mavrakis Oct 11 '20 at 20:18
6

Apple (Eskimo on the Dev Forums) released a FAQ providing more details around this alert: https://developer.apple.com/forums/thread/663858

Particularly, providing more info as to what triggers this alert is FAQ-2: https://developer.apple.com/forums/thread/663874

What operations require local network access?

The general rule is that outgoing traffic to a local network address requires that the user grant your app local network access. Common scenarios include:

  • Making an outgoing TCP connection — yes
  • Listening for and accepting incoming TCP connections — no
  • Sending a UDP unicast — yes
  • Sending a UDP multicast — yes
  • Sending a UDP broadcast — yes
  • Receiving an incoming UDP unicast — no
  • Receiving an incoming UDP multicast — yes
  • Receiving an incoming UDP broadcast — yes

These TCP and UDP checks are done at the lowest levels of the system and thus apply to all networking APIs. This includes Network framework, BSD Sockets, NSStream, NSURLSession and WKWebView, and any other protocols that you layer on top of those.

IMPORTANT Receiving an incoming UDP multicast or broadcast does not currently require local network access but, because we hope to change that in a future update, our advice right now is that you write your code as if did (r. 69792887, 70017649).

Resolving link-local DNS names (those ending with local, per RFC 6762) requires local network access. Again, this check applies to a wide variety of APIs including <dns_sd.h>, <net_db.h>, Network framework, NSStream, and NSURLSession.

Finally, all Bonjour operations require local network access:

  • Registering a service with Bonjour — yes
  • Browsing for Bonjour services — yes
  • Resolving a Bonjour service — yes

Again, these checks apply to all APIs that use Bonjour, including <dns_sd.h>, Network framework, NSNetService, and Multipeer Connectivity.

Note You must declare the Bonjour service types you use in your Info.plist. See How do I map my Multipeer Connectivity service type to an entry in the Bonjour services property? for details.

Bonjour-based services where you don’t see any details of the network do not require local network access. These include:

  • AirPlay — no
  • Printing via UIKit — no
William GP
  • 1,252
  • 1
  • 14
  • 29
1

One of my apps was triggering this prompt unexpectedly in our internet multiplayer mode. We use RakNet for our networking (which is a C++ lib that uses BSD sockets to send/receive UDP) and I was able to track the problem to the RNS2_Berkley::BindShared function here.

After creating a UDP socket, RakNet tests health/validity of the socket by having it send a little test packet to itself. iOS 14 was flagging this send-to-self behaviour as communication on the local network. I'm not sure if this send-to-self behaviour is a common pattern in socket programming, or a particular quirk of RakNet. Frustratingly, the OS prompt didn't actually appear until later when the socket was used for real which made the issue very hard to track.

I think that this is a false-positive from the OS and raised it with Apple (FB8802121). I won't be holding my breath though so I've just disabled that RakNet behaviour for iOS and am hoping that it wasn't too important.

Edit: To more directly answer the original question: sendto is a method call that can trigger this prompt.

Columbo
  • 6,648
  • 4
  • 19
  • 30
1

I get rejected from apple app review for this alert. I'm using GCDWebServer which creates an embedded http server in my app.

I think I should provide a message in info.plist to tell user what my app want to do. Before I didn't set the text string in it.

And I would like to update if this will pass the app review.

<key>NSLocalNetworkUsageDescription</key>
<string>xxx uses the local network to connect with devices around you.</string>
Zhou Haibo
  • 1,681
  • 1
  • 12
  • 32
0

Regarding iOS 14: permission request: would like to find and connect to devices on your local network and after numerous deploys to my physical device, I have figured out what causes this in my case.

I have a Xamarin.Forms app which

  1. calls localhost:xxxx to do some local logging while I develop
  2. I use a product thats called LiveSharp that does local hot reloading for XAML AND C# code changes.

So Livesharp actually communicates with a server on my localhost as well. After disabling both of these and a fresh clean install on my physical device, the permission request has GONE .. Yay

Note: I had to completely remove LiveSharp nuget packages from my project. Also I tried to re-enable my localhost logging, and for some reason the permission request does not appear.. :headscratch

So: remove any localhost communication that happens in your app. Or at least put an if statement around it allowing it if set to true in appsettings

Atif Rehman
  • 417
  • 6
  • 6
  • 1
    Just a note that if the domain suffix of the requested URL is `local` (e.g. `http://foo.bar.local/something`), this also triggers the local network permission request! – DaveAlden May 24 '21 at 08:34
0

I also have a Xamarin app and I used the package LiveXaml. After removing it the message was gone.

sobo
  • 887
  • 8
  • 7
0

If there is an empty string entry in your Entitlements.plist for com.apple.developer.associated-domains then that will also trigger the "would like to find and connect to devices..." permissions popup

Dev Guest
  • 1