SMLoginItemSetEnabled is launching the parent application instead of the helper

Additionally, the main.swift file for the helper is basically empty, it has no logic for launching the parent application:

import AppKit

final class AppDelegate: NSObject, NSApplicationDelegate {
    func applicationDidFinishLaunching(_ notification: Notification) {}
}

private let app = NSApplication.shared
private let delegate = AppDelegate()
app.delegate = delegate
app.run()

Also, if I query the system for the login items via SMCopyAllJobDictionaries(kSMDomainUserLaunchd) it corrects lists com.company.loginlauncher

The craziest thing is that this only happens when the app is launched in the quarantined env (AppTranslocation). When dragging the app into /Applications before launching, this doesn't seem to be a problem.

Can you reproduce this on a ‘clean’ machine? That is, if you create a fresh install of macOS [1] and install your app like one of your user’s would, do that also have the same problem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I usually use a VM for this, restoring from a snapshot between each test.

It’s 100% reproducible on a fresh machine (at least in a parallels VM).

It's also reproducible with other apps using this mechanism eg: https://github.com/newmarcel/KeepingYouAwake

Steps:

1. Download the app
2. Move it to Applications using mv ~/Downloads/KeepingYouAwake.app /Applications (don't use the Finder otherwise the quarantine flag is removed)
3. Launch the app
4. From Preferences, toggle launch at login.

Observe how a second instance is created and destroyed on toggling the launch at login option.

It’s 100% reproducible on a fresh machine (at least in a parallels VM).

Well, that’s clearly a bug, and I encourage you to file it as such. Please post your bug number, just for the record.

Is this only triggered by you moving the app programmatically. That is, if you skip step 2 do you see the problem?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, filed here: FB11674712

If you skip step 2 then neither the LoginItem nor the parent application will launch. I believe a condition for SMLoginItemSetEnabled working at all is that the parent is installed in /Applications?

FB11674712

Ta!

I believe a condition for SMLoginItemSetEnabled working at all is that the parent is installed in /Applications?

No.

Although you could argue that if you replace at all with reliably the statement might be true (-:

A good target for this stuff is ~/Applications, because it has none of the access control restrictions that you see on Applications. So you could something like this:

1. Download the zip archive to the Downloads directory.

2. Move the zip archive to ~/Applications.

3. Unpack it there, so the resulting app is still quarantined.

4. Launch the app.

5. Enable the Service Management login item.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Unpacking the zip inside ~/Application (instead of in ~/Downloads and moving it) exhibits the same problem as /Applications.

OK, so the critical factor here is the app translocation. Interesting.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"