Hacker News Reader

Comment by cdubzzz | Hacker News Reader

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.

View on HN

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.

Thanks for your work on the project!

> I remember working with it in Quinn on Mac OS X like 10 or 15 years ago.

God, I still miss Quinn. For years after its official demise I still had a copy, which I kept playing, until the 32bitocalypse made that impossible.

I wish I’d kept the damn server code around somewhere. Lost to Internet history ):

Reply on news.ycombinator.com