npm run build:mac cannot package: ONNX Runtime 1.27.1 is built for macOS 14, the app's floor is 13

[EtienneLescot]

npm run build:mac fails at pack time on macOS, and has to be worked around to produce a build at all.

Refusing to package binaries that demand a newer macOS than the 13.0 floor
the app claims to support.

  - libonnxruntime.dylib is built for macOS 14.0.0 (floor 13.0)

The three pieces:

• scripts/fetch-onnxruntime.mjs:54 pins VERSION = "1.27.1".
• Microsoft's onnxruntime-osx-arm64-1.27.1 reports minos 14.0 (otool -l | grep minos).
• electron-builder.json5:123 declares "minimumSystemVersion": "13.0", and before-pack.cjs enforces it against every shipped binary.

The guard is right and should not be relaxed. Its own comment explains why, and cites #515: the deployment target decides which symbols the linker resolves against the OS rather than emitting locally, so a too-high floor strands users on the older OS with Symbol not found at dyld time — reported by users as something else entirely. A dylib built for 14 has no business in a package that claims 13.

This is not a warning today, it is a hard stop. I had to disarm the check locally to build the app at all, which is exactly the workaround the guard exists to prevent becoming habit.

Note the shipped 1.10.0 app carries no libonnxruntime.dylib at all, so this arrived with the segmentation work rather than being long-standing, and macOS CI evidently does not run electron-builder --mac.

Three ways out, in the order I would try them:

1. An ONNX Runtime build with a 13.0 floor. fetch-onnxruntime.mjs:15 warns the version is not free to move — crates/Cargo.toml pins ort with an api-NN feature — so this is a question of finding the newest 1.2x whose macOS artefact is built for 13, not of picking any version.
2. Raise mac.minimumSystemVersion to 14.0, and accept dropping macOS 13. That is a product decision, and it interacts with [[the STT floor]] — [Bug]: Not compatible with Monterey #515's history suggests it deserves care.
3. Stop shipping ONNX Runtime on macOS and let Segmenter::load fail as it already does when the library is absent (the module compiles without the segmentation feature and both entries fail cleanly). That costs webcam segmentation on macOS, which is presumably not the intent.

Whichever is chosen, it is worth asking why CI is green: if no job runs electron-builder --mac, then no macOS packaging regression can be caught before someone tries to cut a release.

[EtienneLescot]

There is no such version. I went looking for an ONNX Runtime the 13.0 floor would accept and checked every macOS arm64 release from 1.20 to 1.29, reading minos out of LC_BUILD_VERSION on the shipped libonnxruntime.<v>.dylib:

release	minos
1.20.0	13.3
1.22.0	13.3
1.23.0	13.4
1.24.4	14.0
1.25.0 / 1.25.1	14.0
1.26.0	14.0
1.27.0 / 1.27.1	14.0
1.28.0 / 1.28.2	14.0
1.29.0	14.0

Two things follow, and the second is the surprise.

The floor moved at 1.24 and has not come back. So no version satisfying ort's api-27 feature — which needs ONNX ≥ 1.27 — can pass the check, whatever else is done. Lowering api-NN does not rescue it either.

No release passes at all. Even 1.20, four years of releases back, is 13.3, and before-pack.cjs compares minOs > MAC_MIN_OS_FLOOR, so 13.3 > 13.0 is an offender too. A prebuilt ONNX Runtime has never satisfied a 13.0 floor. Whatever build produced the shipped 1.10.0 either predates the guard or predates ONNX being staged at all — the shipped app carries no libonnxruntime.dylib.

So the choice is not "which version", it is one of these:

1. Raise mac.minimumSystemVersion to 14.0. Simple, honest about what the app actually ships, and drops macOS 13 users. A product decision.

2. Build ONNX Runtime from source with -mmacosx-version-min=13.0. There is precedent — macOS already builds its ffmpeg from source, for licensing rather than floor reasons, and fetch-ffmpeg.mjs refuses to run on darwin for exactly that. ONNX Runtime is a far bigger build than ffmpeg, and it would have to be cached or vendored somewhere, so this is not a small commitment.

3. Stop shipping ONNX Runtime on macOS. Webcam segmentation goes away there.

4. A narrow, documented exception in before-pack.cjs for this one library. Worth considering only because its failure mode differs from the one the guard was built for: ort is wired load-dynamic, so the library is dlopened lazily by Segmenter::load, and a failure there is caught — pump_segmentation sets seg_failed, logs one line, and draws the webcam unsegmented. [Bug]: Not compatible with Monterey #515's helper was not like that: it was needed for a core feature and its absence surfaced to users as a denied permission. Here a macOS 13 user would lose segmentation and keep everything else.

   I have read that degradation path in the code but I cannot test it — this machine is on 26.5, and the claim that a symbol failure lands on the same graceful path as an absent file is inference, not measurement.

My reading: (1) or (4), and the choice between them is really "do we still support macOS 13 for everything, or for everything except segmentation". (2) is the only option that keeps both and it costs a build pipeline.

[EtienneLescot]

Cross-reference that bears directly on option (1). #538 records that on-device transcription was dead on macOS 13 and 14 in every shipped v1.10.0 build — fixed on main by the deployment-target pins in #527, but the point stands that macOS 13 has already been shipped to in a degraded state without it blocking a release.

That does not settle anything by itself, and it is not an argument for shipping a binary that demands 14 while claiming 13 — the guard is right about the failure mode. But it does mean the question is narrower than "do we drop macOS 13": that platform is already carrying known holes, and the cost of raising the floor should be weighed against how much of the app actually works there today rather than against the floor number in the config.

Worth having someone who knows the support policy answer that before anyone spends a day building ONNX Runtime from source for option (2).

[EtienneLescot]

Decision: build it in CI. Recording it here with what is done and what is still needed, because merging #595 does not by itself fix the blocker.

Why this option and not the other two

• Raise the floor to 14 would drop macOS 13, which is not an arbitrary number: it is what ScreenCaptureKit requires (ScreenCaptureRecorder is @available(macOS 13.0, *)), and it is repeated in README.md, website/docs/installation.md and Package.swift. LSMinimumSystemVersion makes LaunchServices refuse to open the app below it, so this is a hard drop, not a degradation.
• Stop shipping ONNX on macOS costs three of the five webcam background modes — transparent, blur, custom — and, as the code stands, costs them silently: RightPanes.tsx offers all four modes unconditionally, and a user would pick "blurred background", see nothing happen, and get no explanation.
• Build it keeps both, and turned out to be far cheaper than it looked.

What is measured, not estimated

step
shallow clone of the pinned tag + submodules	979 MB, 21 s
CMake configure	24 s
build, --parallel 4 on an M1	10 min
result	minos 13.0, arm64, 21.7 MB (upstream 36.7 MB)

The 15 MB difference is the CoreML execution provider, which this app does not use — segmentation.rs builds its session with no explicit provider, and webcam-segmentation.md records the CPU EP as a measured decision.

And it was exercised, not just inspected: the_whole_loop_produces_a_mask_from_compose_frame_alone — capture → inference → mask → composite — went from skipped to 1 passed with ORT_DYLIB_PATH pointed at the built library.

On the supply-chain question

The verification mechanism does not change: an immutable URL and a SHA-256 checked before the archive is opened, exactly as today. What changes is who built the bytes. #595 adds actions/attest-build-provenance on top, so the digest is no longer the only claim — the archive is bound to the commit, workflow and run, signed by GitHub, and verifiable with gh attestation verify.

One thing this does not give you, and it should be said plainly: the build is not byte-reproducible. Rebuilding the same tag will not produce the same archive — paths, timestamps and the image's compiler version all move. So a rebuild cannot serve as an integrity check; the model is "pin one artifact, verify its provenance once, never rebuild silently".

What still has to happen after #595 merges

Merging the workflow does not unblock npm run build:mac. The remaining steps are deliberately manual:

1. Run the workflow (workflow_dispatch).
2. gh attestation verify onnxruntime-osx-arm64-<v>.tgz --repo getopenscreen/openscreen.
3. Attach the archive to a release.
4. Paste the PINNED entry the job summary prints — including baseUrl — into scripts/fetch-onnxruntime.mjs.

Only then does the macOS payload satisfy before-pack.cjs. This issue should stay open until step 4 lands.

[github-actions]

Fixed by #599 and merged into main.

This change is assigned to the Next Release release milestone and is not necessarily available in the latest downloadable desktop release yet. It is currently marked as status: pending release until a packaged release containing it is published.