macOS allows you to independently distribute a Network Extension using Developer ID signing, but with an important wrinkle. This post explains that wrinkle, its affect on Xcode, and how you get around it. If you have questions or comments, put them in a new thread here on DevForums. Tag it with Network Extension so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Exporting a Developer ID Network Extension macOS supports a variety of Network Extension (NE) provider types. Starting with macOS 10.15, it’s possible to distribute an app containing NE providers independently, using Developer ID signing. See TN3134 Network Extension provider deployment for the full list of supported provider types. For your NE provider to work when distributed independently, it must: Be packaged as a system extension. Use Developer ID specific entitlements This post is focused on that second point, because it’s common source of confusion. This post assumes that you’re building your app with Xcode; if you’re building your app outside of Xcode, you’ll have to adapt these steps to your build system. Entitlement Matters A Network Extension system extension and its container app must be signed with the Network Extension entitlement (com.apple.developer.networking.networkextension). That entitlement is an array, with a variety of different element values based on the provider type. For example, a standard NE content filter provider must include the content-filter-provider value. There are two groups of these values: the standard ones and the ones with the -systemextension suffix. During development and for App Store distribution, use the appropriate standard value. For independent distribution using Developer ID, use the corresponding value with the -systemextension suffix. For example, a Developer ID signed NE content filter must use content-filter-provider-systemextension instead of content-filter-provider. Xcode Issues Xcode is currently not aware of this requirement. If you build your NE provider container app using Xcode, you might expect to export it for independent distribution using the Direct Distribution workflow in the Xcode organiser. This does not work (r. 108838909). To get around this, manually export your app from your Xcode archive. Before attempting that, there’s a few things to confirm: By default Xcode’s Signing & Capabilities editor uses the standard values for the NE entitlement. Leave them that way. During day-to-day development it’s best to use an Apple Development signing identity [1], and the standard values work with that. Continue to use Build > Archive [2] to create an Xcode archive for your product. The steps below replace the Direct Distribution workflow, and they assume you’re starting with an Xcode archive. [1] Don’t use Developer ID for day-to-day development; see The Care and Feeding of Developer ID for more on that topic. [2] Or, if you’re automating this, the archive action in xcodebuild. Assemble Your Assets Imagine you’re working on a content filter for the Mac called WaffleFilter. You’ve used Xcode to build the app into an Xcode archive: % ls "WaffleFilter.xcarchive／Products／Applications" WaffleFilter.app That app is development signed: % codesign -d -vvv "WaffleFilter.xcarchive／Products／Applications／WaffleFilter.app" … Authority=Apple Development: … … IMPORTANT The steps in this section are based on the much more comprehensive instructions in Creating Distribution-Signed Code for Mac. If anything is unclear, read that post for clarification. To re-sign this app for independent distribution you’ll need three things: A Developer ID application signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. A Developer ID provisioning profile for the app. In this example I’ve called this WaffleFilter_Dev_ID.provisionprofile. A Developer ID provisioning profile for the system extension. In this example I’ve named this WaffleFilter_WFProvider_DevID.provisionprofile. If you’re not sure how to create these things, see Developer Account Help. Re-sign the App To start, make a copy of the app: % ditto "WaffleFilter.xcarchive／Products／Applications／WaffleFilter.app" "WaffleFilter.app" Dump the entitlements of the app and its embedded system extension: % codesign -d --entitlements "WaffleFilter.entitlements" --xml "WaffleFilter.app" % codesign -d --entitlements "WaffleFilter_WFProvider.entitlements" --xml "WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" And reformat them to make them more readable: % plutil -convert xml1 "WaffleFilter.entitlements" % plutil -convert xml1 "WaffleFilter_WFProvider.entitlements" Now edit these files to add the -systemextension suffix. The result will look something like this: % cat "WaffleFilter.entitlements" … ＜dict＞ … ＜key＞com.apple.developer.networking.networkextension＜／key＞ ＜array＞ ＜string＞content-filter-provider-systemextension＜／string＞ ＜／array＞ … ＜／dict＞ ＜／plist＞ % cat "WaffleFilter_WFProvider.entitlements" … ＜dict＞ … ＜key＞com.apple.developer.networking.networkextension＜／key＞ ＜array＞ ＜string＞content-filter-provider-systemextension＜／string＞ ＜／array＞ … ＜／dict＞ ＜／plist＞ Before you re-sign with these entitlements, replace the embedded provisioning profiles with their Developer ID profiles variants: % cp "WaffleFilter_Dev_ID.provisionprofile" "WaffleFilter.app／Contents／embedded.provisionprofile" % cp "WaffleFilter_WFProvider_DevID.provisionprofile" "WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension／Contents／embedded.provisionprofile" Now re-sign the app and the system extension with their new entitlements, from the inside out: % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter_WFProvider.entitlements" --timestamp -o runtime "WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension: replacing existing signature % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter.entitlements" --timestamp -o runtime "WaffleFilter.app" WaffleFilter.app: replacing existing signature If you have multiple Developer ID Application signing identities, you’ll need to replace Developer ID Application with the name of the specific identity you want to use. IMPORTANT If your app contains other code items, like frameworks or an app extension, re-sign those as well. For advice on how to manually re-sign a more complex app, see Creating Distribution-Signed Code for Mac. And you’re done! Manually Notarise Xcode’s Direct Distribution workflow also deals with notarisation. As you’re not using that workflow, manually notarise your app. For advice on how to do that, see Customizing the notarization workflow. You should also look at Packaging Mac Software for Distribution, which has a bunch of general info about packaging Mac apps.

I have an app which hosts network extensions(Packet Tunnel, Filter). I am facing uninstallation issue in scenario 2. Uninstall API: OSSystemExtensionRequest.deactivationRequest Scenarion 1: app version 1.0.0.1, extension inside app bundle version 1.0.0.1 Installed extension -> version 1.0.0.1 Uninstallation works fine. Scenarion 2: app version 1.0.0.2, extension inside app bundle version 1.0.0.2 Installed extension -> version 1.0.0.1 Uninstallation fails with below error: deactivation failed for client: /Applications/Remo Security Endpoint Client/ep-client.app/Contents/MacOS/ep-client, error: Error Domain=OSSystemExtensionErrorDomain Code=4 "(null)" Question 1: is this by design or we can do something to make uninstall works in case application upgraded and tries to uninstall previous extension version. Snippet from Apple Doc for API: OSSystemExtensionRequest.deactivationRequest A deactivation request may require a restart before deactivating the extension. If the request succeeds but requires a restart to complete, the extension may still appear operational until the next restart. Question 2: How do we know if restart needed or not?

Hi everybody, I have some questions regarding daemons and system network extensions. I’ve read here (https://developer.apple.com/forums/thread/721674): “System extensions are effectively launchd daemons”. So I have a question, can we launch system extension somehow directly via providing com.example.plist file into Library/LaunchDaemons and loading it? Or, for example, by loading it via SMAppService.daemon(). We need our network extension to run before user session. If above is not possible, and we’ll have a separate daemon, which only purpose is to start network extension, how can we listen to the lifecycle of the network extension? For example (I’ve already made some experiments): we start daemon, it starts NE, we unregister daemon (via SMAppService), but NE still lives. Is it possible to get callback/signal in the daemon, that it was unregistered and shutdown gracefully?

Hi everybody, what is recommended way to share settings (user defaults or any other way of storing preferences) between different processes with different ownership? For example we have a UI app, which runs from user, daemon and system extension which both run from root. How can we do some configuration on user level and read it in daemon/system extension safely, without providing some exploits. Bonus: how to observe changes in this scenario?

We have a Developer Id signed VPN application using both NEPacketTunnelProvider and NEAppProxyProvider packaged as a single system extension. The requirement is for the application to implement a full tunnel VPN (has default route 0.0.0.0 on the utun interface) with the exception of another specific Developer Id signed application which needs its connections to bypass the tunnel. Originally, we attempted to use NETransparentProxyProvider to bypass the tunnel (for the single application) with the idea being to intercept the flows for the desired application in the transparent proxy and proxy these flows via a new NWConnection forced via the direct interface to bypass the tunnel. The problem we ran into was that the NEPacketTunnelProvider always get the packets before the NETranparentProxyProvider even though the proxy is started before the packet tunnel. So next attempt was to use NEAppProxyProvider with an NEAppRule set to capture flows for the specific application of interest. The good news is we get the application flows prior to the packet tunnel but the problem is the NEAppRule only seems to work for App Store signed applications, for example Safari. For Developer Id signed applications (for example Chrome) flows are actually blocked when an NEAppRule is added to the proxy configuration. This seems like a bug to me. The system log will show some messages about the http flow being blocked by policy. For the Safari case, when the NEAppRule is added we can see socket redirect policies added (system log). In the Developer Id signed apps there appears to be an error when OS is checking the apps certificate. What is the recommended way to implement our apps requirement? We have a full packet tunnel with the exception of a single, Developer Id signed, application.

I am playing around with Endpoint Security using demo code. I tried to handle AUTH open event on specific folder in my Desktop,set to deny all, but whenever I set this extension, I successfully get deny all on the folder as well as all other files and documents in the Users space. static void handle_open_worker(es_client_t *client, const es_message_t *msg) { static const char *test_nnn = "/Users/myname/Desktop/endpoint_test/block_this_folder/"; static const size_t nnn_length = sizeof(test_nnn) - 1; if (strncmp(msg->event.open.file->path.data, test_nnn, nnn_length) == 0) { es_respond_flags_result(client, msg, 0, true); } else { // Allow everything else... es_respond_flags_result(client, msg, 0xffffffff, true); } } why the code applies to all other files rather than only deny open on /Users/myname/Desktop/endpoint_test/block_this_folder/

I'm testing my NEFilterDataProvider system extension by building it in Xcode and then copying the built app into the Applications folder. When I do changes to the extension's code, obviously the system extension process currently running needs to be shut down or restarted when I launch the new app version. Increasing the app version and build numbers each time always seem to trigger the system extension update in macOS, but that's not so convenient and at the latest when publishing the update those numbers cannot just make arbitrary jumps. I've read that moving an app to the trash should uninstall any attached system extensions, and this seems to be confirmed by the alert that macOS shows when doing so, but even after clicking Continue and authenticating with Touch ID to confirm the uninstall and emptying the trash, it sometimes happens that when launching the next version of my app from the Applications folder the old system extension is still running, which I notice e.g. because the app crashes since it's using different IPC method signatures than the system extension. When checking in Activity Monitor the system extension is also still listed. Even restarting the Mac doesn't always solve the issue, so when this happens my only solution is to increase the build and version numbers to make it work, and then reset them later when moving the app to the trash correctly uninstalls the system extension again. Is this a bug or am I missing something? Or is there a workaround that doesn't involve booting into safe mode and manually uninstalling the system extension? P.S.: I just tried booting into safe mode and moving the files from /Library/SystemExtensions to the trash as suggested on discussions.apple.com, but I got an alert saying that I didn't have the privileges to do so.

On Ventura - We have a network extension(Transparent Proxy) which blocks IPv6 traffic as below. override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { //Ipv6 gets blocks by below code let error = NSError(domain: "", code: 0, userInfo: [NSLocalizedDescriptionKey : "Connection Refused"]) flow.closeReadWithError(error) flow.closeWriteWithError(error) On IPv6 enabled client machine, when a client application(Browser, curl, Teams etc), try to send HTTP/s requests, first they try to send the request over IPv6 and if it fails, they try with IPv4 (Happy eyeballs Algorithm) In our case, as network extension blocks IPv6 traffic, client applications will fail to establish connection over IPv6 and fallback to IPv4 as per Happy eyeballs Algorithm The above scenario works fine till MacOS Ventura. For Sonoma, this behaviour seems to have changed When our network extension blocks IPv6 traffic, client applications do not fallback to IPv4. They simply fail without trying IPv4. We tested with curl, Google chrome browser, Microsoft Teams. All these fail to load pages on Sonoma and they work fine on Ventura. Note : No change in our network extension code, curl and browser versions. Only change is MacOS version Please find attached screenshots with Ventura and with Sonoma, running curl One other difference seen here is the error code received by client applications with Ventura and Sonoma. On Ventura, when IPv6 is blocked, error is Network is down and client application establishes connection with IPv4. On Sonoma, error code is 22 : Invalid arguments and client application does not retry with IPv4. Curl_Ventura.jpg Curl_Sonoma.png

Hello , We've developed a MacOS app with a system extension that includes a content filter using socket and packet providers. To enable the extension, we applied the following payload : - <dict> <key>PayloadContent</key> <array> <dict> <key>PayloadIdentifier</key> <string>com.companyname.webcontentfilter</string> <key>PayloadType</key> <string>com.apple.webcontent-filter</string> <key>PayloadUUID</key> <string>5e8794fb-8820-43cd-9d18-d171539f755a</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadScope</key> <string>System</string> <key>AutoFilterEnabled</key> <false /> <key>FilterBrowsers</key> <true/> <key>FilterSockets</key> <true/> <key>FilterType</key> <string>Plugin</string> <key>FilterPackets</key> <true/> <key>FilterPacketProviderBundleIdentifier</key> <string>com.companyname.dlp.test1.ne.Extension</string> </dict> </array> <key>PayloadDescription</key> <string>Description</string> <key>PayloadDisplayName</key> <string>Restriction Profile</string> <key>PayloadIdentifier</key> <string>com.test.restriction</string> <key>PayloadOrganization</key> <string>COMPANY NAME Pvt. Ltd.</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>f5f02ca0-0bed-4844-ba53-ea1e0dd6f61e</string> <key>PayloadVersion</key> <integer>1</integer> </dict> However, it failed to deploy on the device with the reason being: "The ‘VPN Service’ payload could not be installed. The VPN service could not be created." We've followed the guidelines from available resources, but it's not working as expected. Additionally, we're primarily testing on Ventura (M1) and Monterey (Intel). Any insights or advice from your side would be greatly appreciated. Thank you.

I have an app that installs an endpoint system extension, and I have the app notarized. I can install the endpoint system extension and enable Full Disk Access fine on Ventura, Apple Silicon Sonoma, Apple Silicon But I cannot enable Full Disk Access on Ventura, Intel In System Settings, when I try to slide toggle switch on to enable full disk access, the toggle slides right back to off. In previous development versions, I could enable Full Disk Access on the Intel machine. Any idea why I cannot enable Full Disk Access on Ventura/Intel for my endpoint system extension in my notarized app? One additional observation, the name displayed in the Full Disk Access section is different between the Apple Silicon and Intel Macs. On Apple Silicon, only the final part of the Bundle ID is shown in Full Disk Access: endpointagent On Intel, the full Bundle ID is shown: com.MyCompany.MyApp.endpointagent Don't know if it matters, but I thought I'd point that out.

I am currently writing an agent for endpoint security. I cannot connect the application and the xpc service. I start the plist with launchctl and then open the application, but it does not connect and the application runs dysfunctionally. I leave the code of the ViewController in the application and the XPCConnection in the xpc service below. Note: I create the XPC service in Xcode like a normal application and write it as a service application with "Application is background only" ViewController.swift func establishConnection() { XPCConnection.shared.connectToDaemon(bundle: Bundle.main, delegate: self) { success in DispatchQueue.main.async { [self] in if !success { controlButton.isEnabled = false configMenuStatus(start: false, stop: false) alertWithError(error: "Unable to start monitoring for broken connection with daemon.") } else { Logger(.Info, "Connect to daemon successfully.") } } } } XPCConnection.swift func connectToDaemon(bundle: Bundle, delegate: ClientXPCProtocol, handler: @escaping (Bool) -> Void) { guard connection == nil else { Logger(.Info, "Client already connected.") handler(true) return } guard getMachServiceName(from: bundle) == ClientBundle else { handler(false) return } let newConnection = NSXPCConnection(machServiceName: DaemonBundle) newConnection.exportedObject = delegate newConnection.exportedInterface = NSXPCInterface(with: ClientXPCProtocol.self) newConnection.remoteObjectInterface = NSXPCInterface(with: DaemonXPCProtocol.self) newConnection.invalidationHandler = { self.connection = nil Logger(.Info, "Daemon disconnected.") handler(false) } newConnection.interruptionHandler = { self.connection = nil Logger(.Error, "Daemon interrupted.") handler(false) } connection = newConnection newConnection.resume() let proxy = newConnection.remoteObjectProxyWithErrorHandler { error in Logger(.Error, "Failed to connect with error [\(error)]") self.connection?.invalidate() self.connection = nil handler(false) } as? DaemonXPCProtocol proxy!.connectResponse(handler) handler(true) } This is the error photo, the application continues to work First, I checked to see if I had made a mistake in the bundle identifier, but I could not find an error, and then I realized that I had not run the launchd service. Then I ran it, but it did not make any sense. What I am trying to do is to connect and run the network extension and endpoint security with this service, but the xpc service does not connect to each other.

I have two System extensions in my application. App proxy provider ( app-proxy-provider-systemextension) Endpoint Security (com.apple.developer.endpoint-security.client) But now, on one of my customer's computer, when it launched app proxy provider, the sysextd process said that /Applications/XXXXXX.app/Contents/Library/SystemExtensions/com.***.AppProxy.systemextension: entitlement com.apple.developer.endpoint-security.client not present or not true. As a network system extension, my app proxy provider was asking for an Endpoint Security entitlement, that is a very strange. I don't know how to debug it. Any ideas and help?

Hi, I have installed content filter network extension which is almost same as https://developer.apple.com/documentation/networkextension/filtering_network_traffic. I have another app. As part of this app, I am sending messages from server process to client process by using unix domain sockets which is almost same as https://github.com/devlights/go-unix-domain-socket-example. If network traffic is little bit more then my client is failing to send messages with write: no buffer space available error. If I stop content filter network extension then there is no issue. How can I handle this type of error with network extension? Note: This is happening on both monterey and ventura mac os (both intel and m1).

Apple M2 Pro MacOs: 13.6 (22G120) In my system extension installer's postInstall script I have launch agent configured for the app as below: launchctl enable gui/$user_uid/com.mycompany.client.myproduct launchctl bootstrap gui/501 /Library/LaunchAgents/com.mycompany.myproduct.plist When I install the software using a local user, the service works fine without any issue and the service is shown listed in 'launchctl list' command: % launchctl list | grep -i mycompany 84714 0 com.mycompany.client.myproduct But when I login using on the same machine using a AD (Active Directory) user, the service/agent doesnt start and I don't see any entry service listed in 'launchctl list'. This is how my plist file looks like: % defaults read /Library/LaunchAgents/com.mycompany.myproduct.plist { CFBundleVersion = "200.200.200.200"; KeepAlive = 1; Label = "com.mycompany.client.myproduct"; LimitLoadToSessionType = ( Aqua ); ProgramArguments = ( "/Applications/mycompany.app/Contents/MacOS/Mycompany Module" ); RunAtLoad = 1; Version = "200.200.200.200"; } What am I missing here?

I want to understand in which API triggers this below popup. 1. This below code always trigger popup after fresh install which make sense: `//manager NETunnelProviderManager manager.connection.startVPNTunnel(options: [:])` 2. This below code sometime triggers popup intermittently. Ideally this shouldn't trigger or always trigger. I tried running this code in loop to check this behaviour, some time around 50th or sometime around 88th execution observed this popup. config.providerBundleIdentifier =“bundleId” config.serverAddress = "Connection managed by app”Name// let manager = NETunnelProviderManager() manager.protocolConfiguration = config manager.localizedDescription = “xyz” manager.saveToPreferences(completionHandler: { (saveError) -> Void in }``` no where startVPNTunnel called in 2nd code sample.