SMLoginItemSetEnabled sometimes silently fails to launch sandboxed UI helper

Question

I have an app that is sandboxed, and includes a helper that presents some UI (as a full-screen window, but could be a status item or similar too).

This works... most

Answer 1

Highlighting a source / explanation posted in the comments:

If multiple applications (for example, several applications from the same company) contain a helper application with the same bundle identifier, only the one with the greatest bundle version number is launched. Any of the applications that contain a copy of the helper application can enable and disable it.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html#//apple_ref/doc/uid/10000172i-SW5-SW1

Thus a potential fix for this issue is to increment the bundle version number of the helper app. The new version with the greatest version number will then be the one that is launched.

Answer 2

If you force quit the login item from Activity Monitor, it will be relaunched and log some information.

Check the console log below to determine the location of the new instance being launched:

LSApplicationCheckIn(), app being registered is: "/Applications/YourApp.app/Contents/Library/LoginItems/YourLoginItem.app/Contents/MacOS/YourLoginItem"

Answer 3

Is there any way to make SMLoginItemSetEnabled always use the login item from the current app bundle, rather than some random one elsewhere on the disk?

It seems that there is is a bug in SMLoginItemSetEnabled. When I test my application, the executable is in the DerivedData folder of Xcode.

When I build the release, I put the application and it's helper in the /Applications folder. But for some obvious reasons, the helper that is launched is the helper which is in the DeriveData folder. That's why I'm used to remove everything that is in this folder before launching the main application in /Applications.