The "X would like to find and connect to devices on your local network" prompt surprises a lot of developers, because it can appear when they did not knowingly add local network access, often triggered by an SDK. Since iOS 14, scanning or connecting to devices on the user's local network requires a permission and a purpose string, because that access can reveal what is on someone's home or office network. If your app genuinely needs it, declaring it correctly is straightforward; if it does not, an unexpected prompt is a sign something is reaching for the network that should not be. Here is what the permission is and how to handle it.
Short answer
Since iOS 14, an app that discovers or connects to devices on the user's local network, through Bonjour or mDNS discovery, network scanning, or direct local connections, must request the local network permission, declared with an NSLocalNetworkUsageDescription purpose string, and the system shows the user a prompt. Per Apple's documentation, this exists because local network access can reveal the devices on a user's network, a privacy concern. If a feature needs it, declare the purpose string and the Bonjour services you use; if it does not, an unexpected prompt usually means an SDK is scanning the network, which you should audit. Request it only when a feature requires it, and handle denial.
What you should know
- Local network access needs permission: since iOS 14, with a user prompt.
- A purpose string is required: NSLocalNetworkUsageDescription explaining why.
- It is a privacy gate: local access can reveal devices on the user's network.
- SDKs can trigger it unexpectedly: a library scanning the network prompts the user.
- Declare it only if a feature needs it: and declare your Bonjour services.
What is the local network permission?
It is iOS's consent gate for an app reaching devices on the user's local network. Discovering devices via Bonjour or mDNS, scanning the local subnet, or connecting directly to a device on the same network all require the local network permission, and the system prompts the user the first time your app attempts it, showing your NSLocalNetworkUsageDescription string. Apple added this in iOS 14 because local network access can enumerate the devices on a user's home or office network, smart-home gadgets, computers, other phones, which is sensitive information about the user's environment. So the prompt is a privacy control: the user decides whether your app may see and reach their local devices. For apps built to interact with local hardware, like controllers for smart-home or media devices, the permission is expected; for apps with no such feature, needing it at all is a question worth asking.
When do you need it, and when does an SDK trigger it?
When a feature interacts with local devices, or when a library does so on your behalf. The table clarifies.
| Situation | Needs the permission |
|---|---|
| Discovering local devices via Bonjour or mDNS | Yes |
| Connecting to a device on the same network | Yes |
| Scanning the local subnet | Yes |
| An SDK scanning the network for analytics or ads | Yes, and often unexpectedly |
| Only talking to your backend over the internet | No |
The legitimate cases are features that genuinely reach local devices. The surprising case is an SDK, sometimes an analytics or advertising library, that scans the local network for its own purposes, which triggers the prompt for your app even though you did not add local network functionality. That both alarms users, who do not expect your app to want their network, and can be a privacy problem, so an unexpected local network prompt is a signal to find out which dependency is reaching for the network.
How do you handle it correctly?
Request it only when a feature needs it, declare it properly, and audit for unexpected triggers. If your app interacts with local devices, add a clear NSLocalNetworkUsageDescription explaining why, declare the specific Bonjour service types you use in the relevant Info.plist key so discovery works, and handle the case where the user denies the permission by degrading gracefully. If your app has no local-device feature but the prompt appears, audit your SDKs to find which one is scanning the network, and remove or reconfigure it, since you do not want to ask users for access your app does not use. Keep the request tied to the feature and the moment it is needed, so the prompt makes sense to the user. The principle is the same as other permissions: ask only for what a feature uses, explain it, and do not let a dependency request access on your behalf without reason.
What to watch out for
The first trap is an unexpected local network prompt caused by an SDK scanning the network, which asks users for access your app does not need; audit your dependencies. The second is requesting the permission without a clear NSLocalNetworkUsageDescription, or without declaring your Bonjour services, which breaks discovery or the prompt. The third is not handling denial, leaving a local feature broken. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the entitlements, usage descriptions, and SDKs in your build, which helps you see whether local network access is declared and which dependency might be triggering it. The declaration and the feature design are yours to handle in the app.
What to take away
- Since iOS 14, discovering or connecting to devices on the user's local network requires the local network permission and an NSLocalNetworkUsageDescription purpose string, with a user prompt.
- It exists because local network access can reveal the devices on a user's network, which is a privacy concern.
- Request it only when a feature needs it, declare the purpose string and your Bonjour services, and handle denial; an unexpected prompt usually means an SDK is scanning the network.
- Use a pre-submission scan such as PTKD.com to see whether local network access is declared and which dependency might be triggering it.
