Summary
Every installed v1.10.0 build has broken on-device transcription on macOS 13 (Ventura) and 14 (Sonoma) — including macOS 14, the version the README recommends. The STT helper does not fail: it never loads.
Fixed on main by the deployment-target pins in #527, so builds cut after that are fine. Nothing fixes the installs already out there, which is why this is worth a line in the next release notes rather than a silent close.
What the user sees
The captions pane says "Failed to fetch". That reads as a network problem and sends you looking at the STT server, which was never the issue — the helper process died in the loader before it could answer. (Noted independently in the manual E2E log for a different cause; the message is misleading in both.)
Evidence
Run on a macos-14 GitHub runner, macOS 14.8.7, arm64 — the shipped Openscreen-Mac-arm64-1.10.0.zip, unmodified:
$ ./whisper-stt-server --help
exit=134
dyld[2088]: Symbol not found: _OBJC_CLASS_$_MTLResidencySetDescriptor
Referenced from: .../electron/native/bin/darwin-arm64/libggml-metal.0.dylib
(built for macOS 26.0 which is newer than running OS)
The same source rebuilt from main, with the pin, on the same runner:
minos 13.0 sdk 14.5
$ ./whisper-stt-server --help
FATAL: --model <path-to-ggml.bin> or OPENSCREEN_WHISPER_MODEL is required
i.e. it loads and runs.
Cause
scripts/build-whisper-stt.sh set no CMAKE_OSX_DEPLOYMENT_TARGET, so CMake defaulted to the build machine's SDK and the shipped dylibs were stamped minos 26.0. MTLResidencySetDescriptor is macOS 15.0+, and at that deployment target the compiler emits a strong reference to it. On anything below macOS 15 dyld cannot resolve it and aborts the process.
The deployment target is the whole mechanism, visible in the linkage:
| build |
MTLResidencySetDescriptor |
shipped (minos 26.0) |
(undefined) external — strong, aborts |
pinned (minos 13.0) |
(undefined) weak external — tolerated |
The minos number is not itself the gate. dyld does not refuse a binary whose minos exceeds the running OS — verified both ways: an executable stamped minos 99.0 runs, and a dylib stamped 27.0 loads on 26.5. dyld only mentions the minos in its message, which is misleading; the failure is symbol resolution. Worth stating because the obvious reading of that error line is wrong.
Also latent, same cause, currently masked
The shipped binaries additionally carry strong references to libc++ symbols the SDK dates to macOS 15.4 (availability(macos, strict, introduced = 15.4) on the bad_function_call key function, in __configuration/availability.h). dyld dies on the Metal symbol first, so this never surfaces — but it would have bitten macOS 15.0–15.3. The same pin removes it (measured 9 → 0 strong refs).
Scope
How to re-check
scripts/before-pack.cjs now refuses to package any Mach-O above the declared floor, so this class of defect cannot ship again silently. To confirm a given artifact by hand:
vtool -show-build whisper-stt-server
nm -m libggml-metal.dylib | grep MTLResidencySet # must be `weak external`
Suggested action
Call it out in the next release notes so macOS 13/14 users know an update fixes it — the symptom ("Failed to fetch") gives them no way to connect it to their OS version. Worth considering a patch release rather than waiting, given macOS 14 is the recommended version.
Summary
Every installed v1.10.0 build has broken on-device transcription on macOS 13 (Ventura) and 14 (Sonoma) — including macOS 14, the version the README recommends. The STT helper does not fail: it never loads.
Fixed on
mainby the deployment-target pins in #527, so builds cut after that are fine. Nothing fixes the installs already out there, which is why this is worth a line in the next release notes rather than a silent close.What the user sees
The captions pane says "Failed to fetch". That reads as a network problem and sends you looking at the STT server, which was never the issue — the helper process died in the loader before it could answer. (Noted independently in the manual E2E log for a different cause; the message is misleading in both.)
Evidence
Run on a
macos-14GitHub runner, macOS 14.8.7, arm64 — the shippedOpenscreen-Mac-arm64-1.10.0.zip, unmodified:The same source rebuilt from
main, with the pin, on the same runner:i.e. it loads and runs.
Cause
scripts/build-whisper-stt.shset noCMAKE_OSX_DEPLOYMENT_TARGET, so CMake defaulted to the build machine's SDK and the shipped dylibs were stampedminos 26.0.MTLResidencySetDescriptoris macOS 15.0+, and at that deployment target the compiler emits a strong reference to it. On anything below macOS 15 dyld cannot resolve it and aborts the process.The deployment target is the whole mechanism, visible in the linkage:
MTLResidencySetDescriptorminos 26.0)(undefined) external— strong, abortsminos 13.0)(undefined) weak external— toleratedThe
minosnumber is not itself the gate. dyld does not refuse a binary whoseminosexceeds the running OS — verified both ways: an executable stampedminos 99.0runs, and a dylib stamped27.0loads on 26.5. dyld only mentions the minos in its message, which is misleading; the failure is symbol resolution. Worth stating because the obvious reading of that error line is wrong.Also latent, same cause, currently masked
The shipped binaries additionally carry strong references to libc++ symbols the SDK dates to macOS 15.4 (
availability(macos, strict, introduced = 15.4)on thebad_function_callkey function, in__configuration/availability.h). dyld dies on the Metal symbol first, so this never surfaces — but it would have bitten macOS 15.0–15.3. The same pin removes it (measured 9 → 0 strong refs).Scope
How to re-check
scripts/before-pack.cjsnow refuses to package any Mach-O above the declared floor, so this class of defect cannot ship again silently. To confirm a given artifact by hand:Suggested action
Call it out in the next release notes so macOS 13/14 users know an update fixes it — the symptom ("Failed to fetch") gives them no way to connect it to their OS version. Worth considering a patch release rather than waiting, given macOS 14 is the recommended version.