chanson

A ton of Mac OS X applications these days are using the excellent Sparkle framework — created by Andy Matuschak and maintained by many — to easily implement their own software update mechanism via Appcasting — essentially, syndicated applications. You just add Sparkle to your application, set a few keys in your Info.plist file, and create an RSS feed on your web server where each new entry has an enclosure with a new version of your application.

For what it was designed for, Sparkle works beautifully: It Just Works™ in a way that more software should, providing a very transparent user experience. If you're building Mac OS X software, I strongly recommend you leverage Sparkle for your software updates rather than writing your own update mechanism — regardless of whether you're a part-time indie developer or a multi-billion dollar company.

There's one downside to Sparkle, though: Its scalability, not on the server side, but on the end user's system. I currently have 23 applications in my Applications folder that embed the Sparkle framework. That's not a big deal; the framework is small and even if different applications embed different versions, they won't interfere with one another. The scalability problem comes with updating: I'm only asked to update an application when I run it. If I want to make sure all 23 applications are current, I need to launch each one!

It would be very cool if there were also an optional Sparkle Update Manager application or preferences pane that could be downloaded and installed, which could optionally centralize the update process. An application could check in with the Sparkle Update Manager if it's installed, and if this checkin is successful, all updating would happen via its embedded engine instead. This would have a few significant benefits:

1. It would make it possible to update all Sparkle-using applications with a single click. Just open the Sparkle Update Manager, click "Check for Updates," and any of your applications using Sparkle would be updated.
2. It would provide a single place to set preferences for application updates — whether to check for updates daily or weekly or only on-demand, whether to send system information with the update request, and so on.
3. It would make it easier to post security or other updates for Sparkle. If flaws or bugs are found in Sparkle, the update could be distributed in a "centralized" fashion that would take effect across a user's entire machine by simply updating the Sparkle Update Manager.

Overall, I think this would be very good for the Mac OS X user community, and not too hard to implement.

There's also already a model that Sparkle can follow for this: The Growl notification framework. You can build an application that has basic Growl functionality by just embedding it in your application and calling its API. Or you can install the Growl distribution and get a whole bunch of additional features, such as control over the style and behavior of notifications from different applications, selective enabling of application Growl support, and so on. I think it provides a great model for third-party frameworks that add behavior to multiple applications to follow.

Dave Winer has been working on something called codecasting that looks a lot like Fraser Speirs' Appcasting idea.

Quite a few applications on Mac OS X deliver their updates via appcasts. It's actually really taken off, thanks especially to Andy Matuschak's great Open Source Sparkle framework.

I wonder if this is something else that Dave's going to start taking credit for. You know, like blogging and XML-based syndication.