How iOS 16 Handles Local Network Permissions

In iOS 16, Apple enforces strict privacy safeguards that require third-party applications to obtain explicit user consent before discovering or communicating with devices on a local subnet. This system-level prompt is designed to prevent fingerprinting and unauthorized tracking via nearby hardware. This article explains the technical mechanisms that trigger the Local Network permission prompt in iOS 16, the configuration required by developers, and how the operating system handles user decisions.

How the Prompt Is Triggered

iOS 16 monitors network activity to detect when an application initiates interactions with the local area network (LAN). The permission dialog is not displayed upon installation; instead, it triggers dynamically at runtime during the app's first attempt to execute any of the following actions:

  • Bonjour Discovery: Browsing or advertising services using Multicast DNS (mDNS) through APIs like NWBrowser or NetServiceBrowser.
  • Direct Socket Connections: Opening raw TCP or UDP sockets targeting private IP ranges (such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16).
  • Multicast and Broadcast Traffic: Sending or listening to broadcast or multicast packets intended for local device pairing or smart home control.

When the application executes one of these operations, the operating system pauses the network call and renders a modal alert: "[App Name] would like to find and connect to devices on your local network."

Developer Configuration in Info.plist

For the prompt to display properly without crashing the application, developers must configure specific metadata entries in the app's Info.plist file:

  1. NSLocalNetworkUsageDescription (Privacy - Local Network Usage Description): A mandatory string explaining why the application needs to interact with the local network. This custom text appears directly inside the system dialog below the standard warning. If this key is omitted, iOS 16 terminates the application immediately when a local network call is attempted.
  2. NSBonjourServices: If the application utilizes Bonjour for discovery, developers must explicitly declare an array of every service type (e.g., _http._tcp, _matter._tcp) the app intends to browse or publish. Any service not declared in this list will fail to resolve.

User Decisions and System Behavior

The permission prompt offers two user actions: Don't Allow and Allow.

  • If Allowed: The operating system unblocks the paused network call. The app is granted access to send and receive traffic on local subnets, communicate with smart accessories, and discover Bonjour services.
  • If Denied: iOS blocks the local network access. Outgoing packets to local IPs are dropped, incoming local discovery responses are suppressed, and APIs return standardized errors indicating that the host is unreachable or permission was denied. Standard internet traffic directed toward public IP addresses remains unaffected.

Users can change their selection at any time by navigating to Settings > Privacy & Security > Local Network, where iOS 16 maintains a centralized list of all applications that have requested local access.