LoginItem sporadically not launching, not debuggable

As per a previous thread which for some reason is not coming up in search, I have an app with a helper app embedded within as a login item. It is registered via SMLoginItemSetEnabled. XPC is used to communicate with it.


This was working fine before but recently I'm finding one of the following happening:


- The helper app does not launch. launchctl will list an entry for it with an exit code of 78.

- The helper app will launch, but when I have Xcode set to attach on launch, it won't attach and any XPC communication doesn't seem to do anything.

- The helper app will launch and I can attach with Xcode, but it doesn't seem to stop at any breakpoints. This indicates that some shadow version of the process is running.

- I launch the helper app in Xcode but the app will not communicate with it.


Also, even when the helper is running and launchctl show things are hunky dory, before, if I killed the process, launchctl would immediately launch it again and I would have to remove it to stop it entirely. Now, it will not relaunch.


This has made it near impossible for me to debug anything in the helper for the past couple of days. Any insight or additional tools I can use to diagnose this would be greatly appreciated.


Thanks.

Accepted Reply

As per a previous thread which for some reason is not coming up in search

You mean this one?

Sandboxed login items can be kinda finicky. If I run into problems like this, I generally find that I can reset things by:

  1. Calling

    SMLoginItemSetEnabled
    to disable the item
  2. Deleting all copies of my app and its associated login item

Fortunately these problems rarely show up on user machines; you’re more likely to see them on development machines, where you’re regularly building and updating your app.

Share and Enjoy

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

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

Replies

As per a previous thread which for some reason is not coming up in search

You mean this one?

Sandboxed login items can be kinda finicky. If I run into problems like this, I generally find that I can reset things by:

  1. Calling

    SMLoginItemSetEnabled
    to disable the item
  2. Deleting all copies of my app and its associated login item

Fortunately these problems rarely show up on user machines; you’re more likely to see them on development machines, where you’re regularly building and updating your app.

Share and Enjoy

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

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

Note that the app isn't sandboxed.


Will doing 'launchctl remove' do the same as SMLoginItemSetEnabled? I have been doing that and it doesn't seem to work. Is there some cache somewhere I can ****?

Note that the app isn't sandboxed.

Yeah, the problem is that login items installed via

SMLoginItemSetEnabled
don’t have a good name. Some docs call them sandboxed login items, because they were added for the benefit of sandboxed apps, but that’s not perfect because sandboxing is not mandatory for either the login item or the container app. Some docs call them XPC login items, because they can provider an XPC service, but they are not required to provide such a service. I think I’m going to start calling them ServiceManagerment login items.

Will doing

launchctl remove
do the same as
SMLoginItemSetEnabled
?

I’m not sure. What’s wrong with simple calling

SMLoginItemSetEnabled
? Why do you need a command-line alternative?

Share and Enjoy

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

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

Thought having a quick commandline thing I could call to fix it as needed would be more convenient. Also, just curious.


Also, it seems that what triggered this recently was that a code path changed. Previously, SMLoginItemSetEnabled was being called every time to unregister before registering but that a changed mixed things up such that it wasn't always the case.


Thanks.