It looks like that the issue is not reproducible in the 15.6 RC.

It can be reproduced in macOS 26 beta 1 and beta 2.

Feedback ID: 18731867

I don't have logs, only a memgraph, so I can't say whether there were 2 starts logged. The 2 instances are referenced by a collection object (owned by a different class instance). The data filter instance adds itself to the collection from the startFilterWithCompletionHandler: method and removed itself from the collection from the stopFilterWithReason: method. So the most probable hypothesis is that the stopFilterWithReason: was not called. Which would be more a bug in the NetworkExtension framework. I haven't been able to reproduce this case so far (like by disabling/enabling the Network filter from the System Settings).

It is a System Extension with only one data filter.

A sub folder of /Applications, yes.

Is there some reason you’re unable to do that? Yes, it's related to other macOS requirements that make it mandatory to have the binary in this location (whose parent system directories are not root:wheel 755).

It's not specific to a location. But then there's the SIP factor and whether the default ownership and permissions are restrictive enough. Which is the case for /Library/LaunchDaemons. So the issue I'm concerned about is not with the launchd plist file but really with the program targeted by the plist.

It can be reproduced on macOS 15.5 (and at least another 3rd party software).

Most folks who install launchd property list files install the target executable in a directory that’s only writable by root. Because of what could be seen as a security regression introduced in macOS Installation framework some years ago, this can't be guaranteed.

Feedback ticket for the documentation: FB17345983                  But as a third-party developer I’m not sure that’s a significant restriction. If you’re building your own daemon or agent, you can bake spawn constraint into its code signature. This would protect the daemon or agent from being launched by an unexpected executable. BUT this would not prevent the launchd plist from starting an executable at the path pointed by the plist but which is not the expected executable.

It can be reproduced on macOS 15.4.

Is DocC also responsible for the gotoNextPane and gotoPreviousPane methods of InstallerPane (InstallerPlugins framework) being weirdly defined as readonly properties? Already filed another feedback ticket about that one.

IMHO, it matters considering that: this is the Objective-C flavor of the documentation. the prototype of the method returns a BOOL. the title of the chapter is "Return value". The type is a BOOL. for more than 30 years, it has been YES or NO (e.g. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/Foundation/Classes/NSDictionaryClassCluster.htmld/index.html). It's a documentation so I don't see how the fact that TRUE, true, YES or 1 are all the same matters.

I removed the filter. Outbound UDP flows are all seen. The inbound UDP flow in the test scenario is never seen. Some other inbound UDP flows are seen. Here's the modified source I used for the FilterDataProvider: // MARK: Properties // The TCP port which the filter is interested in. // MARK: NEFilterDataProvider override func startFilter(completionHandler: @escaping (Error?) -> Void) { completionHandler(nil) } override func stopFilter(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) { completionHandler() } override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { guard let socketFlow = flow as? NEFilterSocketFlow, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint else { os_log("Early return") return .allow() } os_log("Got a new flow (socket protocol: %d direction: %d) with remote endpoint %{public}@", socketFlow.socketProtocol, socketFlow.direction.rawValue, remoteEndpoint) os_log("Got a new flow with remote port %{public}@", remoteEndpoint.port) return .allow() } }