4 ms·

For me, updates for apps distributed outside the store have been a surprising hurdle. On the surface, "just bundle an update framework and be done, right?" Sp

For me, updates for apps distributed outside the store have been a surprising hurdle. On the surface, "just bundle an update framework and be done, right?" Sparkle is great, but very complex--xml AppCasts, delta updates, fancy mukti-party signing etc... Not a workflow you can quickly set up. Squirrel (which Electron uses) is dead simple, but is absolutely ancient and basically unusable outside of Electron at this point. I seem to remember that the Electron project had some custom patches to keep it alive, but these weren't usable elsewhere. And with either of these, because it ships as part of your app you have to be very careful to never push a broken build. If you do, your users get terminally updated to a broken app that you can't update again. And never shipping a crashing build is easier said than done :) Are you really testing on every point release of the OS? Are you confident that you've tested all of the "magic" security behavior of macOS (the OS loves to insta-crash your app for these things) The inevitably of shipping a broken build is why big companies build update agents that run in the background and independently update (or roll back) the app, e.g. Dropbox. But to my knowledge none of these updaters are open source. Is the situation any better on Windows?

saurik 4y ago
It is at least somewhat better on Windows because you don't have anywhere near as much "magic security behavior" that "loves to insta-crash your app". That said, the de-facto standard of Sparkle doesn't exist on Windows, so it feels even more like utter chaos. (That said, I frankly have a hard time taking Sparkle seriously since they decided to drop support for old versions of macOS randomly.)
mike_hearn 4y ago
Yes it's a pain. I wrote Conveyor to automate it all - makes appcasts, signs, notarizes, uploads to the download site and all that for you (see my other comment for more info). "to my knowledge none of these updaters are open source." It's a bit better on other platforms. Omaha does this on Windows and is open source, but it's also abandoned. Google are rewriting it as Chromium Updater. Also Omaha's complexity makes Sparkle look like hello world. Conveyor makes MSIX packages for Windows and DEBs for Linux. MSIX is a bit like Omaha, there's a local agent that wakes up from time to time and updates apps on their behalf. There are bugs in it for older versions of Windows but Conveyor works around them. I wouldn't recommend trying to use it directly because it'll seem to work on your nice and up to date Windows but fail for people who aren't accepting online updates. However, when you get it stable, it's actually a really nice feature set. Sparkle has the ability to update apps independently, without being invoked by the app itself, via a command line tool. Currently Conveyor does invoke Sparkle from within the packaged app at startup as per usual, but moving to a dedicated background service would be a good improvement.
bobbylarrybobby 4y ago
Would it make sense to distribute two separate apps, the main app and an updater app, so that both would have to break in order for users to lose the ability to update? I'm thinking users would download the main app, which would download the updater, which would run in the background and keep the main app updated. Since the updater app would run independently a broken main app wouldn't prevent future updates unless it also broke the updater app somehow.
- FinnKuhn 4y ago
  Isn't this what companies like Adobe or JetBrains are already doing?
- iamcalledrob 4y ago
  Absolutely, but building this sort of thing is easier said than done, especially when it comes to security and sandboxing. This is one of the wonderful things about Sparkle—this stuff has been battle tested. They've done the work of finding which APIs actually work and handling all the edge cases. <rant> macOS's APIs in this area are a woeful mess of "deprecated, but the new APIs don't actually work". Sometimes the only way of reliably doing something is using Applescript... https://mjtsai.com/blog/2020/04/20/privileged-operations-on-macos/ https://mjtsai.com/blog/2020/04/20/privileged-operations-on-... </rant>
jbverschoor 4y ago
For me as the user, as I don’t like it when apps require too many permissions. Just distribute on the App Store, if possible, and maybe with less functionality

saurik 4y ago

It is at least somewhat better on Windows because you don't have anywhere near as much "magic security behavior" that "loves to insta-crash your app". That said, the de-facto standard of Sparkle doesn't exist on Windows, so it feels even more like utter chaos. (That said, I frankly have a hard time taking Sparkle seriously since they decided to drop support for old versions of macOS randomly.)

mike_hearn 4y ago

Yes it's a pain. I wrote Conveyor to automate it all - makes appcasts, signs, notarizes, uploads to the download site and all that for you (see my other comment for more info). "to my knowledge none of these updaters are open source." It's a bit better on other platforms. Omaha does this on Windows and is open source, but it's also abandoned. Google are rewriting it as Chromium Updater. Also Omaha's complexity makes Sparkle look like hello world. Conveyor makes MSIX packages for Windows and DEBs for Linux. MSIX is a bit like Omaha, there's a local agent that wakes up from time to time and updates apps on their behalf. There are bugs in it for older versions of Windows but Conveyor works around them. I wouldn't recommend trying to use it directly because it'll seem to work on your nice and up to date Windows but fail for people who aren't accepting online updates. However, when you get it stable, it's actually a really nice feature set. Sparkle has the ability to update apps independently, without being invoked by the app itself, via a command line tool. Currently Conveyor does invoke Sparkle from within the packaged app at startup as per usual, but moving to a dedicated background service would be a good improvement.

bobbylarrybobby 4y ago

Would it make sense to distribute two separate apps, the main app and an updater app, so that both would have to break in order for users to lose the ability to update? I'm thinking users would download the main app, which would download the updater, which would run in the background and keep the main app updated. Since the updater app would run independently a broken main app wouldn't prevent future updates unless it also broke the updater app somehow.

FinnKuhn 4y ago
Isn't this what companies like Adobe or JetBrains are already doing?
iamcalledrob 4y ago
Absolutely, but building this sort of thing is easier said than done, especially when it comes to security and sandboxing. This is one of the wonderful things about Sparkle—this stuff has been battle tested. They've done the work of finding which APIs actually work and handling all the edge cases. <rant> macOS's APIs in this area are a woeful mess of "deprecated, but the new APIs don't actually work". Sometimes the only way of reliably doing something is using Applescript... https://mjtsai.com/blog/2020/04/20/privileged-operations-on-macos/ https://mjtsai.com/blog/2020/04/20/privileged-operations-on-... </rant>

jbverschoor 4y ago

For me as the user, as I don’t like it when apps require too many permissions. Just distribute on the App Store, if possible, and maybe with less functionality