macOS auto-update without extra zip file

[develar]

There is no any reason to require ZIP file. DMG should be enough.

Stay tuned — delta updates using DMG files are coming next week :)

[Ajeey]

Will it matter if I have installed my app via pkg?

[develar]

You can ask us to support pkg but... #1728 (comment) Depends on user demand / donation.

[develar]

To make clear — when this feature will be implemented, it will be very easy to support virtually any format, including pkg. Not because our position about DMG is changed, but because of backward compatibility (need to support both zip and DMG, so, old clients will be able to update).

[farfromrefug]

@develar i think this feature has broken zip auto update. Right now i am building my app with only zip on mac, and since this my latest.yml is not generated anymore
I pinpointed the issue to come from here:

electron-builder/packages/electron-builder/src/macPackager.ts

Line 68 in 58179b7

mapper(name, outDir => new ArchiveTarget(name, outDir, this, targets.some(it => it === "dmg") && (electronUpdaterCompatibility == null || semver.satisfies("2.16.0", electronUpdaterCompatibility))))

The ArchiveTarget is called with isWriteUpdateInfo to false, so my latest.yml is not generated anymore

[develar]

@farfromrefug By intention. If you need auto-update on macOS, you build both dmg and zip. Why do you build only zip and not dmg?

[farfromrefug]

Because i dont need dmg :D What's hard is that you broke support for it while it was there.
Also as i only use zip for now (even thinking about 7z to get smaller) building dmg and zip makes the build longer...

Now i am not against switching to dmg! But does it mean i can only use dmg ,and update files will still be built ? If so, do the distrib updater my clients have within their app already know how to install dmg updates?

Thanks

[develar]

I was not aware about such use case. Fix will be today evening CET (better if you will duplicate your comment as a new issue).

[farfromrefug]

@develar no problem, thanks for fixing this
Will create a new issue about the dmg thing

[XuluWarrior]

What is the current status of this issue?
I see a number of WIP commits from about a month ago but I get "Unhandled rejection Error: ZIP file not provided" when running against GitHub release with a DMG but no ZIP file.

[ilyaLibin]

Hi @develar
Are there any updates on that issue? Getting the same error.
Unhandled rejection Error: ZIP file not provided

[mark-buer]

Adding the following to my electron builder config allowed me to proceed:

mac:
  electronUpdaterCompatibility: '>=2.15'
win:
  electronUpdaterCompatibility: '>=2.15'

[develar]

Feature is not implemented yet. zip is still required for macOS auto-updates.

[damianobarbati]

Same as @ilyaLibin. Any update on this?

[brunolemos]

Bumping this issue, I see no reason to have both .zip and .dmg for users to download. I'd like to keep only .dmg so they can easily drag to Applications.

[vladimiry]

Friendly ping from my side :)

[mmaietta]

@acnebs I'm happy to review any PR.
It's relatively simple to get a local dev env set up too 🙂
https://github.com/electron-userland/electron-builder/blob/master/CONTRIBUTING.md#to-setup-a-local-dev-environment

[lidel]

This is extremely frustrating to realize that disabling zip package format will break autoupdates in dmg.
I've updated docs in #6496 to save other folks from that fate.

[taratatach]

@lidel's warning was removed from the doc by the very next release… Could we get this back into the documentation as nothing warns us about the necessity of generating the zip file?
I created a new PR to bring back the warning into the doc: #7188

[Julusian]

This was bugging me, so I spent a couple of hours looking into how this could be implemented.

The builtin autoUpdater being leveraged requires the app to be in a zip file. There is no way around this without deep code changes there.

So I have 2 ideas on how to proceed. I have not been considering differential downloads.

The hacky way

It would be entirely possible for electron-updater to:

1. download the dmg
2. silently mount the dmg hdiutil attach some-dmg-file.dmg -mountpoint /tmp/some-path -noverify -nobrowse -noautoopen
3. find the app inside the dmg and zip it
4. unmount the dmg
5. serve the newly created zip to the tool

This will be rather inefficient on cpu and storage as it will be asking every user to create the zip file themselves.

The more changes way

From skimming the code, I see no obvious reason (I have never read objective-c before, so I could be missing things) that the builtin auto-updater couldn't be modified to allow electron-updater to pass it the path to an app file on disk that it should update to. If electron were to expose the verifyAndPrepareUpdate method from the updater in a safe way for election-updater to be able to invoke instead of setting a feed url, then we could do the following:

1. download the dmg
2. silently mount the dmg hdiutil attach some-dmg-file.dmg -mountpoint /tmp/some-path -noverify -nobrowse -noautoopen
3. call this verifyAndPrepareUpdate of the updater
4. call quitAndInstall (if not forced by verifyAndPrepareUpdate)
5. after launching, check for the previously mounted dmg and unmount it.

Alternatively, instead of asking electron to accept the change to expose verifyAndPrepareUpdate, it would probably be possible for electron-updater to package enough of squirrel.mac to make this work. That will likely be a bit of a pain and will have a maintenance burden

[mmaietta]

So I've also investigated this in the past and the problem is that the .dmg contains a .app and not a .zip. What this requires is that in order to serve the update to electron's built-in autoUpdater (which is really all electron-builder's electron-updater package is doing specifically for MacOS), I tried to locally zip the .app to the updater cache dir and then serve it to electron's auto-updater. IIRC, this failed due to signature mismatch.

AFAIK, there's no way to get around the zip-enforced update process without manually copy-overwriting the previous .app with the new update, ignoring electron's autoUpdater implementation. This unfortunately completely bypasses electron's built-in signature validation of the update file, so that's a no-go.

Honestly, I'm not sure how to proceed with this given the limitations above and verifyAndPrepareUpdate not being publicly available.

[Julusian]

Honestly, I'm not sure how to proceed with this given the limitations above and verifyAndPrepareUpdate not being publicly available.

I think it depends on if someone is willing to try and get that exposed in electron, and if electron is open to accepting that change.
I might give it a try, but I am not sure yet.

But I am worrying that improving this could end up causing more pain for end users.
Existing projects won't be able to stop producing zip builds until they are confident that all their users are running a version of their app with the dmg compatible updater. Trying to do so if they aren't will result in their software offering an update and then failing to install the update with an error ZIP file not provided:.
It would be a trivial fix to change that error message going forward to be a bit more user friendly, something like No compatible update asset was found, which would improve the situation a little but not massively.

[Julusian]

@mmaietta I took a proper look at this last night, and have a custom build of electron that seems to be working.
I've opened a draft PR to electron to start a discussion on whether they are open to accepting the change electron/electron#45406

[mmaietta]

Thank you, I'll subscribe to that PR and see how the convo goes!