I'm seeing a similar problem to the one listed above: My Xcode entitlements file contains: <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider</string> <string>app-proxy-provider</string> <string>content-filter-provider</string> <string>dns-proxy</string> <string>dns-settings</string> </array> Whereas my Provisioning Profile shows these same attributes as: <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider-systemextension</string> <string>app-proxy-provider-systemextension</string> <string>content-filter-provider-systemextension</string> <string>dns-proxy-systemextension</string> <string>dns-settings</string> </array> Notice the appended "-systemextension" suffix. I've checked the PP options available in my portal and also tried changing the Xcode entitlements. So far I don't see a way to make these match from either side to the other. Am I missing something, or this a bug in Xcode versus PPs generated from the developer portal?

I believe I have found a small bug in the SimpleFirewall example which may effect others. If you have developer mode enabled on your system (systemextensionsctl developer on), the extension will be replaced each time it is activated (as if it were being updated). When the extension is replaced, the previous currentConnection (in IPCConnection.swift) will fail silently. Steps to reproduce: System Extension developer mode must be turned on. Launch SimpleFirewall app and press Start. Attempt to open a connection on the port being filtered. Observe you are prompted whether to allow the connection. Press Stop, wait a moment, and press Start again. Attempt to open a connection on the port being filtered. Observe you are no longer prompted, the call to promptUser from the extension fails silently. While this only effects developers, it was confusing why my variation of the extension didn't work. I was able to fix this issue by adding some code to reset the connection after the extension is replaced. I think there's another bug in the promptUser method in the ViewController. >>>> let window = view.window else { os_log("Got a promptUser call without valid flow info: %@", flowInfo) responseHandler(true) return } Calling into the UI from outside the main thread is unsafe. The last guard let condition needs to be moved into the async block below. Kind regards, - Peter Sichel