andymatuschak.org: Sparklings

Somehow, a critical comma slipped out of 1.5b3 which prevented non-.dmgs from being extracted properly. Please update to 1.5b4 to fix that problem.

Sorry about that, folks.

I’m working on some major refactorings to enable Sparkle to work for updating multiple bundles at once, but that’ll take a while, and some rather important bugs have been fixed since 1.5b2. In the spirit of releasing more frequently, I give you 1.5b3. If you’ve released an app with b2, I recommend upgrading as soon as you can.

• Added a new delegate method to SUUpdater.h to allow delegates to specify custom version comparators.
• Added a German localization, courtesy the Camino localizer team: Dominik T., Tobias Stohr, and Friedemann Bochow.
• Bug fixes:
  • Fixed a serious bug which could cause a server to be DDoS’d (or the host app to crash!) if an appcast fails to be parsed.
  • Fixed .tbz extraction if the archive was made with Stuffit.
  • Fixed support for .tar.bz2 and .tar.gz; Sparkle has to assume the archive is a tar when it sees “bz2″ and “gz”; don’t use those without tarring.
  • Fixed a typo which caused the shouldPromptForPermissionToCheckForUpdatesToHostBundle: method to not work in 1.5b2.
  • Fixed .zip extraction on Tiger (Apple changed the UTI between releases)
  • Fixed a crasher on Tiger.
  • Fixed display of the default app icon when the host app doesn’t have an icon.
  • Sparkle now displays a sensible progress string and uses an indeterminate progress bar when the server doesn’t report a file size.
  • Fixed some memory leaks.

Alright folks, it’s been a few weeks, and we’ve gotten a ton of bugs hammered out. If you’re using 1.5b1, you should absolutely upgrade to b2, as a number of somewhat critical bugs have been fixed.

As of this writing, there are no known bugs (other than Sparkle being bigger than I want it to be), so please let me know if you find something amiss.

Still no documentation yet, but now that the bugs are closed, I’ll get on that.

What’s New?

• Compatibility Issues:
  • Most of the delegate method selectors have changed to scale better. See SUUpdater.h for changes; you’ll likely have to make changes if you implement any delegate methods.
  • If you’re using .tar.gz or .tar.bz2 archives, name them “.tbz” or “.tgz” instead; Sparkle now uses UTIs for archive detection, and it’s not smart about double extensions.
  • I’m no longer supporting 10.3. This may or may not work on Panther—probably not.
  • Sparkle’s no longer built for ppc64 by default. If you want to ship that, feel free to build your own, but this saves a few hundred k.
• Enhancements:
  • Sparkle now detects if the preferences for automatic update checks or the time interval change mid-cycle. If your product is a non-.app, you need to clue Sparkle in on the change by calling [[SUUpdater sharedUpdater] updatePreferencesChanged].
  • Added a cancel to the “checking for updates…” dialog.
  • Sparkle now cleans up all its litter in /tmp.
  • Made SUUpdater's delegate an IBOutlet so you can hook it up in Interface Builder.
• Bug fixes:
  • Sparkle no longer crashes on non-GC hosts when the user cancels an update’s downloads.
  • Sparkle no longer gets stuck in an inconsistent state or crashes when it can’t parse the appcast on scheduled updates.
  • Added the sharedUpdater method to SUUpdater, as it should have been.
  • Fixed a bug where the “checking for updates…” window wouldn’t go away if an error occurs while checking for updates.
  • Made the dual-mode build configuration actually use the .xcconfig which builds it with GC support. (oops!)
  • Fixed relaunching for prefpanes.
  • Sparkle no longer fails to install updates on Snow Leopard (though there’s still an issue with trashing the old version of the app, but it seems to be a 10.6 bug)
  • Sparkle now handles redirects correctly under Tiger.
  • Fixed the installation path for non-.app bundles.
  • Fixed a bug which could crash Sparkle under non-English locales.
  • Fixed a weird race condition which could cause the relaunch tool to never notice that its target relaunched.
  • Fixed a bug where if the host app is inactive when an update occurs, the update alert sometimes doesn’t become key.
  • Minor textual fixes.
• Localizations:
  • Dutch, courtesy Maarten Van Coile
  • French, courtesy Yann Ricquebourg
  • Spanish, courtesy Ernesto Gomez Cereijo

Okay, so it’s sounding like the risk and work involved in my last proposal outweigh the benefits.

I don’t want to spend a ton of time doing crazy things for Sparkle, anyway—I want to solve the software management problem correctly. Hrm.

On the bright side, 1.5b2 tomorrow, probably.

Sparkle is the wrong way to do software updates. This is for many reasons, but one of the big ones is that we’ve got tons of copies of Sparkle running around the system, some potentially very outdated.

Even without security issues, it’s silly to have some apps presenting new Sparkle interface and some apps not. And Snow Leopard compatibility weighs heavy on my mind.

I’ve said this whole time that really solving this problem is not something third-party developers can do. Software update is a small part of the larger software management problem, and I don’t think it can be solved outside of Cupertino.

This might help, though.

The Big Idea

Apps which use Sparkle would ship with a Sparkle stub framework. This would be comparatively small and hopefully require only rare changes.

After it asks “do you want to check for updates?” the stub framework checks to ensure the full Sparkle framework is installed and up to date (by fetching an appcast from my server). If either criterion is unfulfilled, it’ll fetch the latest Sparkle.framework and install it in ~/Library/Frameworks (so as to avoid authentication).

Then it’ll load the framework from that path and proceed as usual, checking for updates to the system framework perhaps once a week. I envision appcasts specifying that they require a particular version of Sparkle for non-compatible new features.

Obviously, there are a lot of issues and cases to take into account (including the fact that I’m not sure I want to do this much work), but I think this is the best solution for the immediate future.

Thoughts?