Taking appcasts to the next level

Appcasts are RSS feeds which make use of the <enclosure> tag which links to a binary file (usually a software package) somewhere on the internet. Sparkle, a library drop-in for Objective-C/Cocoa Mac OS X development, implements and expands this format to use it as transport description for application updates. With this, Sparkle makes it possible to automatically trigger application updates in a well-defined, consistent way. It downloads, unpacks and replaces the original binary and afterwards restarts the updated application.

I’m sure most of the Mac users out there have already seen it; many popular programs support self-updates through appcasts and Sparkle (hell, even guitone has an appcast after I managed to hack Sparkle support into this Qt project), it makes the whole process of updating non-Apple applications on a Mac so much easier and fun. With the advent of AppFresh, which aggregates all the registered appcasts from all locally installed applications and then updates them all-at-once, appcasts become an interesting idea for software distribution at a larger scale.

Now, GNU/Linux users will probably laugh at me when I tell them from this “superior” technique, because appcasting is a well-known technique in the free software world: A software update (if not automatically triggered) is usually done in the background by modern Linux distributions through yum or apt, with full support for version and dependency checking, mirror localisation and much more. Interestingly, these software distribution systems never made the jump to other operating systems – and yes, I know of MacPorts and Fink, but both are different story, because they distribute mostly GNU software.

There is one thing which distinguishs appcasts from GNU/Linux distribution systems, and this is rooted in the way software is developed on both platforms. GNU/Linux software projects usually just provide the sources, which are then build for the specific distribution and platform by so-called packagers. These packagers have not necessarily anything to do with the actual project. Because there are so many distros out there, a software gets quite a lot repackaged, even if some of these packages basically serve the same platform and architecture.

Mac OS X software (and Windows software as well) is usually distributed directly in binary form, ready to use for the defined platform. The “packager” role is here an internal role of the software creator and the distribution – if not done through the software creators home page – usually happens via big download sites like macupdate.com, cnet.com and others. All these websites are isolated “applications”, meaning that they use different internal data formats, are usually closed and don’t work together in most cases.

So, the new hype, not only in content creation branch, is syndication. And that is exactly what appcasts are about: Based on RSS 2.0 they provide a general format to describe software updates. Platforms like iusethis.com use the feed and provide additional services, f.e. a global “usage counter” for a particular software package. However the problem with the current appcast format pushed by Sparkle is, that it is itself an isolated application, because it can only provide “some package with some version to download somewhere” and includes no information about other platforms, architectures or download locations. This may be ok as long as you either have different appcasts for all these different platforms or only target one platform (in case of Sparkle Mac OS X).

But what if you create an application which should run on all major platforms? You certainly want to provide your users the same look’n’feel and features on all these platforms, and this is where my proposal drops in. My aim is to create a cross-platform format for software updates which is suitable to distribute update information for any platform through one single stream of information. Based on this format people could create those kind of library drop ins like Sparkle not only for Mac OS X, but for multi platform toolkits like Qt, wxWidgets, even for .NET. Software developers would then simply add those in their projects, provide the syndicated format on a webserver, and are done.

So again, what are the advantages here?

  • Based on the specification, an application update would “feel” the same on every platform, maybe with slightly differences between the different toolkit implementations
  • The syndicated format, which extends RSS 2.0, could serve as common content feed in any feedreader and, at the same time, transport the needed update information for the application drop ins
  • The feeds are decentralized published; the power is taken back to the software creator as he determines how he publishes his software
  • Other services similar to iusethis.com could arise which would provide social functionality around software updates, caching, mirroring and more

Of course the whole proposal would probably make most sense for Windows and Mac OS X software creators, since, as I already mentioned, distribution in the GNU/Linux world happens quite differently (and these people usually don’t like to build binaries themselves, they let packagers from the different distros do this work). But why should efforts like AutoPackage not be supported, if they’re interested? And I think commercial Linux software distributors would be interested in that as well, just because it would strengthen their relationship with their customers quite a lot.

What follows is a quick effort how such a format could look like. It currently doesn’t contain the RSS part, because I think you all know how this would look alike, I plan to put one <software> node into each <item> which would then stand for an invididual software release. Below the software node, the following tree would be expanded (which should be mostly self-explanatory):


Of course some concepts are stolen from Sparkle (f.e. hashs to check the data integrity of downloaded files), and one could put a lot more stuff in this. I once thought about adding support for “upgrade paths” into it, f.e. if a user skips a couple of versions, he should be notified if his current installation can be updated (using binary patches) or has to be upgraded (which requires a full installation), but I think bandwidth is cheap nowadays and it would make a first shot of this format and its implementation far too complex.

So, this is it, what do you think? I’d love to hear your feedback! I’m in contact with the developers of AppFresh and they signalled interest as well. Stay tuned for more news in the future!

6 thoughts on “Taking appcasts to the next level”

  1. Unfortunately I neither had the time nor the manpower to take further steps – however, in the meantime the Sparkle developer started development of Sparkle 2.0 which includes some of my and many other ideas and improvements:


    If they set their format in stone, one could certainly look into it more in detail and provide alternative implementations for it.

  2. Looks like Sparkle never made it to version 2 either. I’d love to do something similar to what you outlined here, but can’t find any schema standards. Sparkle is all very well, but the appcast RSS syntax isn’t documented properly nor is it cross-platform.

    Why are we trying to fit this inside an RSS data structure anyway?

    Did you make any progress in the last 4 years or find anyone else who did? The Sparkle2 link is also dead.

  3. Well, the reason why a RSS-based format was chosen back in the day was to make the new format also available for the gazillion of RSS readers for human consumption, while still being more meaningful for machine consumption.

    We’re now slowing moving into a world that provides isolated solutions for the software update problem anyways (see Mac App Store, see all the mobile App Stores, see the talked about Windows App Store), and these setups today provide much more than just a stream of updates to install.

    Also, I’m not sure if my original idea of the “unification” of the whole process is the right way to do it today – after all each platform has its own design guidelines, workflows, UIs, and so on, and people simply expect that something like this would be implemented deeply inside and in congruence with the rest of the system.

    So, to make the whole thing useful outside the developer world, we clearly have to define some new use cases about which Joe User actually cares.

  4. Good points Thomas. However a standardised application release document would be useful. For myself, I could make up any old thing to build into my application and it will work fine. But think how nice it would be for my data feed to be picked up by versiontracker, iusethis and all its friends.

    Sparkle has appcast as a sort of defacto standard and Adobe have developed their own variation on that: http://learn.adobe.com/wiki/display/ADCdocs/Adobe+Appcasting+Namespace+Extension And DOAP is another interesting take on this same idea, designed around open source projects.

    I assume (but haven’t found) that Android has some sort of application feed, given the number of Android ‘rate this app’ sites out there alongside the official market website. Or maybe there are lots of people scraping information from the official website?

    Imagine a world where the unix packaging and collection sites (such as http://freshports.org) could tie into upstream application feeds to link to release notes, release dates, and much more. CVE security notices could be added to each release (posthumously of course) and many tools could consume this information, aggregate it in different ways and provide useful tools for the end-user. Imagine if developers could implement this uniformly across Windows, OSX, Android, Unix and whatever else.

    Sparkle’s appcast is the closest we have to this overall goal. But given that your link to Sparkle2 is dead, it looks like Sparkle might be aiming at smaller OSX specific ideals these days. I raised an issue in their bug reporter to see if there is a discussion at Sparkle about the bigger picture: https://answers.launchpad.net/sparkle/+question/168644

    Right now, I’m not sure what to do about all this. My needs are small, and I hope that someone like the Sparkle devs who already have a large mindshare would be interested in picking up this baton. You or I might write a schema that was brilliant, but if nobody used it…

    Unless I get some response from Sparkle I will probably reinvent this wheel (or build on DOAP or Sparkle) for my own application needs. Then publish a blog entry somewhere, consigned to the history of sort-of-good ideas that never took hold.

    I don’t agree with you that unification is not desirable these days. Yes, there are a multitude of workflows and upgrade processes; but the application release data format is pretty much the same throughout.

Comments are closed.