This is a topic that’s come up a few times on the forums, so I thought I’d write up a summary of the issues I’m aware of. If you have questions or comments, start a new thread in the App & System Services > Networking subtopic and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Network Extension Provider Packaging There are two ways to package a network extension provider: App extension ( appex ) System extension ( sysex ) Different provider types support different packaging on different platforms. See TN3134 Network Extension provider deployment for the details. Some providers, most notably packet tunnel providers on macOS, support both appex and sysex packaging. Sysex packaging has a number of advantages: It supports direct distribution, using Developer ID signing. It better matches the networking stack on macOS. An appex is tied to the logged in user, whereas a sysex, and the networking stack itself, is global to the system as a whole. Given that, it generally makes sense to package your Network Extension (NE) provider as a sysex on macOS. If you’re creating a new product that’s fine, but if you have an existing iOS product that you want to bring to macOS, you have to account for the differences brought on by the move to sysex packaging. Similarly, if you have an existing sysex product on macOS that you want to bring to iOS, you have to account for the appex packaging. This post summarises those changes. Keep the following in mind while reading this post: The information here applies to all NE providers that can be packaged as either an appex or a sysex. When this post uses a specific provider type in an example, it’s just an example. Unless otherwise noted, any information about iOS also applies to iPadOS, tvOS, and visionOS. Process Lifecycle With appex packaging, the system typically starts a new process for each instance of your NE provider. For example, with a packet tunnel provider: When the users starts the VPN, the system creates a process and then instantiates and starts the NE provider in that process. When the user stops the VPN, the system stops the NE provider and then terminates the process running it. If the user starts the VPN again, the system creates an entirely new process and instantiates and starts the NE provider in that. In contrast, with sysex packaging there’s typically a single process that runs all off the sysex’s NE providers. Returning to the packet tunnel provider example: When the users starts the VPN, the system instantiates and starts the NE provider in the sysex process. When the user stops the VPN, the system stops and deallocates the NE provider instances, but leaves the sysex process running. If the user starts the VPN again, the system instantiates and starts a new instances of the NE provider in the sysex process. This lifecycle reflects how the system runs the NE provider, which in turn has important consequences on what the NE provider can do: An appex acts like a launchd agent [1], in that it runs in a user context and has access to that user’s state. A sysex is effectively a launchd daemon. It runs in a context that’s global to the system as a whole. It does not have access to any single user’s state. Indeed, there might be no user logged in, or multiple users logged in. The following sections explore some consequences of the NE provider lifecycle. [1] It’s not actually run as a launchd agent. Rather, there’s a system launchd agent that acts as the host for the app extension. App Groups With an app extension, the app extension and its container app run as the same user. Thus it’s trivial to share state between them using an app group container. Note When talking about extensions on Apple platforms, the container app is the app in which the extension is embedded and the host app is the app using the extension. For network extensions the host app is the system itself. That’s not the case with a system extension. The system extension runs as root whereas the container app runs an the user who launched it. While both programs can claim access to the same app group, the app group container location they receive will be different. For the system extension that location will be inside the home directory for the root user. For the container app the location will be inside the home directory of the user who launched it. This does not mean that app groups are useless in a Network Extension app. App groups are also a factor in communicating between the container app and its extensions, the subject of the next section. IMPORTANT App groups have a long and complex history on macOS. For the full story, see App Groups: macOS vs iOS: Working Towards Harmony. Communicating with Extensions With an app extension there are two communication options: App-provider messages App groups App-provider messages are supported by NE directly. In the container app, send a message to the provider by calling sendProviderMessage(_:responseHandler:) method. In the appex, receive that message by overriding the handleAppMessage(_:completionHandler:) method. An appex can also implement inter-process communication (IPC) using various system IPC primitives. Both the container app and the appex claim access to the app group via the com.apple.security.application-groups entitlement. They can then set up IPC using various APIs, as explain in the documentation for that entitlement. With a system extension the story is very different. App-provider messages are supported, but they are rarely used. Rather, most products use XPC for their communication. In the sysex, publish a named XPC endpoint by setting the NEMachServiceName property in its Info.plist. Listen for XPC connections on that endpoint using the XPC API of your choice. Note For more information about the available XPC APIs, see XPC Resources. In the container app, connect to that named XPC endpoint using the XPC Mach service name API. For example, with NSXPCConnection, initialise the connection with init(machServiceName:options:), passing in the string from NEMachServiceName. To maximise security, set the .privileged flag. Note XPC Resources has a link to a post that explains why this flag is important. If the container app is sandboxed — necessary if you ship on the Mac App Store — then the endpoint name must be prefixed by an app group ID that’s accessible to that app, lest the App Sandbox deny the connection. See the app groups documentation for the specifics. When implementing an XPC listener in your sysex, keep in mind that: Your sysex’s named XPC endpoint is registered in the global namespace. Any process on the system can open a connection to it [1]. Your XPC listener must be prepared for this. If you want to restrict connections to just your container app, see XPC Resources for a link to a post that explains how to do that. Even if you restrict access in that way, it’s still possible for multiple instances of your container app to be running simultaneously, each with its own connection to your sysex. This happens, for example, if there are multiple GUI users logged in and different users run your container app. Design your XPC protocol with this in mind. Your sysex only gets one named XPC endpoint, and thus one XPC listener. If your sysex includes multiple NE providers, take that into account when you design your XPC protocol. [1] Assuming that connection isn’t blocked by some other mechanism, like the App Sandbox. Inter-provider Communication A sysex can include multiple types of NE providers. For example, a single sysex might include a content filter and a DNS proxy provider. In that case the system instantiates all of the NE providers in the same sysex process. These instances can communicate without using IPC, for example, by storing shared state in global variables (with suitable locking, of course). It’s also possible for a single container app to contain multiple sysexen, each including a single NE provider. In that case the system instantiates the NE providers in separate processes, one for each sysex. If these providers need to communicate, they have to use IPC. In the appex case, the system instantiates each provider in its own process. If two providers need to communicate, they have to use IPC. Managing Secrets An appex runs in a user context and thus can store secrets, like VPN credentials, in the keychain. On macOS this includes both the data protection keychain and the file-based keychain. It can also use a keychain access group to share secrets with its container app. See Sharing access to keychain items among a collection of apps. Note If you’re not familiar with the different types of keychain available on macOS, see TN3137 On Mac keychain APIs and implementations. A sysex runs in the global context and thus doesn’t have access to user state. It also doesn’t have access to the data protection keychain. It must use the file-based keychain, and specifically the System keychain. That means there’s no good way to share secrets with the container app. Instead, do all your keychain operations in the sysex. If the container app needs to work with a secret, have it pass that request to the sysex via IPC. For example, if the user wants to use a digital identity as a VPN credential, have the container app get the PKCS#12 data and password and then pass that to the sysex so that it can import the digital identity into the keychain. Memory Limits iOS imposes strict memory limits an NE provider appexen [1]. macOS imposes no memory limits on NE provider appexen or sysexen. [1] While these limits are not documented officially, you can get a rough handle on the current limits by reading the posts in this thread. Frameworks If you want to share code between a Mac app and its embedded appex, use a structure like this: MyApp.app/ Contents/ MacOS/ MyApp PlugIns/ MyExtension.appex/ Contents/ MacOS/ MyExtension … Frameworks/ MyFramework.framework/ … There’s one copy of the framework, in the app’s Frameworks directory, and both the app and the appex reference it. This approach works for an appex because the system always loads the appex from your app’s bundle. It does not work for a sysex. When you activate a sysex, the system copies it to a protected location. If that sysex references a framework in its container app, it will fail to start because that framework isn’t copied along with the sysex. The solution is to structure your app like this: MyApp.app/ Contents/ MacOS/ MyApp Library/ SystemExtensions/ MyExtension.systemextension/ Contents/ MacOS/ MyExtension Frameworks/ MyFramework.framework/ … … That is, have both the app and the sysex load the framework from the sysex’s Frameworks directory. When the system copies the sysex to its protected location, it’ll also copy the framework, allowing the sysex to load it. To make this work you have to change the default rpath configuration set up by Xcode. Read Dynamic Library Standard Setup for Apps to learn how that works and then tweak things so that: The framework is embedded in the sysex, not the container app. The container app has an additional LC_RPATH load command for the sysex’s Frameworks directory (@executable_path/../Library/SystemExtensions/MyExtension.systemextension/Contents/Frameworks). The sysex’s LC_RPATH load command doesn’t reference the container app’s Frameworks directory (@executable_path/../../../../Frameworks) but instead points to the sysex’s Framweorks directory (@executable_path/../Frameworks). Entitlements When you build an app with an embedded NE extension, both the app and the extension must be signed with the com.apple.developer.networking.networkextension entitlement. This is a restricted entitlement, that is, it must be authorised by a provisioning profile. The value of this entitlement is an array, and the values in that array differ depend on your distribution channel: If you distribute your app directly with Developer ID signing, use the values with the -systemextension suffix. Otherwise — including when you distribute the app on the App Store and when signing for development — use the values without that suffix. Make sure you authorise these values with your provisioning profile. If, for example, you use an App Store distribution profile with a Developer ID signed app, things won’t work because the profile doesn’t authorise the right values. In general, the easiest option is to use Xcode’s automatic code signing. However, watch out for the pitfall described in Exporting a Developer ID Network Extension. Revision History 2025-11-06 Added the Entitlements section. Explained that, with sysex packaging, multiple instances of your container app might connect simultaneously with your sysex. 2025-09-17 First posted.

Question: Best Practice for NEFilterRule and NENetworkRule Initializers with Deprecated NEHostEndpoint? Hi all, I'm looking for guidance on the right way to construct an NEFilterRule that takes a NENetworkRule parameter. Reading the latest documentation, it looks like: All initializers for NENetworkRule that accept an NEHostEndpoint are now deprecated, including initWithDestinationHost:protocol: and those using the various *Network:prefix: forms. NEHostEndpoint itself is also deprecated; Apple recommends using the nw_endpoint_t type from the Network framework instead. However, NEFilterRule still requires a NENetworkRule for its initializer (docs). With all NENetworkRule initializers that take NEHostEndpoint deprecated, it’s unclear what the recommended way is to create a NENetworkRule (and thus an NEFilterRule) that matches host/domain or network traffic. What’s the proper way to construct these objects now—should we create the endpoints using nw_endpoint_t and use new/undocumented initializers, or is there an updated approach that’s considered best practice? Helpful doc links for reference: NEFilterRule docs NENetworkRule docs NWHostEndpoint (now deprecated)

I am seeking clarification regarding the capabilities and limitations of deploying content filter profiles, such as web content filters, on unsupervised iOS devices through MDM solutions. Specifically, is per-app content filtering supported on unsupervised devices, or is it restricted to supervised devices only? If such restrictions exist, are there recognized workarounds? Additionally, I would like to understand if there are specific permissions or entitlements that enable apps to perform advanced filtering or monitoring functions on unsupervised devices. Any guidance or references to official documentation would be greatly appreciated.

I am making a USB attached IoT device that follows the Matter approach to connectivity (IP/mDNS/DHCP). I am having conflicts with it as it appears to MacOS as an Ethernet adapter and this is causing it to be assigned as a "default" route, interfering with routing when my Mac is connected to NAT based WiFi. I'd like to be able to hint to MacOS & iPadOS that this is not a routable private network, the subnet should be respected and a default route should not be assigned to it, otherwise the order of the device connection is used by the IP routing tables and I am concerned my non-routable private network will initialize before Wifi and block NAT based internet connectivity. How can I hint to MacOS/iPadOS "this is not a routable private network, this is not a NAT, do not assign me a default route beyond the subnet I have provided you."

We are developing an iOS application with a key feature designed to enhance user safety: real-time assessment of Wi-Fi network security. The "Safe Wi-Fi" feature aims to inform users about the security level of the Wi-Fi network they are currently connected to. Our goal is to provide this information seamlessly and continuously, even when the user isn't actively using the app. Currently, we've implemented this feature using a NWPathMonitor. The limitation of NWPathMonitor is that it doesn't function when the app is in a kill state. We are looking for guidance on how to achieve persistent Wi-Fi security monitoring in the background or when the app is killed. Is there any API (Public, Special API, etc) or a recommended approach that allows for real-time Wi-Fi connection monitoring (including connection changes and network details) even when the app is not actively running or is in a kill state. Thank you in advance for your help.

Hi, I am trying to create an App which connects to a Device via Wifi and then has to do some HTTP Requests. Connecting to the Wifi is working properly but when I try to make an HTTP API Call I get the response that the Domain is unavailable (No Internet Connection). I created the App in Flutter on Android everything works perfectly. The packages are all iOS Compatible. But in Safari the URL works so it is probably a permission Issue. I have the Following permissions granted: NSAppTransportSecurity NSBonjourServices NSLocalNetworkUsageDescription I even have Multicast Networking When I test the App I get asked to grant the access to local Network which I am granting. I don´t know what I should do next can somebody help? Feel free to ask for more Information

Hi! We are planning to build an app for a research project that collects sensitive information (such as symptoms, photos and audio). We don't want to store this data locally on the phone or within the app but rather have it securely transferred to a safe SFTP server. Is it possible to implement this i iOS, and if so, does anyone have any recommendations on how to do this?

Hello, I'm running into an issue while developing an iOS app that requires local network access. I’m using the latest MacBook Air M4 with macOS sequoia 15.5 and Xcode 16.1. In the iOS Simulator, my app fails to discover devices connected to the same local network. I’ve already added the necessary key to the Info.plist: NSLocalNetworkUsageDescription This app needs access to local network devices. When I run the app on a real device and M2 Chip Macbook's simulators, it works fine for local network permission as expected. However, in the M4 Chip Macbook's Simulator: The app can’t find any devices on the local network Bonjour/mDNS seems not to be working as well I’ve tried the following without success: Restarting Simulator and Mac Resetting network settings in Simulator Confirming app permissions under System Settings > Privacy & Security Has anyone else encountered this issue with the new Xcode/macOS combo? Is local network access just broken in the Simulator for now, or is there a workaround? Thanks in advance!

Hi, I am making a AI-Powered app that makes api requests to the openai API. However, for security, I set up a vercel backend that handles the API calls securely, while my frontend makes a call to my vercel-hosted https endpoint. Interestingly, whenever I try to make that call on my device, an iPhone, I get this error: Task <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10> finished with error [-1003] Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={_kCFStreamErrorCodeKey=-72000, NSUnderlyingError=0x1435783f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorDomainKey=10, _kCFStreamErrorCodeKey=-72000, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 3ms using unknown from query, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[lte], ipv4, ipv6, dns, expensive, uses cell}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10>" ), NSLocalizedDescription=A server with the specified hostname could not be found., NSErrorFailingURLStringKey=https://[my endpoint], NSErrorFailingURLKey=https://[my endpoint], _kCFStreamErrorDomainKey=10} I'm completely stuck because when I directly make https requests to other api's like openai's endpoint, without the proxy, it finds the server completely fine. Running my endpoint on terminal with curl also works as intended, as I see api key usages. But for some reason, on my project, it does not work. I've looked through almost every single post I could find online, but a lot all of the solutions are outdated and unhelpful. I'm willing to schedule a call, meeting, whatever to resolve this issue and get help more in depth as well.

We are a Layer 3 VPN provider offering a comprehensive SASE (Secure Access Service Edge) solution that includes TLS inspection, threat protection, granular access control, and secure access to private resources. One of the key challenges we face involves TLS inspection. Many mobile applications, especially on iOS, implement certificate pinning, which causes them to fail when TLS inspection is applied. These apps expect connections to be secured with a specific certificate or trusted certificate authority, and inspection disrupts this trust model. On iOS, the current limitation is that the Packet Tunnel Provider extension does not provide visibility into the originating application (i.e., there is no API to obtain the app’s bundle ID or package name associated with a given network connection). Due to this, we are unable to dynamically determine whether TLS inspection should be bypassed for a particular app. While Apple’s Per-App VPN is one possible solution, it introduces a significant drawback: any applications that are excluded from the VPN configuration are entirely outside the VPN tunnel. This means they do not benefit from any of our SASE features — including secure access to internal resources, DNS/web content filtering, or threat detection. This limits the effectiveness of our solution in environments where both inspection and secure access are critical. We would like to understand whether iOS has any current or planned capabilities to associate a network flow (e.g., a 5-tuple: source IP, destination IP, source port, destination port, and protocol) with the originating app. Such a capability would allow us to programmatically identify certificate-pinned apps and selectively disable TLS inspection without excluding them entirely from the VPN, thereby preserving the full set of SASE protections. Is there any guidance or roadmap update from Apple that addresses this use case?

I'm facing an issue where if a WiFi network is turned off and back on within a short time frame (2-4 seconds), iOS still shows the device as connected but does not send a new DHCP request. This causes a problem for my network device, which relies on the DHCP request to assign an IP address. Without the request, the device is unable to establish a socket connection properly. Is there any way to force iOS to send a DHCP request immediately when reconnecting to the network in this scenario? Are there any known workarounds or configurations that might help ensure the DHCP process is re-triggered? Any insights would be appreciated. Thanks!

Hi we want to use CONNECT-IP extension within the MASQUE protocol suite. we want to be able to reroute ICMP packets from our machine and redirect them to our MASQUE proxy. we want to avoid a creation of virtual interface or modifying the routing tables. is it possible, if so, how can it be achieved. thanks

Hi, when I perform an overlay installation via a PKG on macOS for an application containing the NEFilterDataProvider functionality, there is a chance that the entire system network becomes unreachable. Disabling the corresponding Content Filter in "System Settings > Network > Filters" immediately restores network connectivity. This issue does not occur every time, with a frequency of approximately 1 in 20 installation attempts.  The following details may help identify the problem: The Filter.app containing the NEFilterDataProvider resides within the main app's Resources directory, e.g., /Applications/Main.app/Contents/Resources/Filter.app Main.app is installed via a PKG; the issue typically occurs during an overlay installation of Main.app. The NEFilterDataProvider operates as a System Extension. The func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict {} returns .allow. Wireshark packet captures show TCP packets but no UDP packets; TCP handshakes cannot complete. Disabling the corresponding content filter in "System Settings > Network > Filters" restores the network; re-enabling it breaks connectivity again. After waiting for a period, approximately 30-60 minutes, network connectivity can recover automatically. What causes this and how can it be fixed? Any workarounds?

I'm developing an iOS application in Swift that performs API calls using URLSession.shared. The requests work correctly when the app is in the foreground. However, when the app transitions to the background (for example, when the user switches to another app), the ongoing API calls are either paused or do not complete as expected. What I’ve tried: Using URLSession.shared.dataTask(with:) to initiate the API requests Observing application lifecycle events like applicationDidEnterBackground, but haven't found a reliable solution to allow requests to complete when backgrounded Goal: I want certain API requests to continue running or be allowed to complete even if the app enters the background. Question: What is the correct approach to allow API calls to continue running or complete when the app moves to the background? Should I be using a background URLSessionConfiguration instead of URLSession.shared? If so, how should it be properly configured and used in this scenario?

I have a requirement to create a VPN app which only works on Cellular. But I'm facing an issue like when wifi is ON, OS is using wifi interface to route the traffic instead of cellular. I tried some ways like let cellularParams = NWParameters.udp cellularParams.requiredInterfaceType = .cellular But this is not working properly as expected. How can I manually bind to cellular interface in iOS?

I would like to inquire about the feasibility of developing an iOS application with the following requirements: The app must support real-time audio communication based on UDP. It needs to maintain a TCP signaling connection, even when the device is locked. The app will run only on selected devices within a controlled (closed) environment, such as company-managed iPads or iPhones. Could you please clarify the following: Is it technically possible to maintain an active TCP connection when the device is locked? What are the current iOS restrictions or limitations for background execution, particularly related to networking and audio? Are there any recommended APIs or frameworks (such as VoIP, PushKit, or Background Modes) suitable for this type of application?

I have an iOS app that connects to a server running on macOS by leveraging NWListener & NWBrowser. It also makes use of the peerToPeer functionality / AWDL offered via the Network framework. This works great in the iOS app. Now I would like to add support for Shortcuts / App Intents in general. The NWConnection on its own is also working great in the App Intent, but only if I provide the host/port manually, which means I can't use the peer to peer functionality. If I try to run my NWBrowser in the AppIntent it immediately changes its state to failed with a NoAuth (-65555) error: nw_browser_cancel [B1517] The browser has already been cancelled, ignoring nw_browser_cancel(). nw_browser_fail_on_dns_error_locked [B1518] DNSServiceBrowse failed: NoAuth(-65555) NWClientManager: Browser failed: -65555: NoAuth I haven't found documentation/information on whether NWBrowser should work in an AppIntent extension or not.

I am experiencing issue - Phone16 cannot to connect to WPA3-Enterprise Transition Mode SSID on Wi-Fi 7 AP. While iphone17 do not have this issue. And I have already created ticket - FB20924263. Here are the details below: Product: iOS 26.1, Device Models: iPhone 16 (fails), iPhone 17 (works) Network: Wi-Fi 7 AP, 2.4 GHz and 6 GHz disabled, only 5 GHz enabled Feature Area: WPA3-Enterprise Transition Mode connectivity Expected Behavior: Both iPhone 16 and iPhone 17 running iOS 26.1 should successfully connect to a WPA3-Enterprise Transition Mode SSID when configured according to the standard. Actual Behavior: iPhone 16 (iOS 26.1) fails to connect to the SSID. iPhone 17 (iOS 26.1) connects successfully under the same conditions. Steps to Reproduce: Configure a Wi-Fi 7 AP: Disable 2.4 GHz and 6 GHz bands, keep only 5 GHz active. Add an SSID using WPA3-Enterprise Transition Mode. Attempt to connect with iPhone 16 (iOS 26.1) → fails. Attempt to connect with iPhone 17 (iOS 26.1) → succeeds. Additional Notes: When I disable 11be mode and make the DUT run under 11ax mode, then iPhone16 can also connect to the WPA3-Enterprise Transition Mode SSID As I’m a WiFi router developer, then I did one more thing, keep DUT under 11be mode, but do not enable MLO for that SSID (Remove MultiLink relate IE in beacon), then iPhone16 can also connect to the WPA3-Enterprise Transition Mode SSID It seems Iphone16 with Broadcom wifi chip solution has some specific policy for MLO + WPA3-Enterprise Transition Mode, while iphone17 with apple wifi chip solution do not add such limitation Also test other android devices and not found this issue

Hi, I’m trying out my app with Xcode 26, running on an iOS 26 simulator. I'm having issues with URLSessions, it crashes when I set the URLSessionConfiguration to default, and if I don’t use the URLSessionConfiguration, it crashes if I use URLSession.shared. When running in a real device, it doesn't crash, but any network request will hang and time out after a while. Is it a known issue in the latest beta versions?

Hi I am developing the packet tunnel extension on a SIP enabled device. If I build the app and notarize and install it on the device, it works fine. If I modify, build and execute the App (which contains the system extension), it fails with below error. 102.3.1.4 is production build. And 201.202.0.101 is for XCode build. SystemExtension "&lt;&lt;complete name&gt;&gt;.pkttunnel" request for replacement from 102.3.1.4 to 201.202.0.101 Packet Tunnel SystemExtension "&lt;&lt;complete name&gt;&gt;.pkttunnel" activation request did fail: Error Domain=OSSystemExtensionErrorDomain Code=8 "(null)" If SIP is disabled, it works fine. Is there a way the system extension can be developed even if SIP remains enabled?