andymatuschak.org: archive

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?

I just wanted to plug a couple of tools now available for automatic appcast creation.

The first is SparkleCaster, a Cocoa app by Adam Radestock. I’ve mentioned it on here before, but it’s made some progress—check it out and see if it fits your needs.

The second is new: a tutorial on using Rake to make appcasts. This is the kind of badassery that keeps me using Ruby.

Keep on rocking, folks! 1.5b2 soon.