Thanks. So rules are more performant than custom filtering code and have no other practical advantage. Since I want to display all flows to the user of the app anyway, then there's no reason for me to use rules at all and simply get all the traffic.

Thanks again. You may find that this is a lot of networking flows that the user ends up having to acknowledge when the filter is first turned on. Do you mean that enabling the filter generates a lot of network flows? In any case, I would like to give the user the chance to inspect all flows, but they are initially all allowed by default, without need of user interaction.

Thanks, I will consider asking the user to contact me when the crash happens. I only have the crash reports from Xcode. Since the whole app extension depends on the existence of that directory, it doesn’t really make sense for me to prevent the crash.

In my case I had a whitespace in the Network Extension's product name in the build settings. Removing it solved the issue.

This sounds like a severe impediment. Is there still no official response from Apple?

I install it through a container app which shows the "System Extension Blocked" alert.

In this case it seems to always be UDP. Is this different from protocol to protocol?

Filter data providers only see TCP and UDP flows. Is this really the case? I also have a NEFilterDataProvider and until now I got ICMP (remote endpoint 192.168.1.1), ICMP6 (remote endpoint ff02::2), TCP and UDP flows.

I recently noticed that NEFilterFlow already seems to have a notion of the process that generated it. In handleNewFlow(_:), printing flow.description outputs something like this: identifier = 976999BB-C169-42BE-9CAF-41D22E332848 hostname = www.imdb.com sourceAppIdentifier = .com.apple.Safari sourceAppVersion = 17.0 sourceAppUniqueIdentifier = {length = 20, bytes = 0x94d650dbd26d77127b24d6c80c1faf8109368246} procPID = 744 eprocPID = 600 direction = outbound inBytes = 0 outBytes = 0 signature = {length = 32, bytes = 0x3f4e07a6 6077bb66 05cd661f 522a515e ... fa2751eb ac6bb41a } localEndpoint = 192.168.1.6:52304 remoteEndpoint = 18.165.186.203:443 remoteHostname = www.imdb.com protocol = 6 family = 2 type = 1 procUUID = F470D161-B607-3458-ADDE-F35CC5857E19 eprocUUID = A8B1FDA3-50E6-3A8A-AFCF-47D86E86B87F In particular, notice sourceAppIdentifier = .com.apple.Safari and procPID = 744. Is this information reliable? Why does it appear in the description but cannot be accessed via the API?

Different info is available on iOS. I've been running this code on macOS, never on iOS, so the app and pid information seems to also available on macOS. Or do you mean that the information that's printed in the description is not reliable on macOS?

I never removed the network configuration (I assume you mean in System Settings > Network). I just quit the container app and deleted it. When rebuilding it, moving it to /Applications and launching it again, sometimes I get the "System Extension Blocked" alert showing that the extension was deleted alongside the container app, but sometimes I don't.

In this case look at the local and remote ports, is everything the same here for the flows or are they different? If they are equal, would that mean that it's effectively the same flow? Why is then handleNewFlow(_:) called multiple times? Does this only happen when data starts moving on the flow? Not sure what you mean... it sounds like handleNewFlow(_:) can indeed be called multiple times. In case it was not clear, the same identifiers really appear multiple times when handling flows in handleNewFlow(_:) and not when handling reports in handle(_:). What I mean is that I didn't even check what happens in handle(_:).

Did you remove the container app using Finder? Yes.

The intended function to use when you specify the .cursorUpdate option on your tracking area is cursorUpdate(with:): Thanks, that really seems to solve the issue with the sample code I provided above. I guess updating the cursor once in cursorUpdate(with:) makes macOS aware that there is a custom cursor so it doesn't try to reset it continuously, as opposed to "force" setting it in mouseMoved(with:). The problem now is that I was really looking for a way to set a custom cursor whenever the mouse moves, because in my custom view there can be many hotspots that should change the mouse cursor, and I guess adding hundreds of tracking areas is not ideal... or is it? These hotspots also change very frequently. It seems like calculating and creating all individual tracking areas is very inefficient, as opposed to dynamically finding out what the cursor should be depending on the mouse cursor's position (particularly since in my case this can be done with some simple calculations).

Does this only happen when data starts moving on the flow? Isn't handleNewFlow(_:) called only when data starts moving? I couldn't find any mention of a different behaviour in the documentation.