Apple Silicon Universal Support

[lutzroeder]

Tracking Universal support from #5426.

See also electron/electron#26710 and electron/universal.

@mmaietta @quanglam2807 @elliottkember @devlar

[mmaietta]

Getting the universal package seems to work quite simply.

const universal = require('@electron/universal');
const path = require('path');

universal.makeUniversalApp({
  x64AppPath: path.resolve('./dist/artifacts/mac/Electron.app'),
  arm64AppPath: path.resolve('./dist/artifacts/mac-arm64/Electron.app'),
  outAppPath: path.resolve('./dist/artifacts/mac-universal/Electron.app'),
});

Native addons are spliced together into a "fat" file.

Two things I don't know yet:

• Do we need to resign the universal app?
• Where do we insert this in EB? macPackager.ts? Everything I've seen so far is heavily tied to an Arch mapped to Target(s). This location seems ideal but we need all the output directories provided, and we'd want to abstract the functionality back to macPackager as well I think.
  https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/packager.ts#L425-L441
  Any thoughts/input on where to start with incorporating makeUniversalApp from @electron/universal?

[lutzroeder]

@mmaietta @develar How would this be initiated at command line?

npx electron-builder --mac --x86 --arm64 won't work as it builds separate x64 and arm64 targets.

Would it make sense to add an Arch called --universal or --x64_arm64? The goal would be to avoid building multiple .dmg or .zip files or signing before the merged .app is created. Does building the executables exist as separate step?

Another issue would be rolling off universal in the future. Is it possible to build arm64 targets without a platform suffix once x64 is getting deprecated?

[mmaietta]

There's actually already an all available via the programmatic API, so I'd imagine we could reuse that here.
https://github.com/electron-userland/electron-builder/blob/master/test/src/mac/macPackagerTest.ts#L9

Universal apps still require an x64 and arm64 build. I think electron-updater may require those separate builds as well, as opposed to the larger initial universal binary, I honestly don't know because I don't use it. It would make sense though from a user-perspective as they should only need to be downloading an arch-specific package.

My plan is to just check if both mac x64 and arm64 builds are created, if so, also create a universal app. From my testing, the universal app "stitching" together took only a few seconds to complete, so the impact should be minimal. We just need to figure out the resign and an additional dmg/zip packing.

Another issue would be rolling off universal in the future. Is it possible to build arm64 targets without a platform suffix once x64 is getting deprecated?

There's no need to by default as we also want to maintain backward compatibility, you should just manually specify an artifactName template without the ${arch} and only build with an arm64 target.

[lutzroeder]

all gets expanded into --x86 --arm64 right away. It has a predefined meaning that is different from universal. For test, all would include x64, arm64 and universal.

My plan is to just check if both mac x64 and arm64 builds are created, if so, also create a universal app. From my testing, the universal app "stitching" together took only a few seconds to complete, so the impact should be minimal. We just need to figure out the resign and an additional dmg/zip packing.

The goal is to avoid signing the x86 and arm64 binaries if only the universal binaries need to be signed and deployed. Signing and notarization tends to be the most fragile part of a CI pipeline so it should be avoided unless necessary. doPack might have to split into doPack and doSignAfterPack with doPack having an option not to sign while building the temporary x86 and arm64 binaries.

The folder name for universal should be Foo-mac.zip so it gets picked up by updater. Since this is used for x64 currently there might be a mismatch. The goal would be to update from the current x64 bits to universal bits with the same name and in the future allowing to update from universal to arm64 bits with the same name. From the user perspective there is only Foo-mac.zip.

[lutzroeder]

There's no need to by default as we also want to maintain backward compatibility, you should just manually specify an artifactName template without the ${arch} and only build with an arm64 target.

@mmaietta is it possible to configure artifactName for macOS zip targets? Also, the dmg target will compute a different volume name including architecture, even if artifactName is specified.