If the app termination request is delayed or canceled, the user can check for updates again with the standard user driver and try installing/relaunching again, which will trigger the installer to send another quit event to the running application.
Before the install/relaunch window would close but the check for updates option would still be present but not functional.
On macOS 13 (Ventura) and later, installation could fail if Gatekeeper blocks app modifications. Note this is only applicable for external updaters like sparkle-cli where the updater and target bundle to update have different team identifiers.
When the framework or sparkle-cli is run as root, we always launch the installer (Autoupdate) in the system domain.
For the progress tool agent, we chown() the copied Updater.app so the Updater app has proper ownership of it (and clean it up later). The progress tool app may not be able to clean up the parent directory, but that's okay and will be garbage collected on a later run.
To get the username and home directory for the user session when running the framework as root, we use the SecurityConfiguration framework. Sparkle needs and depends on an active GUI user login session. If a user ssh's in to install an update, that user must be the same as the active logged in user.
Installing interactive based package updates as root is not supported. For sparkle-cli, we disallow using --interactive when running as root.
An additional error exit code is added for sparkle-cli when ran as root and trying to install a interactive based package update, which is unsupported.
The workflow assumes changelog and version information have been updated and the tag has not been created yet before running it. When the workflow finishes, it should take you to a release page with the uploaded binaries, where you can verify the final details and publish a tag officially.
Also the following improvements were made:
* Change CURRENT_PROJECT_VERSION to represent a monotonically increasing bundle version (starting at 2000)
* Add MARKETING_VERSION to represent marketing version of Sparkle, comprised of SPARKLE_VERSION_MAJOR, SPARKLE_VERSION_MINOR, SPARKLE_VERSION_PATCH, and the new SPARKLE_VERSION_SUFFIX for pre-releases.
* Verify code signing signatures of extracted SPM zip file in make release and CI
* Generate changes to Sparkle podspec, just like the Package.swift file, based on current marketing version
* Improve format of Info.plist version strings when appending git hash info, eliminating unnecessary whitespace
* Simplify validating that XPC Service versions align with framework version
* Handle lightweight tags in addition to annotated tags in release-move-tag.sh
* Don't expose SPUDownloadData initializer publicly
* Make SUAppcast -init unavailable
* Fix documented default user agent string
* Improve header documentation for SUAppcast(Item) and comparators
* Update more API documentation headers
Also allow returning nil in -allowedSystemProfileKeysForUpdater:
* Clarify documentation on -allowedSystemProfileKeysForUpdater:
* Rename willIdleScheduling -> notSchedule for delegate method
* Make minor correctness fix for reading info URL
In some cases for shared headers in downloader XPC Service or generate_appcast / sign_update tools, I had to do a little dance for using double quote imports.
We unify the user driver method showing the update to take a generic state object now. The current fields of the state object are its current stage, if it's user initiated, and if the update is a major one.
We also remove deprecated code paths that were complex to support and will otherwise generate in compile errors if people adopt the new API.
We don't have a dismiss method for every transition state and we don't want to. This should be up to the UI to determine how to transition from one UI state to another UI state.
When the update is shown to the user, the menu item for checking for updates is no longer disabled. Instead it is enabled, and when invoked, will bring the update to utmost focus back to the user again.
This is consistent with other options (eg Preferences...) that bring up windows. Improved user experience here is that updates are now less "lost".
We (re)define properties on SPUUpdater:
canCheckForUpdates - to mean that the user can check for updates (start a new update check or show the already present update frontmost)
sessionInProgress - to mean if Sparkle's internal driver / scheduler is running (i.e, downloading appcast or update, showing update, starting installation).
And remove logic in SPUStandardUpdaterController and SUUpdater that defers starting the updater one cycle later, because that logic is now in SPUUpdater which they invoke.
It is too easy to start the updater "too soon" (if not using SPUStandardUpdaterController or SUUpdater) and I had some weird approach before that allowed the developer to check for updates before starting the updater and it would get deferred until the updater was started (without showing a permission prompt). Instead, defer the update cycle check allowing developer to check for updates immediately after starting the updater if needed (sparkle-cli needs to do this in one case).
Errors are now logged when checking for updates without having started the updater.
This fixes edge cases of UI being shown too early.
This reduces friction in creating a SPUUserDriver. This assumption that the calls could be made from any thread is a relic of the past of separating the user driver into a different process from the updater/scheduler, which is no longer sane or supported.
This should speed up things very slightly too.
This will increase the chance of a user driver implementing being able to show informational only updates. Also it's better to use a new method rather than re-use another existing one inappropriately.
This is better than the hack in the previous commit. Also, a user driver may very well want to act differently in showing UI if the user initiated the update check.
This allows us to remove SPUUserDriverUIComponent and remove a bunch of logic in the user driver regarding termination. The user drivers generally don't need to know about the application bundle anymore, and strictly now only show UI events.
This has another advantage of the agent being able to quit multiple instances of an application even if the application to update is sandboxed.
We enforce the logic that an application can only be relaunched if it was running initially.
Zorg
Tony Arnold
Daniel Jalkut