Build Arch64 Mac builds on M1 machines and prevent conflicts between outputted DMGs

[sergeichestakov]

Why

Currently, only one DMG gets published for both the Intel and Apple Silicon Mac builds. I also don't think it's guaranteed which one actually gets published since it's a bit of a last-write-wins situation which is not ideal. Instead, we should create two different DMGs (one for each arch) and differentiate them by name so that users on both types of devices can install via DMG instead of zip.

During this process, I also discovered that the default hosted macOS-latest machine is actually based on x64 architecture and does not support arch64 natively (for example, trying to download arm64 Node will fail). We've been passing the flag into pnpm make which does produce a build that works on M1s but it seems to cause some issues. For example, it uses an x64 version of Node rather than arm64 and inspecting the binary reveals that the application "kind" is labeled "Intel" rather than "Apple Silicon" or "Universal" as many other apps designed for the M1 do. This likely contributes to the lag and crashes that some users have been reporting.

Luckily, I discovered that GitHub just announced support for running GitHub actions on M1 Macs. It's in beta but is available to all and seems stable enough for our use case: https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/

What changed

Explicitly set different dmgPaths for each arch in DMG maker. This config field is undocumented but seems to work.

Additionally, run the build and publish workflows on the new M1 Mac runners (macOS-13-xlarge) when building for Apple Silicon (arm64) devices.

Test plan

• Should see build create two different DMGs with different file names (one for each arch).
• Should see M1 workflow successfully run make and use arch64 version of Node when building the artifacts.
• Will also try and play around with the new M1-built DMGs before we publish the next release to make sure things are working smoothly.

[szymonkaliski]

Oh wow great catch!

One thing that I wonder about is that Apple support "Universal Binaries" https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary -- basically having one executable which has both Apple Silicon and Intel code in it.
Quick googling found this https://github.com/electron/universal but I have no idea if it works/fits into our workflow. I think we should research this a bit (https://www.electron.build/configuration/mac.html also mentions universal binaries), as a follow up, and possibly clean this up. But for now we should ship this as it's a clear improvement over what we have.

[sergeichestakov]

oh wow that's what kind: Application (Universal) meant! Lots of apps I have installed locally are universal. That's a great find. I can look into that as well but looks like it does have some major binary size implications (seems to be roughly ~2x the size) which is a big tradeoff to make for a little more convenience on our side. Let's see how this works and then we can reevaluate.