feat: macOS universal binary instead of separate x64/arm64 builds

[ewrogers]

Summary

• Replaces the two separate macOS build matrix entries (macOS arm64 on macos-14 + macOS x64 on macos-15-intel) with a single universal binary build (arch: universal on macos-14)
• Removes the latest-mac.yml rename workaround in the asset collection step
• Removes the "Merge macOS updater manifests" step and its dependency on scripts/merge-mac-update-manifests.ts

How it works

No build script changes are needed — the existing scripts/build-desktop-artifact.ts already supports universal as a valid arch value:

• BuildArch is defined as Schema.Literals(["arm64", "x64", "universal"]) (line 21)
• The macOS platform config explicitly allows ["arm64", "x64", "universal"] (lines 50-64)
• The arch is passed to electron-builder as --universal (line 694), which electron-builder natively understands — it builds both x86_64 and arm64 slices, then uses @electron/universal (which wraps lipo) to merge them into a single fat binary automatically

This PR only changes the workflow YAML to pass universal instead of running two separate arch-specific jobs.

Benefits

Simpler release pipeline

The workflow drops from 4 matrix jobs to 3. The macOS-specific manifest merging logic (merge-mac-update-manifests.ts, the latest-mac-x64.yml rename) is eliminated entirely — fewer moving parts, fewer places for the release to break.

Better user experience

Users download a single .dmg that works on both Intel and Apple Silicon Macs. No more choosing the wrong architecture, no confusion between two macOS downloads on the releases page.

Simpler auto-update

With one universal build, electron-builder produces a single latest-mac.yml manifest that covers both architectures. No need to merge two separate manifests at release time.

Reduced CI cost

One macOS runner instead of two per release. Apple Silicon runners (macos-14) can natively build universal binaries via lipo, so no cross-compilation is needed.

Trade-offs

• The universal .dmg will be roughly 2x the size of a single-arch DMG since it bundles both x86_64 and arm64 slices. This is standard practice (e.g. VS Code, Chrome, Discord all ship universal binaries).
• The single build job may take slightly longer than either individual arch build, but total wall-clock time decreases since the two jobs no longer run (and the merge step is gone).

Test plan

• Trigger a workflow_dispatch release on the fork and verify the universal .dmg is produced
• Verify the .dmg runs natively on both Apple Silicon and Intel Macs
• Confirm latest-mac.yml is published without needing the merge script
• Confirm auto-update works on both architectures

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: c9a92a01-7b98-402f-b47d-238f63203f2a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Tip

CodeRabbit can enforce grammar and style rules using `languagetool`.

Configure the reviews.tools.languagetool setting to enable/disable rules and categories. Refer to the LanguageTool Community to learn more.

[tduarte]

I'm not sure if I agree this is better user-experience. Especially on Macs where storage is so costly, I can't see the benefit in using the space in my system for code that doesn't run on my platform.

The better user experience in this case is to automatically identify the platform on the public website, and link to the proper DMG for each user.

[ewrogers]

Fair point, it's just a different angle of user-experience. The extra (doubled) disk space is a negative, but not needing to worry about which architecture you have is a plus. Granted this is developer focused so perhaps a non-issue on the latter.

Electron apps aren't lightweight so I suppose 250MB versus 130MB is not ideal. Then again x86 for macOS is on the tail end with each generation of the M-series chips.