It'd be nice if Sparkle could move the app to ~/Applications or /Applications for the user

[mikehearn]

App Translocation is a pain, it breaks updates and requires the user to do things with the finder they might not know how to do. Especially if you want to distribute apps as zips and skip the slow/heavy/annoying DMG mount and unmount process, the UX is better except for lacking the hint of how to move the app. It'd be nicer if the app could do this itself. The LetsMove framework does this but it's no longer working properly in the latest macOS and it'd be nicer if Sparkle did it out of the box. Moving to /Applications is nice if possible but if the user isn't an admin, moving to ~/Applications also works and is recognized by macOS as equally valid.

What are your thoughts? It doesn't feel that hard to implement - maybe the hard part is getting the right UX.

[zorgiepoo]

This was last discussed in #1012

I think installing a new app update to /Applications is a better idea and more in scope with Sparkle (I don’t like apps asking me to move them when I try them out).

But it’s confusing since we’re no longer just replacing an app bundle and can’t remove the old bundle, allowing users to still use it.

Then there are some potential edge cases and details on implementing it correctly.

Overall still not a big fan. I am not familiar with any recent macOS changes that affect LetsMove so I am curious what those are (unless it’s just issues based on a fragile implementation).

[zorgiepoo]

That's true, albeit I don't think it has any negative impact on app translocation. If I understand the rationale correctly the goal is to fix old apps that open files next to the bundle and which can also be tricked or hacked into being malicious. So if the user downloaded an archive consisting of the signed but buggy app, placed next to the malicious input, then the app would do the wrong thing and code signing would be subverted. Translocation prevents the app from finding any files that are next to its bundle. But the vast majority of bundles don't open files from locations next to them like that, so for those apps, it's pure downside. Feels like Apple should have allowed apps to opt-out of this with a Info.plist key and not only with a signed DMG. Ah well.

This may be true (or missing a detail somewhere) but the bummer is that there aren't good supported methods of locating or removing the old app, just hacks.

LZMA is attractive but would make mounting/loading even slower, presumably? Which is better really depends on the speed of the internet connection. I'm lucky and have a fast link albeit it's getting pretty normal in the country where I live (gigabit), and in that case it can be slower to mount a DMG and copy the app out of it than to actually download it in the first place. I guess LZFSE might fix that.

This is true there is a tradeoff but in my experience I've often seen LZMA win out on the savings vs decompression speed. We switched our delta updates to default to LZMA rather than bzip2 (which LZMA turned out to be much better and bzip2 is in this legacy/deprecated territory now). For example for my ~65 MB app, my app compresses to ~13 MB lzma dmg vs ~20 MB zip file but the difference in mounting or unzipping and dragging the app to Applications using Finder is not that perceivable to me. For larger apps, a number of developers do care about download size and would be happy shipping a e.g. 180 MB update over a 240 MB one with the decompression speed tradeoff. Depending on your app if decompression speed is more favorable, then LZFSE may be slightly better than zip (although it might not be significant enough to write about). (Another thing though is that apfs / lzma disk images require 10.15+ so have a bit steeper compatibility requirements, but in a few years that will water down and apfs / lzfse (10.13+) ones do for now..)

[mikehearn]

Thanks for the discussion interesting and insightful discussion!

[zorgiepoo]

@mikehearn Fyi, for your interest I wrote about creating modern Mac disk images recently (and contributed to several of the dmg-creation software).

I also came across your article comparing binary delta methods which was very neat! For clarification with Sparkle we use lzma nowadays instead of bzip2 and don't compress bsdiff resulted patches on an individual basis (which you already figured).

We also looked at zstd briefly, but found it to be a mixed bag [1] [2] despite it being promoted to be better than bsdiff.

[mikehearn]

Thanks for the info! I think the reason the zstd team claim better results than what you found is that they were doing deltas for source tarballs, but Sparkle is used with binaries. Binary delta efficiency for executable native code is very heavily affected by how well you can patch internal pointers and bsdiff has a design that accomodates that whereas zstd probably doesn't. What would work well is zstd+something like Courgette.

Your article about modern disk images is good. We still produce zips but may look at DMGs in future.

[zorgiepoo]

Yeah there are some efficiency/reliability downsides with trying to programmatically extract DMG files but it's preferred by many developers for website distribution so it's tough to beat that aspect. And many developers don't want to ship different archives for updates vs website distribution. (Then again zip and tar have their own downsides too as being reliable formats)

Another note that for Sparkle's format, Clone's are also an optimization (original format didn't support it). It's our way of detecting files in the new bundle are similar to files in the old bundle at a different relative-path location using some basic heuristics..