What I don’t like about the current solution
Don’t interrupt me!
Sparkle asks whether you want to update the app when you start it. When someone opens his mouth, it’s not a good time to ask him something: he’s about to say something. Starting an app is the same.
Sparkle can also ask you whether you want to update the app when it’s running. That’s just plain rude: it could be interrupting the user’s thought process, especially as, IIRC, it causes the application’s icon to bounce if you’re using another app.
How am I supposed to know?
There is no way the user can know whether an upgrade will improve his experience, or waste time as he tries to recover his mistake. Asking can only make people feel stupid. Web Applications don’t ask. You get the upgrade, and you may not even notice.
Automatically upgrading software on other people’s computers could be a support nightmare, so it must be very easy to go back to where you were. Sparkle currently doesn’t provide a downgrade path.
Don’t make me wait!
Sparkle downloads the whole app on each update. For people on slower connections it’s noticeable and irritating. It would be better if the user didn’t notice it.
About 60% of my users seem to have disabled Sparkle. That’s a lot given that during the beta-test cycle, upgrades are not optional.
Updates are small bidirectional binary diffs (created using bsdiff for example) that are downloaded in the background. To minimize user visible lag, they could be downloaded in small sections.
By default upgrades are applied silently at application startup, but the user can require a confirmation step using the Application’s Preference Panel.
In built version selector
The Application’s Preference Panel easily lets users switch back to an older version. It shows the version information for each version that Sparkle currently only shows when checking for a new update. Because each downloaded upgrade is a bidirectional diff, one can always downgrade.
The Appcast Sparkle currently uses to inform the Application that an upgrade is available is enhanced so that a developer can correct an “Oops” by retracting a faulty upgrade. Adding this to the appcast protocol would be easy.
A small unchangeable harness is used to launch and monitor the App. If the app crashes on startup before the user could access the preference panel, it retracts any recent unproven upgrades and sends crash logs to the developer, after asking the user. Using a process to monitor another is extensively used for high reliability Telecom Systems: nine nines reliability (that’s 30ms downtime a year).
Growl and Email
If Growl is installed, it can be used to inform the user of the upgrade.
Generally however I think email is the most appropriate forum to inform the user of updates: one is more inclined to read information if one is not busy doing something else. Notice that even users who worry about providing their email addresses to the software developer can be catered for: the app itself can email the user with the information currently in the appcast when an upgrade has been downloaded.