So it turns out that the "issue" was in my code. The - resumeFlow:withVerdict: method was called from an instance of a subclass of NEFilterDataProvider that was not listed in the Info.plist file of the .systemextension bundle.

Just in case, the container app does not need to be at the first level of /Applications, it can be in a sub-folder.

The rules are written to disk, and the app sends a "hey, the rules were changed" XPC message to the extension when the user makes modifications. The extension also loads the rules when it starts up. This way, it should always be in sync. Why would the Network Extension have read access to the disk?

Well, it does not work on 10.15.6 here.

Just out of curiosity, has anyone been able to make the pause + resume workflow work?

For the record, this issue seems to be solved (or at least not to appear immediately) in macOS BS beta3.

FB8251066

I'm referring to the system dialog that pops up to ask the user to allow a Network Extension. Not a Network Extension trying to figure out which application "owns" a flow (which I would tend to do through the pid on macOS since most of the properties for the source app are not available on macOS, which is a pity but makes some sense).

@HarDToBelieve If you're using a Developer ID Application certificate, shouldn't there be a -systemextension suffix for the com.apple.developer.networking.networkextension values? i.e. app-proxy-provider-systemextension

FB8177506

FB8177476

This part looks OK. Other things to check, just in case: the Network Extension has the Network Extension permission. the Network Extension app ID starts with the app ID of the embedding application. the Team Prefix is the same for both app IDs. the profiles for the Network Extension and the Application uses the same Developer ID Application certificate. In the case the certificate used to create the profile is not the same instance that is selected in Xcode, Xcode will warn you in the project settings.

I encountered this issue but do not remember in which specific scenario. Reading my "don't" notes, this reminds me of this case: Avoid creating a macOS App Development provisioning profile: you probably will end up with a system extension that can not be loaded because the signature can not be verified (and the parent app will tell you everything is fine). Otherwise, you probably need to check that the entitlements are correctly set up as documented in this thread: https://developer.apple.com/forums/thread/125508

I mean the listen "event" that is provided by the .sf_listen callback in the struct sflt_filter KPI.

@Babse In my case, the XPC service is in a launchd daemon. To figure out how to make this work, I had the XPC service client code in both the Network Extension and in an app. Because the results of stopping and starting a Network Extension on Catalina are totally unreliable, having the same code in an app helped making sure that the XPC service was correctly started by launchd and that messaging through a proxy object worked. This proved to be useful to detect little mistakes such as not having the same mach service name in the launchd .plist file and the listener code. For the name of the service, I used the following pattern: TeamID.bundle_identifier_of_the_app_embedding_the_network_extension.some_service_name Currently, I have 3 XPC service names defined in the launchd .plist of a single daemon and all services are visible and usable from the Network Extension. I'm not sure whether the name of the launchd .plist file and the Label values matter but, just in case (because of the strange sandbox idea of relying on a group name), I used the same value for both of them with the following pattern: bundle_identifier_of_the_app_embedding_the_network_extension.something Because starting and stopping Network Extensions is unreliable, when something does not work, I usually restart the Mac, thus removing the Network Extension through the System Preferences > Network pref pane seem to also work in most cases. So far, I've probably restarted the Mac more than I did when developing the kernel extension flavor…