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?
The Buzz {1 trackbacks/pingbacks}
The Conversation {19 comments}
As long as it prompts the user about whether or not s/he wants to quit when downloading and installing an update *cough*, sounds great!
But on a more serious note, would I be able to opt out of sparkle updates in my app? For instance, let’s say Sparkle introduced a model forcing DSA signing and I (for some reason beyond reason) decided I didn’t want to do that, wouldn’t a new Sparkle update effectively break my ability to update my app? I just imagine developers wanting more control over something that is linked so fundamentally to their applications. Unit tests against a single, static version are easy to perform but developers needing to update their app and test against Sparkle updates might spark some resistance.
We played the external framework game way back in the day and it was a pain. This approach sounds like it’ll cause the typical “DLL hell” where some install from app A can break app B.
Now, you could minimize this by making the ‘external thing’ an application or tool or something that doesn’t get loaded into my app’s address space. This reduces the problem space somewhat, to more of an API issue than a binary compatibility issue.
Why not just go all the way and have a single, self-updating Sparkle tool that the Framework just launches?
I’m not sure your idea can jive with the “Sparkle does not have its own branding” concept, btw. If something is going to be installing software (even self-updating) on a users computer, you should establish the identity of the author and the software so the user can make the appropriate trust decisions.
Yeah, this wouldn’t change that behavior. Sparkle does need a “install on quit” button very badly, though. I’ll try to get to that.
As for both of your concerns about versioning issues, OS X framework technology includes support for versioning (to guard against DLL hell and the like). So updates to Sparkle.framework which could break past versions would just add a new version to the framework bundle. Of course, I’d try to avoid doing this as much as possible, but storing 8 versions of Sparkle in ~/Library/Frameworks is better than 20+ versions in all the different apps.
It would be tricky to do that with branding and delegate support, but it’s something to consider.
I dunno. I could make it up to the devs conceivably, but so long as the software is a framework, it’s “dead” code. That is, it’s only executed by the host app, so if you trust the host app, you trust what it’s executing.
Maybe. I guess I’ll think about it more, but I don’t want to mess up the branding thing.
I don’t necessarily know that a full app is necessary (if you really need to go that route, a “updates powered by [Sparkle logo]” image on the update notice screen would work (if anything, it might actually drive adoption as some dunderheads still don’t know Sparkle exists)).
I guess my big concern is I can easily imagine someone not trusting you to declare an update of Sparkle as being “safe” to update to without testing on a per-app basis. Thinking of a worst case scenario, let’s say you accidentally merged in a branch that broke Sparkle self-updating, had too wild a time at a particular Apple sponsored developer conference, and shipped it as safe update. I don’t expect that that would ever happen but one benefit of per-app frameworks is that it could never break updating to all apps on the system.
Also: trust issues are why the web has this major advantage I’m trying to fix with Sparkle anyway. They might not know it, but 99.9% of people want to always be running the newest version, and totally invisibly. By a statistic I just made up, though.
Seriously, though, if I fix a bug or add a feature, I want that in everyone’s hands. If I mess up, that sucks, but I should be able to flip a switch and roll them all back. The web has it; the desktop should have it too.
You’re definitely right about the fear of updating bit. Apple is (rightly) terrified about making even benign code changes to SWU because it’s their lifeline.
Any updates to the Sparkle framework would need to undergo heavy peer review. I’d add a pref people could flip on to always be running the latest “testing” version of Sparkle against their apps. That’d help, but I don’t know if it’s enough.
I don’t know that I care enough to fix this issue. This is the wrong way to fix it. Solve software management, Apple! :(
Sort-of-on-topic-aside: I think SWU for Windows is the most widely-installed piece of Apple software. That’s hilarious.
SWU on Windows is also one of the apps I fear running on Windows, mainly because it usually means I need to re-remove Quicktime from the menu bar. It’s really amazing how stuff we
Oh yeah, since Adobe’s going Cocoa now - if you can get them to use Sparkle I can promise more free alcohol next year at WWDC than you could possibly imagine…
But Robert, Adobe Updater is enterprise-class and realizes synergies for their clients!
Seems like it can work. However, my concern is similar to that noted earlier. One of the awesome advantages of having Sparkle in the package is that developers have 100% complete control of the behavior of their individual app. It looks like the new concept might encroach on that, meaning the exact behavior of the app may change as Sparkle is updated.
Is separate frameworks such a bad thing? Honestly, I think the extra disk space is a non-issue relative to our drive sizes. The UI concern is more serious, and would be a very big deal in general. Sparkle though, has very little UI, so maybe this is not so important?
I agree with Gorbach. I like to have 100% control and like to have tested a framework update myself before it gets deployed to my users. Good thoughts but I like it just the way it is.
If by that, you mean causes them to flock to Adobe headquarters as a unified mob complete with torches, then yes - it’s aces.
Sounds like the risk and work outweighs the usefulness.
The main usefulness isn’t space on disk and so on—it’s mostly that I’ll fix bugs (potentially serious ones), and users won’t get those fixes.
Thanks for the feedback, guys.
Sparkle’s simplicity of distribution is precisely the reason number 1 of his success. In my opinion, your best bet is to help as much as you can developers to keep the framework up to date in their particular instance.
Keep up the good work Andy.
Exactly. Such as making more frequent releases ;) Really. I take care to include the latest *released* versions of frameworks used, but I’m not going to go down the “using latest bzr trunk sources” path, I can’t spend that much time testing everything in 3rd party frameworks.
This sounds like a social problem as much as, or more than, a technical one. If that’s true, then the main issue is making sure that the developers are informed.
Maybe the Sparkle distribution should recommend—via the website, docs, etc—that you subscribe to some pertinent RSS feed that announces Sparkle updates (and nothing else)? You could even include an UpdateSparkle app that would download the latest to a new location, if you felt so inclined…
Peter has it exactly right. We’ll update Sparkle if you release it. AFAIK, there hasn’t been an official release since 1.1. I’m not complaining about that — free software is a gift, not an entitlement. On the other hand, you can’t expect us to take bug fixes unless you include them in a release. We were thinking about including Sparkle 1.5b1 in Vienna 2.3, but then I discovered that 1.5b1 wasn’t localized yet, so it was a non-starter for us.
Thanks for the extra feedback, guys.
I’m definitely working on the “getting a new official release” thing going: believe me, I don’t want you releasing your apps on untested bzr source any more than you do.
Leave a Comment
You can follow any responses to this entry via its RSS comments feed. You can also leave a trackback if the inclination is there.