Silent Updates

Lately I’ve been thinking about software updates on the Mac, specifically patch releases. With just about every app that isn’t in the App Store adopting Sparkle I see that update prompt quite a bit, usually populated by release notes consisting of bug fixes and performance improvements. It’s fantastic that developers are improving the apps I use, but with updates like this I pretty much mindlessly click install, then wait while the update is downloaded and applied. Depending on the speed of my connection to the update server and the complexity of the install process I could be waiting a while.

Compare this with the experience of using Chrome or Dropbox. Both apps just install the latest version with little to no presentation to the user. Chrome shows you its Arrow of Judgement if you don’t restart the app for a while when an update is pending, but normally you don’t know anything has happened. Dropbox is able to restart itself and shows no UI at all. When using these apps you don’t have to think about software updates. You just use the app and benefit from the improvements.

For patch releases the silent update process strikes me as the better choice. Your apps improve with fewer update prompts and less thinking about software updates for everyone. I say patch releases because an across the board silent update seems like going too far for most desktop apps. The goal of a silent update process should be to refine the experience the user is familiar with. The UI and application behavior shouldn’t just change unannounced. Imagine if you were giving a presentation and launched an app to find that it had silently updated with a redesigned user interface. All the saved update prompts in the world aren’t going to make that up to you.

With this in mind I came up with some guidelines for how I would implement a silent update process:

• Automatic updates are enabled by default.
• Automatic updates can be disabled.
• There is a method to manually check for an update.
• Updates that substantially change the application’s behavior or user interface require user approval.
• Updates that interact with the user during installation require user approval.

The ability to disable updates doesn’t need to be part of the UI, but it should be possible. If a user runs into an update that doesn’t work on their system they should have a way of going back to a previous version and staying there. Likewise, a manual update check doesn’t need to be obvious in the UI but should be there for users that follow your blog or Twitter feed. If they see that a new version has been released they should be able to use the software update process to get it.

I hope to implement something like this in my own apps in the near future. Besides making a small dent in the number of update prompts slung at users I think this will increase the number of updates I release. Many times I’ve made a small fix and then sat on it for weeks because it didn’t seem worthy of a release by itself. When such releases are invisible there’s no reason not to get it into everyone’s hands right away.

Update: Work is in progress to implement this in Sparkle’s quiet-automatic-update branch.