[mistercow]

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.

[andymatuschak]

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.

[mistercow]

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.