Add preference: start at login

[lwouis]

This app is a background app that should, for most people, launched automatically at login.

First step would be to investigate if Cocoa or popular libraries offer this feature.

[mrc247-DE]

i miss the autostart option too

[mrc247-DE]

I created a login object for my user, so that
alt-tab-macos starts automatically. The strange thing is, sometimes it starts and sometimes it doesn't. strange...

[lwouis]

sometimes it starts and sometimes it doesn't. strange...

Maybe sometimes it starts fine, and sometimes it crashes at startup, so from your perspective it didn't start at login? It would help to implement #132 so that if the app crashes at login, you would get a feedback popup and by pressing "send info" it would open a ticket here so that we can understand what's happening and provide a fix for it!

[lwouis]

After some research regarding how to implement this ticket, I found that there is a complex history with different historical ways to implement this.

I found this framework as a good candidate to use. It uses the latest recommendation from Apple to use the Service Management framework to implement launch-during-login. Note this weird design decision from Apple:

Login items installed using the Service Management framework are not visible in System Preferences and can only be removed by the application that installed them.

[lwouis]

Another worry I have is that we are starting to stack multi-processes systems:

• Updating the app with Sparkle uses helper processes
• Moving the app to /Applications with Let's Move uses a helper process
• Starting the app at login would use a helper processes

I'm afraid of bad interactions here. For example, you update the app with Sparkle; at this point, is the startup-during-login going to work with the new app? It's making testing more and more e2e and lowers my confidence in new releases being stable :/

[nathang21]

Seems very odd of Apple. Personally I think users can just add startup apps via system preferences. Maybe the app settings could just have a direct link to the system preferences, instead of implementing its own logic?

…

On Mon, Feb 17, 2020 at 6:33 PM lwouis ***@***.***> wrote: Another worry I have is that we are starting to stack multi-processes systems: - Updating the app with Sparkle uses helper processes - Moving the app to /Applications with Let's Move uses a helper process - Starting the app at login would use a helper processes I'm afraid of bad interactions here. For example, you update the app with Sparkle; at this point, is the startup-during-login going to work with the new app? It's making testing more and more e2e and lowers my confidence in new releases being stable :/ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#159?email_source=notifications&email_token=AB4CUJXTRMWFUKRUGATNCHLRDNCJJA5CNFSM4KTGGCKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAKOCY#issuecomment-587245323>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4CUJSREUYWFJZIMQEMQQLRDNCJJANCNFSM4KTGGCKA> .

[lwouis]

I investigated implementing this using the deprecated (but still available as of macOS 10.15) API: LSSharedFileListCreate([...]kLSSharedFileListSessionLoginItems. Here is some code I was playing with, in case someone is interested in learning about how that API family works:

static let url = URL(fileURLWithPath: Bundle.main.bundlePath) as CFURL

// observing the OS login items
let loginItemsRef = LSSharedFileListCreate(nil, kLSSharedFileListSessionLoginItems.takeRetainedValue(), nil).takeRetainedValue()
        LSSharedFileListAddObserver(loginItemsRef, CFRunLoopGetCurrent(), CFRunLoopMode.commonModes.rawValue, loginItemsDidChange, nil)

// adding/removing login item depending on the checkbox state
@available(OSX, deprecated: 10.11)
@objc static func startAtLoginCallback(_ sender: NSButton) {
    let loginItems = LSSharedFileListCreate(nil, kLSSharedFileListSessionLoginItems.takeRetainedValue(), nil).takeRetainedValue()
    if sender.state == .on {
        let loginItemsSnapshot = LSSharedFileListCopySnapshot(loginItems, nil).takeRetainedValue() as! [LSSharedFileListItem]
        debugPrint(loginItemsSnapshot.count)
        LSSharedFileListInsertItemURL(loginItems, kLSSharedFileListItemBeforeFirst.takeRetainedValue(), nil, nil, App.url, nil, nil)
        debugPrint(loginItemsSnapshot.count)
    } else {
        let loginItemsSnapshot = LSSharedFileListCopySnapshot(loginItems, nil).takeRetainedValue() as! [LSSharedFileListItem]
        loginItemsSnapshot.forEach {
            if CFEqual(LSSharedFileListItemCopyResolvedURL($0, 0, nil).takeRetainedValue(), App.url) {
                LSSharedFileListItemRemove(loginItems, $0)
            }
        }
    }
}

// reacting to a change made on the OS login items UI
@available(OSX, deprecated: 10.11)
func loginItemsDidChange(_ loginItems: LSSharedFileList?, _ pointer: UnsafeMutableRawPointer?) {
    let startAtLoginCheckbox = Unmanaged<NSButton>.fromOpaque(pointer!).takeUnretainedValue()
    let loginItems = LSSharedFileListCopySnapshot(loginItems, nil).takeRetainedValue() as! [LSSharedFileListItem]
    let loginItem = loginItems.first(where: { CFEqual(LSSharedFileListItemCopyResolvedURL($0, 0, nil).takeRetainedValue(), App.url) })
    startAtLoginCheckbox.state = loginItem != nil ? .on : .off
}

Outside of the technicalities, I think this way of doing start-at-login is fading away. I reviewed the apps on my mac, and most of them use the new approach of "each app handles their own start-at-login through custom UI, and the user has no central place to manage that".

I think I will go with the new approach as it is clearly where Apple wants to go. Also I think the user can always throw away an app if they are frustrated that it is launching at login and the UI is poor or absent in that app to disable it.