When building a Windows Electron app on Apple Silicon macOS, electron-builder --win defaults to the host architecture — so running:
|
produces arm64 Windows binaries instead of the expected x64.
The Fix
Force x64 explicitly with the --x64 flag when invoking the package command:
|
Or call electron-builder directly:
|
This produces the standard NSIS x64 artifacts:
|
To pin a specific version (e.g. 1.14.42), set the OPENCODE_VERSION env var before the build:
|
Follow-up: Native Module Mismatch
After building with --x64, the .exe may launch but crash with:
|
Root cause: bun run build resolves native modules (e.g. @lydell/node-pty) based on the host platform and architecture — darwin-arm64 — rather than the target win32-x64. The bundle ends up importing the macOS native binding, which fails when the Windows .exe tries to load it at runtime.
The Fix
Set RUST_TARGET=x86_64-pc-windows-msvc so the build step selects the correct native bindings for the target platform:
|
Verify
After the build, confirm the main bundle imports the correct platform binding:
|
And check the packaged app.asar includes the right native module:
|
TL;DR for cross-building on macOS
Both env vars are needed together for a working Windows build:
|
Without RUST_TARGET, you get a working .exe installer but a broken main process that can't find its native modules.
Caveat: Code Signing
The .exe built on macOS will not be Windows-code-signed. Electron-builder's signing routines typically gate on process.platform === "win32" (and often GITHUB_ACTIONS === "true"), so they intentionally skip signing on macOS. If you need a signed Windows release artifact, you must either build and sign on a Windows machine or add a macOS-compatible signing path to your config.