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.

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

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!

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!

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

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?

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

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!

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 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.

Looking in the build log, the call to ld contains an additional flag in my project, as compared to the test project: "-dynamiclib" ... this may explain why the "_mh_dylib_header" change works, but I have yet to find the build setting which would influence Xcode to use this flag.

An additional piece of information, I have found that Archiving succeeds, so it would appear I'm only experiencing the issue when building/running in debug.

Naturally, the test project works fine. I'm also assuming that there is some project setting that I'm missing. NB - this is a well established large project with numerous targets and sub-projects.

A little more background. I dug into the build output, and it is as follows: Undefined symbols for architecture x86_64: "__mh_execute_header", referenced from: -[MyClass init] in MyClass.o ld: symbol(s) not found for architecture x86_64 I'm building on an M1 Machine, and my targets are all set to build both architectures. Interesting that it can't find the symbol for x86_64, even if building just for Apple Silicon.

We have a linker flag set as follows, and I've used otool to dig into the headers, so I know that we're trying to read header data from an executable, not a dynamic library (Though, the code DOES read the plist data at runtime when building with Xcode 16 using the dylib_header). This leads me to think that perhaps it's Xcode 16 that has introduced a new default build setting that changes the Xcode 15 linker behavior? -Wl,-rpath,@loader_path/../Frameworks -sectcreate __TEXT __somePlist_plist ../MySubModule/somePlist.plist.enc