Skip to content

CI: build the macOS app as a universal binary (x86_64 + arm64) (#51)#58

Merged
ryanbr merged 2 commits into
mainfrom
fix-macos-universal-binary
Jul 8, 2026
Merged

CI: build the macOS app as a universal binary (x86_64 + arm64) (#51)#58
ryanbr merged 2 commits into
mainfrom
fix-macos-universal-binary

Conversation

@ryanbr

@ryanbr ryanbr commented Jul 8, 2026

Copy link
Copy Markdown
Owner

Problem

The shipped macOS app is arm64-only and won't launch on Intel Macs. Confirmed against the released v8.3.4 zip:

NOOP Staging.app/Contents/MacOS/NOOP Staging: Mach-O 64-bit arm64 executable

No x86_64 slice anywhere in the bundle. (Reported in #51.)

Root cause

The macOS build used -destination 'platform=macOS', which on the Apple-Silicon runners resolves to the host arch and thins the binary. project.yml's ONLY_ACTIVE_ARCH: NO is set only under configs.Release, so the -configuration Debug build inherited the default YES → arm64-only.

Fix

Force a true universal build in all three macOS workflows (fork-release, fork-testing-build, app-build) with the generic destination + explicit archs:

-destination 'generic/platform=macOS' ARCHS="x86_64 arm64" ONLY_ACTIVE_ARCH=NO

These are command-line build settings that override the project config, so the configuration stays Debug and nothing else about the shipping build changes (same signing flags, same output path, same package step). Also added a lipo -archs guard to the release + testing jobs that fails the build if the binary isn't universal, so this can't silently regress again.

Verification

Dispatched a testing build off this branch; the new "Verify universal binary" step confirms x86_64 + arm64 (see run). The minimal-scope approach was chosen deliberately over a broader refactor — this is only the arch flags, no config/signing/bundle-name changes.

Fixes #51.

ryanbr added 2 commits July 8, 2026 12:53
The shipped macOS app was arm64-only and wouldn't launch on Intel Macs. The build
used `-destination 'platform=macOS'`, which on the Apple-Silicon runners resolves to
the host arch and thins the binary — project.yml's `ONLY_ACTIVE_ARCH: NO` only applies
under `configs.Release`, so the Debug build inherited the default YES. Confirmed
against the shipped v8.3.4 zip: `lipo`/`file` report arm64 only, no x86_64 slice.

Force a true universal build in all three workflows (release, testing, CI verify) with
the generic destination plus explicit `ARCHS="x86_64 arm64" ONLY_ACTIVE_ARCH=NO`. These
are command-line build settings that override the config, so the configuration stays
Debug and nothing else about the shipping build changes. Added a `lipo -archs` guard to
the release + testing jobs that fails the build if the binary isn't universal, so this
can't silently regress again.

Fixes #51.
…ts read)

The verify step used `defaults read $APP/Contents/Info CFBundleExecutable` to
locate the binary, which failed on the runner. Find the Mach-O executable directly
under Contents/MacOS instead (skipping dylibs) — no plist parsing, space-safe.
@ryanbr ryanbr merged commit 593ca50 into main Jul 8, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Not working on macOS with Intel processor

1 participant