Thanks. When you write: "Everything needs to be handled in the main thread", does that mean that the calls absolutely need to be on the main thread? Or is it possible to use the Bluetooth API from secondary threads as long as one adds a locking mechanism around those calls?

myprocess.crash

I agree that the Rosetta entry at the end of the Binary Images is a bit mysterious. This is a Universal binary running native according to the "Code Type" field. As far as I know, it's Intel on Intel. I can add the missing Binary Images section. Will re-post.

myprocess.crash

Thanks a lot. I will try to figure out if there are some suspicious Mach port actions in thread 11.

Did you try creating and installing a Network Extension with a profile AND with an actual code-level project also? Did each one of these install paths possibly create a new Network Configuration on your system? If you're thinking about the case where there would be a regular installation of the Network Installation while some work is being done in Xcode with a debug/test version, this is not the case here.

You are not removing from a system daemon or command line utility are you? No, there are no attempts to remove the Network Extension form a daemon or using systemextensionsctl.

What type of Network System Extension is this? Content Filter Are there any logs that show up during install time that might help identify what is going on? I don't have access to the unified logs from install time. I can just see that the installation worked fine from install.log point of view. Is there a screen shot that you can provide on both of your network configurations installed at the same time? I can not provide the one I was given. But I can ASCII Art it: Location: Automatic Wi-Fi Please use "My Great Application" to control this content o Connected. filter configuration. My Great Network Extension o Running Another Extension o Running My Great Network Extension o Running Other Interface o Not Connected Yet another Interface o Not Connected […]

By accident, I got the same problem while doing something else. So if there are instructions to get more information, I can try them. It's worth noting that when this UI issue occurs: there can be extensions waiting to be removed according to systemextensionclt list but on the next restart the problem is still there and the extensions had been removed. deleting one instance of the extension in the Network PrefPane can remove both of them. if you delete the extensions (using the Network PrefPane) and re-allow the extension, the problem does not reappear (at least so far).

Apparently, there are __covariant and __contravariant attributes in Objective-C. __contravariant would mean, AFAIK, that only instances of MySubClass or its super classes would be possible keys. Instances of a subclass of MySubclass would not be allowed.

BTW, is there any plan to provide documentation for this event and the new Ventura events? This could be interesting to know whether there is a bug or this is the "designed" behavior. The online documentation for the new event types is currently: not helpful as there is not the beginning of basic Discussion section. buggy: the new event types are listed separately as constants. Ref. https://developer.apple.com/documentation/endpointsecurity/es_event_type_t/es_event_type_notify_btm_launch_item_add

vs. Ref. https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle help app, helper tool. macOS. Contents/MacOS/ Contents/Helpers/ macOS framework. Versions/A/Helpers/

Thank you very much for the detailed answer. I will check on my side if it's just the registering call that is missing. Regarding the status value, I'm apparently not the only one that is mislead because the documentation clearly states that this means there is an error: Both inline and online documentations: SMAppServiceNotFound An error occurred and no such service could be found While I'm looking into this new framework, I must confess that I find the documentation to be rather: confusing with important pieces of information being available in the inline documentation but not, AFAIK, in the online documentation. e.g the requirement for applications to be notarized to embed LaunchDaemons. incoherent with the returned values, whether a value is actually returned or not. e.g. the registerAndReturnError: method where the inline documentation states that true and false are returned, or where both the inline and online documentation state that CoreFoundation enum values are returned by this method whereas these are just possible error codes of the NSError * out parameter. confusing when it comes to the case where an embedded LaunchAgent or LaunchDaemon, or their corresponding PropertyList are updated. This is a part where a project example would provide some clarification. From the way it looks so far, the documentation seems to suggest that the version management of embedded agents or daemons could be worse than the embedded System Extensions' one and could make the whole thing unusable. I'm also surprised by the method prototypes for register and unregister which, unless I'm mistaken, do not follow the Cocoa pattern and are strongly suggesting that a NSError * is being returned. I'm surprised that there are no recommendations in the documentation regarding the POSIX permissions for the property list or embedded launch agents/daemons considering that these are usual show stoppers for the legacy agents or daemons. I'm disappointed that there are no Cocoa error domain string or error code values and that it is required to use CoreFoundation values. I filed a few Feedback assistant tickets about this.

Feedback IDs: FB11875368 - deprecated constants being used FB11873325 - registerAndReturnError: weird prototype and incorrect documentation FB11873316 - registerAndReturnError: incorrect documentation FB11873303 - missing information in online documentation FB11873295 - documentation is scary when it comes to updated plist or items. It also looks like, from what I'm observing, that the register and unregister APIs do no behave as documented. In the headers, it is written that when trying to register an already registered item or unregistering an already unregistered item, an error will be returned but the returned BOOL is YES and the out NSError * is nil. If the service is already registered, this API will return error kSMErrorAlreadyRegistered If the service is already unregistered, this API will return error kSMErrorJobNotFound Side note: it looks like that the forum code is not ready for FB# greater than 9999999 when it creates the helpful link.

Did you try this on 13.0? No, I'm running macOS 13.1 (in a VM, in case that matters).