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

If I have additional questions should I post on the other thread? The interesting thing is that if I use _mh_dylib_header, I get a build error in Xcode 15/macOS 14.

I ended up adding commands to the main WindowGroup, and 'faking' the shortcut indicators in the sub-menu. I'm still curious, though, if there is a way to surface sub-menu keyboard shortcuts without this work-around.

A clean Sequoia install did address the issue. Thanks! It does lead to the question, if an app already in production moves from SMJobBless to SMAppService, could this issue crop up for those apps? We have the luxury of shipping this app as SMAppService to start, but we have a few legacy apps that will eventually have to make the jump.

Hello, Yes, using SMAppService. I'm working on re-doing the test machine. (Is there a thread on how you guys recommend developers do VMs? I couldn't find one...) In the meantime, below is the slightly redacted code sign result. (I apologize for doing things out of order.) Thanks! App Executable=/Applications/MyApp.app/Contents/MacOS/MyApp Identifier=com.myCompany.MyApp Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=2369 flags=0x10000(runtime) hashes=63+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=4f7273a43e951e145744876fdca528dc6dce79e6 CandidateCDHashFull sha256=4f7273a43e951e145744876fdca528dc6dce79e6802450108738a6971be08681 Hash choices=sha256 CMSDigest=4f7273a43e951e145744876fdca528dc6dce79e6802450108738a6971be08681 CMSDigestType=2 CDHash=4f7273a43e951e145744876fdca528dc6dce79e6 Signature size=9069 Authority=Developer ID Application: MyCompany () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jun 17, 2024 at 5:16:29 PM Notarization Ticket=stapled Info.plist entries=30 TeamIdentifier= Runtime Version=14.2.0 Sealed Resources version=2 rules=13 files=9 Internal requirements count=1 size=216 Daemon: Executable=/Applications/MyApp.app/Contents/MacOS/com.myCompany.MyApp.daemon Identifier=com.myCompany.MyApp.daemon Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=1000 flags=0x10000(runtime) hashes=20+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=20f56ee32d7846e5845ee210c9a9cee20a3fcb1d CandidateCDHashFull sha256=20f56ee32d7846e5845ee210c9a9cee20a3fcb1db434afe904aa1e1e56cf9f78 Hash choices=sha256 CMSDigest=20f56ee32d7846e5845ee210c9a9cee20a3fcb1db434afe904aa1e1e56cf9f78 CMSDigestType=2 CDHash=20f56ee32d7846e5845ee210c9a9cee20a3fcb1d Signature size=9068 Authority=Developer ID Application: MyCompany (*******) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jun 17, 2024 at 5:16:29 PM Info.plist entries=15 TeamIdentifier=***** Runtime Version=14.2.0 Sealed Resources=none Internal requirements count=1 size=220

Shoot... I realized that the existing processes were from a previous build that utilized SMJobBless. After unloading, the app does add the service to loginItems, but now there's a note that the process isn't signed, and the app doesn't connect to the helper. Guessing I should start a new thread?

It was upgraded. Other than reformatting the drive, is there a way to 'reset' the system for a given background item? I would think that an upgraded machine should still show the app in the list.

I didn't think to check, but yes, it's running. What's the methodology for applying privilege to a daemon in Sequoia? Would we need to conditionally open the Login Items pane depending on the OS version?