I have been using Sparkle for a while now, and I’m quite fond of it. A few months ago I got rid of my semi-broken update system and adopted Sparkle.
Sparkle is usually described as an “application update framework.” It works like this: you plug it in your application, you tell it where to find the updates, and then your application will magically be able to update itself.
Sparkle does have its drawbacks, however. For example, imagine opening a chat application and being notified of an application update. If you choose to update, you’ll have to go offline again, virtually right after you finished signing in, which is just annoying.
Perhaps Sparkle could delay the update step and perform the update right before the application quits. This could happen completely in the background, without user interference.
It is also hard to use Sparkle for stuff like system preference panes, libraries, frameworks, system services, faceless applications, and more. It’s not impossible, but may require a customized Sparkle framework. User interaction would be flawed too: imagine a dialog box popping up asking you to update and relaunch some non-GUI application you didn’t even know was running.
So you can’t (or don’t want to) use Sparkle for the kind of stuff mentioned above. But there already is a system for updating software, and it’s aptly called “Software Update,” but it unfortunately does not supports third-party software.
What I’d like to see is an “Indie Software Update” (let me abbreviate that to ISU) which would work exactly like Software Update, but for third-party apps. Before I continue, let me make a list of the why’s and why not’s first:
Why?
- ISU would allow all applications to be upgraded at once
- ISU would be able to upgrade much more than just applications
- Having one >1MB Sparkle framework per application is a waste of space.
- No need to have per-application update preferences anymore
Why not?
- People are already using Sparkle, which works well enough
- ISU may be unsafe and/or exploitable
When installing a brand new application, ISU would be invoked like this:
- User opens a brand new application.
- The applications’ ISU framework tells the ISU daemon about itself.
- The ISU daemon stores the appcast URL and version number in its database.
Now, the ISU daemon can regularly perform update checks by fetching the appcast and comparing version numbers, just like Sparkle does.
In fact, ISU could reuse quite a bit of Sparkle code. Not the GUI, obviously, but the appcast parsing, update checking, and the actual application update code could be reused. Open source for the win. This probably also means that ISU probably won’t have more security issues than Sparkle.
Worth noting is that both the ISU and Sparkle frameworks need the appcast URL, and virtually nothing else. Therefore, with a bit of work, the ISU framework could have a tiny Sparkle framework compatibility layer; the ISU framework could then be a drop-in replacement for Sparkle.
I’m probably not going to implement this all (and definitely not now, since it’s only a very early idea). I’d rather spend time working on my existing projects and getting them released instead of starting new projects. Feel free to take my idea and turn it into something usable.
Last but not least: I’d like to point out that I don’t dislike Sparkle at all. It’s a great little framework which I’d like to take to the next level. That’s all! :)