What do you guys think is best practice regarding auto-updating? Google Chrome for instance seems to auto-update itself as soon as it get's a chance without asking and I'm fine with it. I think most "normal" users benefits from updates being a transparent process.

Then again, some more technical users might be miffed if you update their app without permission, as I see it there's 3 options:

1) Have a checkbox when installing that says "allow automatic updates"

2) Just have a preference somewhere that allows you to "disable automatic updates" so that you have to "check for updates manually"

I'm leaning towards 2) because 1) feels like it might alienate non-technical users and I'd rather avoid installation queries if possible. Also I'm thinking about making it easy to downgrade if an upgrade (heaven forbid) causes trouble, what are your thoughts?

Another question, even if auto-updates are automatically, perhaps they should be announced. If there's new features for example otherwise you might not realize and use them

One thing that kinda scares me though is the security implications, someone could theorically hack my server and push out spyware/zombieware to all my customers. It seems that using digital signatures to prevent man-in-the-middle attacks is the least you could do otherwise you might be hooked up to a network that spoofs the address of of update server.

  • Chrome is a little obnoxious about this. I update my system at least once a week, and almost always see this : The following packages will be upgraded: google-chrome-beta. Almost impossible to adjust for quirks between their many releases.
    – user131
    Jan 4, 2011 at 13:37
  • Google Chrome is not Enterprise friendly due to the gratuitous auto-updates, but they're fixing that: arstechnica.com/microsoft/news/2010/12/… Jan 4, 2011 at 14:16
  • 8
    Of course, the problem with auto-updating instead of getting user input is you can't helpfully offer to install the f@*#&ing Yahoo toolbar every f@*#&ing time you update.
    – Kyralessa
    Jan 4, 2011 at 14:34
  • 2
    Consider that if your audience will be corporate users, they may not have user rights to install updates at all - no matter what option you choose. Thus, an admin should be able to turn it off during installation on their deployment image. Jan 4, 2011 at 14:42
  • Also, if your app can be in any sort of business configuration, the corporate users will not want it changed at what to them is arbitrary times. Updates, unless perfect, are potentially destabilizing. Jan 4, 2011 at 20:51

8 Answers 8


As a tech user, I don't terribly mind opting out of updates, but I imagine you'll see a fair bit of variation on that point. Are you expecting the majority of your app's users to be tech-inclined? If not, then enabling automatic updates by default is a great idea and I'd go with option #2. Otherwise... well, I'd probably still go with option #2 because I like it, but you might want to poll some subset of your userbase to find their preference.

With all that said, my favourite option is "check for updates but let me know when to download and install them". This way I can avoid installing an update if I know I'm just on the computer for 30 seconds to check email.

Definitely make it easy to roll back upgrades if you can, regardless of the update option you go with.

  • The program is of the nature that it's running in the background all the time so I can just do updates when the user has been idle for a time so they don't disturb the user. A "Check for updates but ask to install" them option is nice though
    – Homde
    Jan 4, 2011 at 13:31
  • Roll-back would be awesome. I'm yet to see this work successfully in any commercial software I use. Jan 4, 2011 at 14:20
  • @JBRWilkinson You used to be able to uninstall individual Windows updates/service packs. I think Windows 7 relies on restore points now, but I recall manually rolling back updates in XP.
    – Adam Lear
    Jan 4, 2011 at 14:22

Odd as it may seem the Windows Update dialog has the right options (ignoring the potential for problems caused by the default):

  • Automatic (updates downloaded and installed without user intervention [Microsoft's words not mine]). Though this is badly worded and misleading as the system will reboot without giving you the chance to save work etc. Which is one reason why I don't use it.
  • Download update but let user choose when to install (my preference).
  • Notify but don't download or install.
  • Off.

This gives your user full control over the process from the "silent behind the scenes" to "I'll update if I remember to check".

The default will depend on your audience and how extensive and frequent your updates are. It could be acceptable to silently install small, frequent updates whereas the user might want more control over larger updates.

I wouldn't recommend the silent download and automatically update if there's any chance of the process causing the user to lose data. The default should be either Notify or Download.

  • 9
    Mostly. One thing Windows Update gets very, very wrong--to the point that I wouldn't be surprised to hear of it provoking a class action lawsuit--is rebooting your system without the user's explicit permission. No software should ever do that under any circumstances, especially on a multitasking machine where the possibility for lost work exists. Jan 4, 2011 at 14:17
  • 2
    Anybody who has had to leave their computer with open documents/work/state on-screen and come back the next morning to see a blank desktop with a yellow bubble stating "Your computer was updated!" will strongly dispute that Windows Update gets it right. 'Critical Updates' ignore your setting. Jan 4, 2011 at 14:18
  • 3
    @Mason - well we are talking about the start of the process here rather than the end ;)
    – ChrisF
    Jan 4, 2011 at 14:19
  • 1
    @ChrisF: My point is that it's a terrible example - there is no indication that "Automatic" will Reboot your computer whatsoever. "No user intervention required" is not the same as "Reboot, losing all my work, without my permission" blogs.technet.com/b/mu/archive/2008/10/02/… Jan 4, 2011 at 14:29
  • 1
    @JBR - I take that point, but I was using it as an illustration of the options that you should have for auto updating your application. Will it help if I make the point that Microsoft's definition of Automatic is bad?
    – ChrisF
    Jan 4, 2011 at 14:35

One program whose update style I really noticed for being done well is the diff/merge tool Beyond Compare. It's got an excellent, well-thought-out UI in general, and its update system doesn't disappoint. Basically, when it runs, it quietly checks the update server and if it finds anything, it sticks a link label informing you of the update in the right-hand side of the menu bar. Quiet, unobtrusive, out of your way, but impossible to miss. If you click it, it gives you an update dialog. You hit the button and it downloads, installs, and reboots the program automatically.

It's not fully automated, but I prefer that. Your program could do a lot worse than to follow the same model for updates.

  • Skype (unless I'm confusing with another program) acts in a similar manner, but instead it already downloads the update if there is one, then asks if you want to install now or wait for the next time the application is run. Personally I prefer that it asks before downloading anything at all, but in any case, both are already better than Google's "always running in the background even when no google software is running" auto-updater.
    – wildpeaks
    Jan 4, 2011 at 14:36
  • Also LibreOffice (OpenOffice) does that. But the actual update process isn't automatic and that sucks.
    – ZJR
    Jan 18, 2013 at 12:41

It really depends upon how the automatic updates are being done as there is nothing worse than sitting trying to get some work done and then have a pop up telling you that you need to restart due to an update. Also, I've noticed that some programs that use background downloading will sometimes use a bit too much bandwidth and slow down my web browser when I am trying to do some research online. As such I generally prefer to be able to opt-out of automatic updating unless I know that it is very unintrusive. Firefox tends to do a fairly good job of this as I usually don't notice that it is downloading an update and the actual install process is fairly quick and doesn't require me to interrupt any work that I already have in progress.

  • I think you mean "unless it is very unintrusive". :)
    – Adam Lear
    Jan 4, 2011 at 13:35
  • @Anna Lear - Ah, yes, that is what I meant. ^^"
    – rjzii
    Jan 4, 2011 at 13:38
  • Firefox is a good example - seems to do the right thing, installing when you next run. Jan 4, 2011 at 14:22

What do you guys think is best practice regarding auto-updating?

From talking with other developers, I've found that whatever Adobe Reader does, it irritates the heck out of them. That app has settings where you can set it to check every time it starts (default), once a week, or never. It also pings a certificate revocation server every time it starts as add-ins for the free reader require a digital certificate to load. My position is that since that application has such a widespread adoption rate in corporations, then its behavior should be modeled as that behavior is acceptable to corporate network admins.

I typically work on .NET applications, and the version of application updating "supported" by .NET is called ClickOnce. This doesn't work too well in Vista/Win7 as it tends to install updates "per user" (which means that each user ends up with a separate install of updates, as well as the original install).

One thing that kinda scares me though is the security implications, someone could theoretically hack my server and push out spyware/zombieware to all my customers. It seems that using digital signatures

ClickOnce requires digital signatures.

My personal opinion is that one should leverage off of the existing built-in updating inside of Windows. BITS has been around since WinXP and works reasonably well. For applications that run in a typical locked-down corporate environment, this means your updater will need to run as a windows service (because it will need admin rights). Building off of BITS allows you to also leverage WSUS which allows corporations to determine which updates get installed and when.

  • The problem is BITS is pretty old technology and isnt wellintegrated in many products. Also I have a hard time seeing the need for BITS if you're doing incrimental updates the bandwidth requirements are pretty low and in these days of abundant bandwidth pretty unnoticeable. ClickOnce has it's benefits but I need to be able to run my app portably on a thumbdrive for instance. I decided to go with Wix/MSI and roll my own for checking for updates and running the msi when updating, this has the benefit of playing well with enterprise customers that needs msi packets.
    – Homde
    Jan 4, 2011 at 14:35
  • @MattiasK, BITS is built into every version of Windows that .NET supports. It also handles edge cases (such as the user deciding to suddenly shut down windows during updates) quite well. Our apps handled government forms, and were not suitable for running from removable media (most of our corporate customers have USB ports locked down to prevent inserting USB drives).
    – Tangurena
    Jan 4, 2011 at 14:45
  • @MattiasK: You can make use of ClickOnce without having to use it as an installer (ie. through the Visual Studio interface), calling all of the relevant functionality through your own code and still using MSI for initial installation. Jan 4, 2011 at 14:46

I feel like there should always be the option to turn off automatic updates, as I - like a lot of users in rural areas - am on dialup and there's nothing I hate more than having something start downloading causing me to not have enough bandwidth to surf the internet anymore, or to not be able to disconnect from the internet to make a phone call because this 10mb update is taking 2-3 hours to download. Much better to be able to choose to update when I take my laptop to a wi-fi hotspot and don't have to worry about a dropped connection either.

Of course, being able to turn of automatic updates also makes it harder to kill illegal copies of a program, but in my opinion it's worth it to not alienate a bunch of users.


In our company we have a very high security standard. Our internal IT department doesn't allow any applications which update themselves, because then there is no way for them to control what they do and which version is installed where. They want to roll out any software updates manually (through our own software update system) so that they can examine them for potential security problems beforehand.

Lots of additional work for them? Certainly.

They won't find anything anyway? Maybe.

Counter-productive because it leaves us vulnerable to zero-day exploits for a lot longer? Not my department.

But fact is, many companies work that way. And when your product doesn't allow this update workflow, they won't consider it.


I'd like to point out that on-by-default aggressive automatic updating, when you grow over a certain scale, (or when you rent really absymal servers) might also trigger denial of services if you're not handling it trough p2p/torrent solutions. You might take that into consideration while implementing the functionality.

Also: are you planning painless automatic updating? I hope so.

IMHO the dilemma you present revolts around it. In fact asking to the user, with a little box, at each update, if he wishes to get on the bandwagon, is almost always fine, UI-wise. If the actual update process is swift.

(And ok, you have to provide an option in the menus to turn updates off, as, there are concerned users around, ok, but what you should really consider are enterprise scenarios where people isn't allowed to update stuff)

But the real problem surfaces when the little "how about updating?" box redirects you to the author's site (sometimes even to the wrong url) where you can have the pleasure of:

  • sifting trough the downloads,
  • finding the right link for your platform,
  • starting the download, waiting for it to finish,
  • start the installer,
  • realize you should close the program you where trying to work with to let it update,
  • closing it - blocking your workflow,
  • re-start the installer,
  • mindlessy click "OK," 5 to 8 times
    • (all this hoping you didn't chose a non standard installation path, last time)
  • starting the freshly installed copy of the program
  • wondering what you where up to, before joining all of this joyous update dance.

So, my theory is that it's not that popup that nags the user, but the actual not-really-automatic update process.

It's a pretty widespread defect, and there are reasons for that, but still: bad UX. Some examples that pop to mind: (those also update A LOT, amplifying the symptom)

  • LibreOffice (it has unobtrusive update notifications and allows you to download updates as a torrent, but it really doesn't want to handle its own updates)
  • Filezilla
  • PDF Creator
  • Sumatra PDF Reader

μTorrent, instead, is a good example of a painless update process. (and yes it has it easy, having a small footprint to start and the main focus on downloading stuff)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.