Sparkle doesn't close and relaunch the app with custom user driver

[tomrozb]

Summary

When SPUStandardUserDriver is set as the driver, there's native UI which asks to "install and relaunch" - that works perfectly fine, app closes, updates and relaunches.

In my case I provide custom UserDriver that overrides the necessary function as shown below (the goal is to get rid of OS native UI):

final class SilentUserDriver: NSObject, SPUUserDriver {
    func showReadyToInstallAndRelaunch() async -> SPUUserUpdateChoice {
        return .install
    }
}

That installs a new version, but doesn't close & relaunch the app. What may be wrong here? I also tried to Task.yield() before returning .install, but that didn't help. Should I override other callbacks to enable the relaunch?

As a temporary workaround the code listens to willInstallUpdateOnQuit and quits the app, but in the end I need the app to auto relaunch.

Version

2.8.1

[zorgiepoo]

When SPUStandardUserDriver is set as the driver, there's native UI which asks to "install and relaunch" - that works perfectly fine, app closes, updates and relaunches.

The standard user driver doesn't do much here other than reply with SPUUserUpdateChoiceInstall. Sparkle's helper then sends an apple quit message to the app. The app could technically cancel the app quit termination request but the app would have to go out of its way to do that.

This is in Swift and I don't exactly remember the details with the Swift concurrency model regarding Task 'n all, but I don't think the code looks wrong. I think this is also equivalent to:

func showReady(toInstallAndRelaunch reply: @escaping (SPUUserUpdateChoice) -> Void) {
	reply(.install)
}

As a temporary workaround the code listens to willInstallUpdateOnQuit and quits the app, but in the end I need the app to auto relaunch.

This callback is for updates being automatically downloaded / installed in the background on app quit. This is an orthogonal path from the user driver. This callback and the user driver methods will not be called in the same update cycle, but the user driver can be presented in an update cycle sometime in the future, as long as you don't return YES in this callback, which would stop Sparkle's next update cycles. On the other hand, if you do return YES in that callback, it gives you the opportunity to invoke immediateInstallHandler which should relaunch the app in that case (the user driver would still be used in other situations if an update cannot be automatically installed silently, like when user authorization is involved).

I also very recently added documentation page for custom user interfaces and it highlights some aspects that developers often get wrong about it (e.g. SilentUserDriver judging by its name feels like it may not behave correctly)

[tomrozb]

Thank I'll check the documentation provided and verify the immediateInstallHandler, then post my findings.

I'm actually using a Dart wrapper around Sparkle code (https://pub.dev/packages/auto_updater), which doesn't seem to call
immediateInstallHandler at all, but still the app closes & relaunch when SPUStandardUserDriver is driving the UI.

    public func updater(_ updater: SPUUpdater, willInstallUpdateOnQuit item: SUAppcastItem, immediateInstallationBlock immediateInstallHandler: @escaping () -> Void) -> Bool {
        let data: NSDictionary = [
            "appcastItem": item.toDictionary()
        ]
        _emitEvent("before-quit-for-update", data)
        return true
    }

BTW the SilentUserDriveroverrides showReady as below:

func showReady(toInstallAndRelaunch displayName: String) async -> SPUUserUpdateChoice { .install }

[zorgiepoo]

The willInstallUpdateOnQuit handler is most certainly implemented incorrectly. If it returns true, you likely want to try to invoke immediateInstallationBlock() when suitable, otherwise you stopped the updater from presenting further update notices (it could return false if it just wanted to simply intercept the event). To clarify this callback is driven by Sparkle's automatic update driver, which does not use the user driver, because it is a silent path. The user driver is used in a UI update driver, which is not a silent path. Therefore, a "silent" user driver likely is also not logical.