SMLoginItems not in ~/Library/LaunchAgents?

I just built a little demo app, based on the Apple document Adding Login Items Using the Service Management Framework. My app has a menu command to install+run a helper app which is packaged in its

Contents/Library/LoginItems
. It seem to work: When I run my app and click this menu item, the helper app launches. And if i then log out and back in, the helper app launches. Another menu command, to uninstall+quit the helper app terminates it as expected. But my helper app never appears referenced in
~/Library/LaunchAgents
.
I expect that it should be, since documentation states that Service Management framework provides facilities to load and unload launchd services and read and modify launchd dictionaries. My helper also never appears in
/Library/LaunchAgents
, nor in System Preferences > Users & Groups > Me > Login Items, even if I quit and relaunch System Preferences.


I compared my demo's behavior to that of Arq (arqbackup.com) and its Arq Agent helper. Both apps have helpers residing in the main app's bundle, at

/Contents/Library/LoginItems
. But Arq Agent is listed in System Preferences > Users & Groups > Me > Login Items. Another difference is that with my demo app, if I force quit the helper, whether or not the main app is running, the system immediately relauches the helper (it has a new PID). Arq Agent remains quit if Arq is not running, but if it is, Arq displays a dialog with a button to relaunch the helper, and the helper is not relaunched until the user clicks this button. I conclude that Arq is not using the Service Management framework.


It seems strange that, in these days of ever-increasing security and asking permission for everything,

SMLoginItemSetEnabled()
creates its own category of invisible launchd tasks, controllable only via the parent third-party app. I'm running Mojave Beta 9. Is this possibly a bug?


My app package is a Debug build, signed by Xcode for Developer ID, and moved into

/Applications
. It does not have an icon assigned, so it appears as the generic "A".

Accepted Reply

I don't know what is going on with Arq. Maybe it has some kind of custom installer or something. It is definitely not doing the login item correctly.


Everything you describe about your app sounds correct. Service Management login items live only inside their app. There is no separate plist file for them. They also never appear in System Preferences. The system does indeed create its own category of invisible launchd tasks, controllable only via the parent third-party app. This is by design, not by bug.

Replies

I don't know what is going on with Arq. Maybe it has some kind of custom installer or something. It is definitely not doing the login item correctly.


Everything you describe about your app sounds correct. Service Management login items live only inside their app. There is no separate plist file for them. They also never appear in System Preferences. The system does indeed create its own category of invisible launchd tasks, controllable only via the parent third-party app. This is by design, not by bug.

Thank you for confirming it, John.


There must be some other file where these Service Management Login Items are listed, though. It would certainly be handy for Mac consultants to check when customers see malware running. I mean, there is the list:

  1. System Preferences … Login Items
  2. ~/Library/LaunchAgents
  3. /Library/LaunchAgents
  4. Service Management Login Items

But where do you look for #4?

The

LaunchAgents
directory hasn’t totally reflected reality since we stopped updating the
Disabled
flag in those property lists, way back in the day (10.7?).
launchd
tracks various bits of state in its own database (currently
/var/db/com.apple.xpc.launchd/
) and I’d expect to find
SMLoginItemSetEnabled
items in there somewhat.

IMPORTANT This database isn’t considered API, so it’s fine to poke around in there for investigative purposes but please don’t encode such knowledge into software you distribute to a wide audience.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"