Timer-based updates for apps that aren't running

[mikehearn]

One nice feature of the Chrome updater is that it can update apps that aren't being used right now. It installs a service in /Library/LaunchAgents that wakes up every so often to apply updates. For the user it means the app is always fresh and they never need to see update prompts at all, even if they only use an app occasionally. It's also good for ensuring security updates are applied promptly, as otherwise the user will be exposed when they next start the app if background updates are in use, or if they just click "no" because they're in a hurry.

It has another useful attribute too: if someone ships an app that can't start up for some reason (e.g. incompatibility with new macOS) then the separate service will recover things when it starts up and applies the update externally.

It would be neat if Sparkle offered the same feature, ideally with a single service that could update all Sparkle-ized apps (that opt in).

One interesting thing I noticed: Chrome seems to have installed the Google update agent as root. I don't recall ever giving it permission to do that, but presumably I must have done.

[zorgiepoo]

I imagine Chrome only needs to ask for permission if the app is installed in a location where authorization would be required (though I could be wrong, I don't use Chrome).

Having the developer opt into Sparkle's automatically downloaded updates is the recommended approach. It works in the majority case: most users don't need to authorize and won't need to provide a password, most users will not see an update prompt since updates are installed on quit silently (albeit there are some cases where an update is shown like info-only updates, critical marked updates, or if the user hasn't quit the app for a week -- although the last one can be adjusted via the delegate).

Also sure if you're a Big Entity maybe you can get away with installing an agent/daemon in the background that can be running at any point, but otherwise users may dislike you for it. Imagine if Sparkle did this for many apps and then how unhappy developers/users may be. There are also bigger security implications/risks here in installing a permanent installer tool.

It has another useful attribute too: if someone ships an app that can't start up for some reason (e.g. incompatibility with new macOS) then the separate service will recover things when it starts up and applies the update externally.

This is a bad situation to be in regardless and now you may have more points of failure with a permanent helper tool.

Other relevant discussions for your interest #2169 | #2370. The former illustrates it's possible to use sparkle from an agent/daemon like tool but you have to set up and install such a tool yourself. The latter illustrates why Sparkle installing a permanent helper tool out of box is not feasible for this project.