I have recently restarted an old code base. The app uses App Groups to communicate with network and endpoint system extensions. For some reason, in Xcode > Target > Signing & Capabilities the app groups are showing up with red text. I feel the red signifies a problem, but I cannot figure out what it is. The app compiles and runs, but I feel there is problem that I am missing. Any idea why App Group names would be displayed in red?

Hi, I’m expecting the demo from Apple, but I think I’m seeing different behavior on my end. Here are the steps I followed: Run the SampleEndpointApp example. Copy SampleEndpointApp to the /Applications folder. Run and enable the Extension and Full Disk Access → Everything works properly. I modify something in the example and start again from step #1, but nothing gets updated as shown in the demo video. The only way I can make it work is by going into Settings, manually removing the ES extension, and then running the app again. My concern is: if I deliver the application to clients, how can I properly update the extension without requiring them to manually remove it first? Thanks,

Hi! When starting my app which is loading a Content Filter Network Extension I am getting the following error : sysextd: <bundle_id> : extension failed category property check: extensions belonging to the com.apple.system_extension.endpoint_security category require a later version of operating system to launch ... OSSystemExtensionRequest didFailWithError for <bundle_id> : The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 9.) This is happening on a VM running Sonoma 14.7.8. I upgraded the VM to the latest available OS and the system extension is loading just fine. My question is : reading the documentation, I understand that the Network Extensions are supported starting with macOS 10.10+. Why is this not working on my Sonoma 14.7.8 VM?

I've alluded to this before in these posts and there are some posts from others about this, e.g. https://developer.apple.com/forums/thread/759845 and I've filed some bugs related to the behavior. FB20212935 FB19451832 FB19450508 FB19450162 FB19449747 Our company owns the USB vendor IDs X and Y . We've been granted a USB transport entitlement for both of those IDs. The crux of the problem is that I want to build a driver for USB vendor ID Y. Xcode's well-hidden auto-generated provisioning profile for my driver contains com.apple.developer.driverkit.transport.usb: { idVendor = X; } which is obviously not what I want. Xcode fails to provision the target. But I have another, much older project with an auto-generated provisioning profile containing com.apple.developer.driverkit.transport.usb: { idVendor = X; }, { idVendor = Y; } I can build a driver for idVendor Y without problems in this project. But that doesn't help me with my new project. What can I do to fix this? Do I need to request our entitlements again? I fear if I do so, something will get lost in the process. Is there a way to inspect what we have already been granted? - I can't see a "managed entitlements" section on the account portal. I can go through the motions of making a new App ID, then I can see that some Capability Request have been "Assigned", but I don't see what their values are. A second question I have is about the userclient-access entitlement. Are these tied to the bundle ID of the app which claims the access? In other words, if I have two drivers com.mycompany.app1.driver1 com.mycompany.app2.driver2 and I would like to have com.mycompany.app1 communicate with com.mycompany.app1.driver1, I would ask for the com.apple.developer.driverkit.userclient-access capability for com.mycompany.app1.driver1. But must I request that access for each specific app bundle ID that will talk to that driver, or once the entitlement is granted, can I use com.apple.developer.driverkit.userclient-access = { com.mycompany.app1.driver1 } in any of my apps?

As per : TN3120: Expected use cases for Network Extension packet tunnel providers | Apple Developer Documentation It is clear that Packets that are read from NEPacketTunnelFlow are meant to be sent over a tunnel connection to a remote server for injection into a remote network. They are not meant to be dropped or re-injected back into the system. In my usecase: NEPacketTunnelProvider is separate process. which reads the packet using packetFlow.readPacketObjects Send it over to other process i.e privileged helper(Non-bundle/command line tool/non sandboxed) via UDS IPC. Helpers send to to remote tunnel and return back the packet to NEPacketTunnelFlow via same IPC. NEPacketTunnelProvider uses packetFlow.writePacketObjects to inject packets. Things works fine. We don't distribute it via Appstore. We are now attempting to implement a on device bypass mechanism from helper tool side. Could you please suggest if there is any approach I could try, even if it involves proceeding at my own risk?

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) We are using JAMF MDM profile for installing our transparent proxy in customer environment. We are using VPN payload(https://developer.apple.com/documentation/devicemanagement/vpn) for this network system extension. This payload does not have any field for order. As per https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy-data.dictionary documentation there is another payload for TransparentProxy and we could create a Transparent Proxy profile using iMazingProfile Editor. Noticed that, if we add the Order attribute to the VPN/TransparentProxy payload, while installing the extension, the save to preferences fails with "Error in saving TP configuration in updateOnDemandRule permission denied" error. Can we use this Order field to ordering the installed Transparent Proxy extension in a machine? Customer devices will likely have other Transparent Proxy network extensions as well. We want to allow the Customer to control the order in which each Transparent Proxy network extension receives the network traffic. How can we set the order of the Transparent proxy extension that can be deployed using MDM profile with VPN/TransparentProxy payload? Attached the TransparentProxy payload profile for the reference. DGWebProxy_TransparentProxy_iMazing

Hey, We also opened a feedback assistant request, and also opened a ticket with Apple Developer Technical Support a while ago that notice the unmount problem also but it was before we pin point the problem to the Network Extension. After a further investigation, we've found out that the root cause of this problem is cause by having a network filter from the NetworkExtension provider on (Specifically we have tested with the NEFilterDataProvider) while having a Xsan volume. The NEFilterDataProvider causing problems for the Xsan, and is stalling the shutdown until we get a panic from watchdog timeout, and only then the mac is fully shutdown. The problem from what we investigated and also talked with you, is that the Xsan process can't unmount the volume and stuck. We have also noticed that if we install a network extension and allow the popup of the network filters, i.e enabled the NEFilterDataProvider the computer is stuck, and the finder is in a non responsive state until a reboot (Also probably due to the fact the Xsan is now in a problematic state). This tests was done on latest versions of MacOs 13 & 14. We have taken a sysdiagnose from the computer while we have tested. Do you familiar with the problem (We got no answer on the feedback assistant)? Thank you, Idan

Hi All, I am currently working on a Network Extension App for MacOS using 3 types of extensions provided by Apple's Network Extension Framework. Content Filter, App Proxy (Want to get/capture/log all HTTP/HTTPS traffic), DNS Proxy (Want to get/capture/log all DNS records). Later parse into human readable format. Is my selection of network extension types correct for the intended logs I need? I am able to run with one extension: Main App(Xcode Target1) <-> Content Filter Extension. Here there is a singleton class IPCConnection between App(ViewController.swift) which is working fine with NEMachServiceName from Info.plist of ContentFilter Extension(Xcode Target2) However, when I add an App Proxy extension as a new Xcode Target3, I think the App and extension's communication getting messed up and App not getting started/Crashing. Here, In the same Main App, I am adding new separate IPCConnection for this extension. Here is the project organization/folder structure. MyNetworkExtension ├──MyNetworkExtension(Xcode Target1) │ ├── AppDelegate.swift │ ├── Assets.xcassets │ ├── Info.plist │ ├── MyNetworkExtension.entitlement │ | ── Main │ |-----ViewController.swift │ └── Base.lproj │ └── Main.storyboard ├── ContentFilterExtension(Xcode Target2) │ ├── ContentFilterExtension.entitlement │ │ ├── FilterDataProvider.swift │ │ ├── Info.plist │ │ ├── IPCConnection.swift │ │ └── main.swift ├── AppProxyProviderExtension(Xcode Target3) │ ├── AppProxyProviderExtension.entitlement │ │ ├── AppProxyIPCConnection.swift │ │ ├── AppProxyProvider.swift │ │ ├── Info.plist │ │ └── main.swift └── Frameworks ├── libbsm.tbd └── NetworkExtension.framework Is my Approach for creating a single Network Extension App with Multiple extensions correct or is there any better approach of project organization that will make future modifications/working easier and makes the maintenance better? I want to keep the logic for each extension separate while having the same, single Main App that manages everything(installing, activating, managing identifiers, extensions, etc). What's the best approach to establish a Communication from MainApp to each extension separately, without affecting one another? Is it good idea to establish 3 separate IPC Connections(each is a singleton class) for each extension? Are there any suggestions you can provide that relates to my use case of capturing all the network traffic logs(including HTTP/HTTPS, DNS Records, etc), especially on App to Extension Communication, where my app unable to keep multiple IPC Connections and maintain them separately? I've been working on it for a while, and still unable to make the Network Extension App work with multiple extensions(each as a new Xcode target). Main App with single extension is working fine, but if I add new extension, App getting crashed. I suspect it's due to XPC/IPC connection things! I really appreciate any support on this either directly or by any suggestions/resources that will help me get better understand and make some progress. Please reach out if in case any clarifications or specific information that's needed to better understand my questions. Thank you very much

NEAppProxyUDPFlow contains below property: open var localEndpoint: NWEndpoint? { get } Why is localEndpoint not available for NEAppProxyTCPFlow? Is there a way to determine the source port of a flow of type NEAppProxyTCPFlow within the following method of NETransparentProxyProvider? override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool {

Hello Apple Developer Community, We are developing a full-tunnel VPN app for macOS that utilizes a packet tunnel network system extension (via NEPacketTunnelProvider). We're committed to using a system extension for this purpose, as it aligns with our requirements for system-wide tunneling. The app is sandboxed and intended for distribution on the Mac App Store. Here's the workflow: The app (running in user context) downloads a VPN profile from our server. It generates private keys, appends them to the profile, and attempts to save this enhanced profile securely in the keychain. The packet tunnel system extension (running in root context) needs to access this profile, including the private keys, to establish the VPN connection. We've encountered challenges in securely sharing this data across the user-root boundary due to sandbox restrictions and keychain access limitations. Here's what we've tried so far, along with the issues: Writing from the App to the System Keychain: Attempted to store the profile in the system keychain for root access. This fails because the sandboxed app lacks permissions to write to the system keychain. (We're avoiding non-sandboxed approaches for App Store compliance.) Extension Reading Directly from the User Login Keychain: Tried having the extension access the user's login keychain by its path. We manually added the network extension (located in /Library/SystemExtensions//bundle.systemextension) to the keychain item's Access Control List (ACL) via Keychain Access.app for testing. This results in "item not found" errors, likely due to the root context not seamlessly accessing user-keychain items without additional setup. Using Persistent References in NETunnelProviderProtocol: The app stores the profile in the user keychain and saves a persistent reference (as Data) in the NETunnelProviderProtocol's identityReference or similar fields. The extension then attempts to retrieve the item using this reference. We manually added the network extension (located in /Library/SystemExtensions//bundle.systemextension) to the keychain item's Access Control List (ACL) via Keychain Access.app for testing. However, this leads to error -25308 (errSecInteractionNotAllowed) when the extension tries to access it, possibly because of the root-user context mismatch or interaction requirements. Programmatically Adding the Extension to the ACL: Explored using SecAccess and SecACL APIs to add the extension as a trusted application. This requires SecTrustedApplicationCreateFromPath to create a SecTrustedApplicationRef from the extension's path. Issue 1: The sandboxed app can't reliably obtain the installed extension's path (e.g., via scanning /Library/SystemExtensions or systemextensionsctl), as sandbox restrictions block access. Issue 2: SecTrustedApplicationCreateFromPath is deprecated since macOS 10.15, and we're hesitant to rely on it for future compatibility. We've reviewed documentation on keychain sharing, access groups (including com.apple.managed.vpn.shared, but we're not using managed profiles/MDM) as the profiles are download from a server, and alternatives like XPC for on-demand communication, but we're unsure if XPC is suitable for sensitive data like private keys during tunnel creation. And if this is recommended what is going to be the approach here. What is the recommended, modern approach for this scenario? Is there a non-deprecated way to handle ACLs or share persistent references across contexts? Should we pursue a special entitlement for a custom access group, or is there a better pattern using NetworkExtension APIs? Any insights, code snippets, or references to similar implementations would be greatly appreciated. We're targeting macOS 15+. Thanks in advance!

I haven’t come across any official documentation regarding the limit on the number of Network Extensions macOS can run. However, I did see some discussions suggesting that Apple might restrict this to 5 extensions in macOS Tahoe. Is there any official confirmation on this?

Apple is encouraging VPN apps on macOS to transition to Network Extension APIs, if they haven't done so yet, see: TN3165: Packet Filter is not API WWDC25: Filter and tunnel network traffic with NetworkExtension Using Network Extension is fine for VPN apps that are distributed via the Mac App Store. Users get one pop-up requesting permission to add VPN configurations and that's it. However, VPN apps that are distributed outside of the App Store (using Developer ID) cannot use Network Extension in the same way, such apps need to install a System Extension first (see TN3134: Network Extension provider deployment). Installing a System Extension is a very poor user experience. There is a pop-up informing about a system extension, which the user has to manually enable. The main button is "OK", which only dismisses the pop-up and in such case there is little chance that the user will be able to find the correct place to enable the extension. The other button in that pop-up navigates to the correct screen in System Settings, where the user has to enable a toggle. Then there is a password prompt. Then the user has to close the System Settings and return to the app. This whole dance is not necessary for VPN apps on the Mac App Store, because they work with "app extensions" rather than "system extensions". As a developer of a VPN app that is distributed outside of the App Store, my options are: Implement VPN functionality in an alternative way, without Network Extension. This is discouraged by Apple. Use a System Extension with Network Extension. This is going to discourage my users. I have submitted feedback to Apple: FB19631390. But I wonder, why did Apple create this difference in the first place? Is there a chance that they will either improve the System Extension installation process or even allow "app extensions" outside of the Mac App Store?

Starting on macOS Sequoia, flows originated in Firefox have an empty sourceAppAuditToken. Other apps contain a valid token. Background: in order to fetch process info for a certain NEFilterFlow, my content filter extension uses sourceAppAuditToken, audit_token_to_pid() and proc_* (as recommended in #126820). When that fails, we use SecCodeCopyGuestWithAttributes, recommended in some other thread as a better alternative. Both approaches break when the sourceAppAuditToken is empty since they need the pid. Debugging: My logging shows audit token is empty for Firefox Typical logs from com.apple.networkextension also indicate it fails to fetch the same info I'm looking for: com.apple.networkextension debug 11:22:07.024588-0300 Fetching appInfo from cache for pid: 948 uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 bundle id: (null) com.apple.networkextension debug 11:22:07.024657-0300 Calling delegate lookup handler with pid: 948, uuid: 5C40B765-C6C9-3641-A822-2BC44D264361, bundleID: (null) com.apple.networkextension debug 11:22:07.025856-0300 Could not look up appInfo for pid: 948 bundle id: (null) uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 com.apple.networkextension error 11:22:07.025897-0300 Could not find app info, return the original flow without filling in app info Handling new flow: identifier = D89B5B5D-793C-4940-D992-4E90F2AD1900 procPID = 953 eprocPID = 948 direction = outbound inBytes = 0 outBytes = 0 signature = {length = 32, bytes = 0x4afeafde b484aa0c c5cb8698 0567343d ... 7cdee33e 135666dd } socketID = 19adf2904e92d9 localEndpoint = 0.0.0.0:0 remoteEndpoint = 17.33.202.170:443 protocol = 6 family = 2 type = 1 procUUID = 0C68E603-967E-3643-B225-378BD2A655F7 eprocUUID = 5C40B765-C6C9-3641-A822-2BC44D264361 Perhaps there's a bug when generating the audit token or could it be something with the Firefox signature? I double-checked Firefox and it seems fine: $ codesign --verify --verbose /Applications/Firefox.app /Applications/Firefox.app: valid on disk /Applications/Firefox.app: satisfies its Designated Requirement Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome: codesign -dv /Applications/Firefox.app ... CodeDirectory v=20500 size=863 flags=0x10000(runtime) hashes=18+5 ... Versus chrome CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded

Hi everyone, I’m currently developing a macOS app that is distributed via a DMG file on our website. The app includes an App Extension (appex) for Network Extension functionality. I’m wondering if distributing via DMG on the web requires the app extension to be implemented as a System Extension instead of an App Extension. Is it necessary to migrate to System Extension for web-based DMG distribution, or can I continue using App Extension as is? Any insights or recommendations would be greatly appreciated. Thank you!

I'm trying to distribute a sandboxed macOS app with a PacketTunnelProvider (system extension) via direct distribution (outside of AppStore). The app and the extension both use the same app group, using the new group.com.XXXX.YYYY format detailed here for 10.15+ https://developer.apple.com/forums/thread/721701 I've also followed the instructions below to get around the quirk of not being able to directly process it via XCode: https://developer.apple.com/forums/thread/737894 I've re-signed with Developer ID certificate, all that is smooth and successfully notarized. However upon running the app I get: "My.app" would like to access data from other apps. Checking ~/Library/Containers ~/Library/Group Containers I see the correct files folders have been created before I select Don't Allow and Allow. My app does not access any files or folders outside of the sandboxed directories. How can I prevent this from happening? In order to diagnose further, how to diagnose exactly which files/folder the app is trying to access that is causing this problem?

Hello everyone, I'm developing a macOS application with an integrated Content Filter System Extension. Both the main app and the extension are signed with a Developer ID Application provisioning profile. When building in Xcode, I'm encountering an entitlement mismatch error. I've inspected the provisioning profile using the command: security cms -D -i FilterContentExtension-prod-profile.provisionprofile | grep -A 10 com.apple.developer.networking.networkextension And found that the com.apple.developer.networking.networkextension section only contains values with the -systemextension suffix, for example: content-filter-provider-systemextension. However, when I enable Network Extension → Content Filter in Xcode, the .entitlements file is generated with: content-filter-provider. This leads to the error: "Provisioning profile 'FilterContentExtension-prod-profile' doesn't match the entitlements file’s value for the com.apple.developer.networking.networkextension entitlement." My specific questions are: Why does this error occur? How can I use the content-filter-provider entitlement? If I want to use the content-filter-provider entitlement inside com.apple.developer.networking.networkextension for my Content Filter System Extension, what should I do?

Hello everyone, I'm developing a macOS application with an integrated Content Filter System Extension. Both the main app and the extension are signed with a Developer ID Application provisioning profile. When building in Xcode, I'm encountering an entitlement mismatch error. I've inspected the provisioning profile using the command: security cms -D -i FilterContentExtension-prod-profile.provisionprofile | grep -A 10 com.apple.developer.networking.networkextension And found that the com.apple.developer.networking.networkextension section only contains values with the -systemextension suffix, for example: content-filter-provider-systemextension. However, when I enable Network Extension → Content Filter in Xcode, the .entitlements file is generated with: content-filter-provider. This leads to the error: "Provisioning profile 'FilterContentExtension-prod-profile' doesn't match the entitlements file’s value for the com.apple.developer.networking.networkextension entitlement." My specific questions are: Why does this error occur? How can I use the content-filter-provider entitlement? If I want to use the content-filter-provider entitlement inside com.apple.developer.networking.networkextension for my Content Filter System Extension, what should I do?

We have an application which is written in Swift, which activates Transparent Proxy network extension. We want to use MDM deployment for this network system extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) We don’t have any remote server setup to forward the traffic, instead we open a connection with a certain localhost:port (127.0.0.1:3128) to redirect the traffic which is received in our transparent proxy. We have another module that listens to the particular localhost:port to process the traffic further. As per https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy documentation, we noticed that we can use the VPN payload with app-proxy as Provider Type for Transparent Proxy. By referring this document, we created the profile. If we provide "127.0.0.1" as RemoteAddress field, we were able to install the profile and also while installing our product, the Transparent Proxy gets mapped with the one which is installed via profile. However after that the network is broken and hence unable to browse anything. We are suspecting the remote server(RemoteAddress) filed is causing this. What value should be provided in the RemoteAddress field?

I am trying to intercept localhost connections within NETransparentProxyProvider system extension. As per NENetworkRule documentation If the address is a wildcard address (0.0.0.0 or ::) then the rule will match all destinations except for loopback (127.0.0.1 or ::1). To match loopback traffic set the address to the loopback address. I tried to add NWHostEndpoint *localhostv4 = [NWHostEndpoint endpointWithHostname:@"127.0.0.1" port:@""]; NENetworkRule *localhostv4Rule = [[NENetworkRule alloc] initWithDestinationNetwork:localhostv4 prefix:32 protocol:NENetworkRuleProtocolAny]; in the include network rules. I tried several variations of this rule like port 0, prefix 0 and some others. But the provider disregards the rule and the never receives any traffic going to localhost on any port. Is there any other configuration required to receive localhost traffic in NETransparentProxyProvider?

I've discovered that a system network extension can communicate with a LaunchDaemon (loaded using SMAppService) over XPC, provided that the XPC service name begins with the team ID. If I move the launchd daemon plist to Contents/Library/LaunchAgents and swap the SMAppService.daemon calls to SMAppService.agent calls, and remove the .privileged option to NSXPCConnection, the system extension receives "Couldn't communicate with a helper application" as an error when trying to reach the LaunchAgent advertised service. Is this limitation by design? I imagine it is, but wanted to check before I spent any more time on it.