ADR 0145: Publish Native macOS Intel Artifacts
- Status: Accepted (amended by D353, ADR 0191, D450 / ADR 0289)
- Date: 2026-09-01
- Deciders: PI-Desktop core
- Related: D126, D285, D353, D354, D450, ADR 0022, ADR 0191, ADR 0289, E2E-092
Context
The tag release workflow published only Apple Silicon macOS artifacts. The electron-builder configuration also pinned both macOS targets to arm64, so an Intel build could not be selected without changing the shared package configuration. The Rust host sidecar is packaged from the native target/release output, which makes a cross-compiled Electron package unsafe unless the sidecar architecture is independently managed and verified.
Decision
- The release matrix publishes two native macOS lanes:
macos-15for arm64 andmacos-15-intelfor x64. The workflow verifiesuname -mbefore preparing package inputs. - The static macOS electron-builder targets remain DMG and ZIP without a fixed
arch. The workflow passes the explicit matching--arm64or--x64flag to electron-builder. - Each macOS runner builds
pi-desktop-host-corelocally and packages that same native output. The local signed release script defaults to the host architecture and rejects aMAC_ARCHoverride that does not match it. - Each macOS job renames its generated
latest-mac.ymlbefore uploading. The publish job validates both feeds, merges their files, and publishes one combinedlatest-mac.ymlalongside both architectures' installers. - D353 originally gave the Intel x64 job target-specific artifact patterns, publishing
PI-Desktop-<version>-Intel.dmgandPI-Desktop-<version>-Intel-mac.zip, while arm64 kept generic names. ADR 0191 supersedes that suffix convention: both lanes now use their standard architecture labels,-arm64and-x64, with updater URLs and checksums generated from those final names. - macOS in-app update delivery is qualified separately by D450 / ADR 0289. This decision changes release artifact coverage and native packaging only; it does not change updater ownership.
Consequences
- Intel Mac users receive native DMG and ZIP artifacts from every tag release.
- The Rust host and Electron executable have a deterministic, matching architecture on both macOS lanes.
- Release publication needs one metadata merge step because electron-builder emits one macOS updater feed per architecture.
- Every macOS public download carries an explicit standard
arm64orx64marker, so neither architecture depends on a generic version-only name. - Intel package footprint and native launch qualification must be recorded separately from the existing arm64 baseline.
- A developer cannot use the signed local lane to cross-build the other macOS architecture without first moving to the matching native runner.
Alternatives considered
- Keep macOS arm64-only: rejected because Intel users remain unable to install a native release and the requested platform coverage is not met.
- Build Intel packages on an Apple Silicon runner: rejected because the Rust sidecar is produced from the host's native release target and could be mismatched with the Electron package.
- Publish separate updater feeds permanently: rejected because the current macOS delivery mode is notify-and-link and the GitHub Release should expose one macOS feed when a signed update channel becomes available.
Amendment (D450 / ADR 0289)
The merged latest-mac.yml now drives in-app macOS updates. Architecture coverage and native packaging in this ADR are unchanged.