I was able to build with ENABLE_DEBUG_DYLIB set to NO... though the default appears to be yes, based on the value in the test project.

After finding this, I searched for the setting, and found a known issue about it in the XCode 16 release notes here: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes?changes=_1 Known Issues Some large or complex projects may fail to build and run if they are scanning for specific Mach-O sections in their binaries. (123416939) Workaround: Try setting the build setting ENABLE_DEBUG_DYLIB=NO. This will disable the debug dylib that enables the new preview execution mode. Setting this to NO will still allow you to preview in Xcode 16 Seed 1 using the legacy execution mode, but support for this mode will be removed in a future build. Perhaps I need to switch from "legacy execution mode" to the new preview execution mode? Is there a setting for this?

I can't speak to the Swift side without doing a lot of refactoring, but the Objective-C version works! I do get the following warning, however: Incompatible pointer types passing 'const struct mach_header *' to parameter of type 'const struct mach_header_64 *' Using this declaration fixes the warning: extern const struct mach_header_64 __dso_handle; I'd call this one settled... is it possible to change the accepted answer to your final post? Thanks!

If the framework will then be able to perform privileged operations, then yes. 😉 Thanks!

There is no default framework search path for the helper tool. As a result, the helper crashes at launch because it can't find the framework. What's the search path to look in the parent directory?

For reference, the crash report includes this: Library not loaded: @rpath/MyFramework.framework/Versions/A/MyFramework

I think I figured it out. In any event, the helper is no longer crashing. I added @executable_path/../Frameworks to Runpath Search Paths in the helper's build settings. Thanks!

Sorry, I didn't mean to leave this hanging. It turned out that the problem was the location of the application. It is an accessory app, so we were storing it outside of the Applications folder. Installing it in the Applications folder 'solved' the issue. You can reproduce in Monterey by moving an app containing widgets to somewhere like Application Support. It appears that later versions of macOS can discover widgets outside of Applications, while earlier ones cannot. Thanks!

Thanks for the quick response. Feedback filed, number: FB16924007.

Thanks! I'm afraid I still need to support Ventura, so I can't adopt Swift 6 just yet. I have a tool that verifies volumes using diskutil.

In playing with Subprocess, I'm assuming that I'll need to use the custom closure example... Except that the sample code has some errors, particularly, this line: { execution in // <--- it wants three more arguments and: for try await chunk in execution.standardOutput { //<--- Execution doesn't have a member standardOutput Not sure where to go from here... Perhaps return to an earlier methodology?

Since Subprocess is so shiny and new, do I still use Feedback Assistant, or do I need to do so elsewhere?

I've been working on reading the data with: DispatchIO.read(fromFileDescriptor: readFD.rawValue, maxLength: whatLength, runningHandlerOn: queue) and also from an instance of DispatchIO like: let channel = DispatchIO(type: .stream, fileDescriptor: readFD.rawValue, queue: queue) { error in ...} // and channel.read(offset: 0, length: 2, queue: queue) { done, data, error in ... } I'm finding that these don't 'see' the data until the process finishes either... can you point out what I'm missing? Many thanks!

Looks like someone has already posted an Issue regarding adding high/low water marks for AsyncStream. It will certainly be ideal if that option becomes available. Thanks!

I should add, that using codesign -d -vvvv to interrogate my helper, it doesn't appear that the parent process plist (.coderequirement) is getting embedded in my command-line helper tool. The info.plist IS getting embedded, however.