Thanks for the detailed explanation! It was helpful. 😊

I should note, that the menuBarExtraStyle is .window, and the menu is displayed with a button.

I'm seeing this issue, and the app window (I'm using XIB) is also not remembering where it was left.

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?

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.

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?

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

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.

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.

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.

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

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.

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.

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.

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.