andymatuschak.org: Sparklings

Sparkle 1.5b1 is imminent! If there are any tickets you really, really, really want closed, speak up now!

This is really just meant to tide people over until Sparkle 2, so I don’t want to do that much more work on it. My time is very unpleasantly limited.

A little birdy at Apple told me that my plan detailed in the previous post won’t work at all, since Software Update will (for obvious security reasons) refuse to install any update packages not signed by Apple.

Oh, well. Back to the drawing board!

Christopher Atlan has been committing some really useful patches to Sparkle trunk as of late. Among them are support for plugins, support for pkg and mpkg updates, and a couple nice bugfixes. Thanks, Chris!

Sparkle 2 Updates

I haven’t had a chance to actually code on Sparkle 2 (dohgod, Caltech’s killing me so hard), but I thought I’d update blog readers with what I’m thinking, vision-wise, since I haven’t had a chance to update the Conspiratory:

Lots of people in #macsb pointed out that they don’t want their apps asking users if they want to install some third-party crazy preference pane thing that requires authorization. This is understandable. I’m going to make Sparkle 2 a little friendlier than that.

First, there’s the developer side: Sparkle.framework, which contains all the core functionality: code to parse appcasts, to make the version poset, to check authenticity, and so on. Your app can use Sparkle.framework as before to just do updates completely within-app. No creepy install-y prompts.

Then there’s Sparkle, the user-focused thing (should it have some other name? or should Sparkle.framework?). When users install this, they start a localhost-only webserver on some obscure port that acts as the Software Update server for the real, bonafide Software Update.app. This doesn’t require any crazy SIMBL-hackery or anything: a simple preferences .plist setting specifies the host Apple SWU supposed to use to retrieve its update catalog.

So this webserver will serve up .sucatalog files (example) made from the union of the genuine Apple update catalog and a generated catalog of updates available for the apps on your computer. A daemon will update the webserver’s .sucatalog file every so often (daily-ish) by pinging all the appcasts.

A preference pane will switch the webserver on and off; users can switch back to the genuine Apple update server easily, so it shouldn’t be too scary.

And finally, like with Growl, developers can choose to call a quick method in Sparkle.framework that’ll offer to download + install the user-side Sparkle solution. Totally optional, opt-in.

There are some technical details to be worked out behind the software update proxy thing, but I’m pretty confident I can make it happen—this’ll offer the best solution to users, since it’ll be integrated into the interface they already know. There’s only one set of settings for updating, and no duplicated UI.

Not that this’ll actually happen until Caltech stops beating me up and taking my lunch money.

Okay, school’s had me really busy, so Sparkle 2 is still a long way off, but the problem is that there’s lots of known bugs in Sparkle 1.1—bugs that have been fixed! And there have been other improvements in trunk. Big ones include Panther compatibility, support for plugins, a much more graceful restart method, and support for DMGs in 10.4.9+ / Leopard.

So I think I want to do a Sparkle 1.2 release to tide people over until Sparkle 2 comes out: Sparkle 1.1 is really old, and everyone should be using trunk, but that’s scary, so people don’t.

I need my kind readers to check out the trunk version of Sparkle and test it with their apps: see if it works for your scheme! I think everything is still working great, but I want to be sure.

Exciting news: Adam Radestock has taken up the gauntlet for SparkleCaster and has a preliminary version available! You can get more information and download it here.

Status report!

Meanwhile, I’ve frankly gotten nothing done on Sparkle since classes began again. Schoolwork eats all time, and even when it doesn’t, it eats all energy. On the bright side, my course in discrete mathematics is coming in handy for the new branching system based on posets. I have a nice algorithm in mind for solving some special case releases.

One particularly mean test case I’ve been considering is that of Dave Watanabe’s Inquisitor. The path from 1.x to 2.0 was a paid upgrade, but 3.0 was free for everyone. Obviously, users of 1.x shouldn’t be prompted to pay for the upgrade to 2.0 before getting 3.0 for free. That’s tricky.

In another tricky case, imagine a developer who is preparing for a 2.0 launch. They give out 2.0 beta builds to a small group of testers and provide upgrades to those beta versions via Sparkle. The users in the main branch never see these updates because they’re not connected to this branch. But when 2.0 final comes out, the developer wants to give his testers a free upgrade as a way of saying thank you. The normal 1.x users, however, are expected to pay. Tricky. I think I’ve got it, though.

The other guys

Software update is a trickier thing than it should be. It’s a silly, small, tiny problem that really shouldn’t be occupying this much time or attention. But if you think I’m sweating the details, you should see Apple’s implementation.

They download and execute Javascript files like this one for each update available; the scripts provide functions the software update client can call to determine whether the update should be displayed and how it should be installed. If you ever wondered why the “checking for updates…” progress bar took so long, that’s why.

On another interesting note, it seems that the software update client can be configured to use another server’s URL. Like maybe localhost. Intriguing. A tiny webserver could be run on users’ machines to serve update catalogs to localhost, thereby providing a unified update interface for Apple’s updates and 3rd-party updates alike. I’ll have to investigate this further.