OK, I will file tickets. At least the IBAction one is still happening in Xcode 26.2.

Thanks. I will file multiple feedback assistant tickets as getting documentations and fixing the issues seem to be 2 different topics.

API != command line tool. Not a fan of using command line tools either. I have already a radar/feedback assistant ticket about this issue: 21381323

This issue is related to notarization assessment not being automatically done by the OS. [Q] Are there public APIs to assess notarization? There are private APIs (visible in the security open source code of the security library) but there does not seem to be public APIs.

I don't think the problem is coming from the macOS instance itself as the problem does not occur when the extension is updated using an installation package. The problem only happens when replacing the system extension and its wrapper .app using basic NSFileManager APIs. I diffed the 2 cases and there are no differences. Same files, same contents. And anyway spctl and codesign are happy. I tried different macOS versions in VMs (14, 15). Same result. What I'm also observing is that after updating the system extension using an installation package, just using the NSFileManager APIs is going to work fine when reverting to any version that has been previous installed via an installation package or updating to version that has been previously updated via an installation package.

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.