It's cool Sparkle is still around and offering an alternative for app updates. I remember working with it in Quinn on Mac OS X like 10 or 15 years ago.
I have to say—it's a bit unsettling to me! I released it in 2006; I was a teenager. Obviously, it's evolved since then, and others have taken responsibility for it, but the interface is still the same. I regret that: I didn't know anything about design when I was a teenager. It's not at all graceful. Serves me right, I guess, that I'm now confronted with that poor interface regularly as an adult.
If it’s any consolation, every time I see the Sparkle update UI it reminds me of a much better overall Mac UX and makes me glad some semblance of it still exists. I could certainly critique the design in some ways, but I think it was quite good at providing a consistent upgrade mechanism across the whole ecosystem at the time, and it still has some distinct advantages over the multitude of equivalents that exist today, across MAS and Chrome-style background updates and the kitchen soup of Electron. Even if the interface could be improved, its consistency over so many years is a testament to how well it already solved the problems it addressed. If I could, I’d go back to the de facto standard of Sparkle updates to native Mac apps in a heartbeat.
Interesting. I'm curious what you don't like about the interface in retrospect. I remember being a young shareware dev, seeing that UI and thinking "this is so much better than the bespoke updaters people keep writing". Sparkle ended up being one of the few third party frameworks that I didn't end up stubbornly rolling my own version of, because it just did exactly what I wanted.
Thanks for the kind note. Lots of problems, but my central criticism would be: this is an interface which modally interrupts the user and requests a blocking operation, exactly when the user has indicated intent to perform a task in the app (i.e. when launching it or focusing it).
A better solution in most cases would be to integrate some kind of "update available" affordance into the window chrome, as many interfaces now do. And (with user consent) most apps should simply update themselves when they are not in active use. That is (again, with user consent), desktop apps should simply behave like SaaS apps.
Oh yeah, that’s a very good point. It’s sort of mitigated by the fact that to this day, app launching is a pretty bad experience across the board. It’s just the norm for apps to do annoying things on startup that violate user intent, take focus away, etc. So in a regime where you already have to assume that apps need time to “settle” before you can interact with them (or in fact, before you can reliably interact with anything), modal updates actually don’t make things much worse.
To be honest, I didn't realize it wasn't a native Mac thing until just now. I have always found it to be low friction and just part of the Mac experience, it never occurred to me it was third party.
At least for me, you've certain done it better than almost any other updater.
Sparkle is great. We use it in the Conveyor packaging tool to supply the Mac update implementation for apps, and automatically integrate it into apps without needing them to do any code changes (using a mix of code injection and other techniques). It's definitely one of the more robust and well featured update engines out there.
Actually we use a fork of Sparkle that adds support for forced updates on start, which is useful for apps that need to stay in sync with a rapidly changing server protocol. It gives you a more web-like approach.
I use Sparkle on all the Mac apps I work on and always found the setup docs somewhat convoluted so happy to see this.
A couple years ago I built https://replay.software/bump to automate into the cloud the entire Sparkle process, and it's made it much more idiot-proof to create the changelog, do signing and release.
