Menu ▾ ▴

#19 Intel Based Mac Support

open
nobody
None
2026-08-07
2026-08-04
Anonymous
No

Originally created by: hellosimplerick

First:
The work you've done here is fantastic. Truly. This is an amazing amount of work to produce an super useful/helpful solution. In order to avoid working at the bleeding edge, so to speak, I have an old iMac that I do a lot of programming and such on it. This ensures I don't do some weird thing that is only available on some higher end machine which leaves millions of people with older devices out of the loop.

So, naturally, I want to get SpeakoFlow running on this older box, using OpenCode's cheap service since I'm not worried about cloud LLM usage. I was surprised to see that you're core home page/docs made the claim it was impossible to get a build going on an intel mac and this repo essentially says build it from scratch if you need it. Which works fine. I assume your issue is the DMG for people not wanting to 'build it themselves' which, even that can be fixed. Given that it is just you working on this and you're still working on graduating, I asked our friend ChatGPT what's the scoop and got the answer below. My question, would you like me to build a DMG for the intel mac that does have the right components? I'm happy to spend some time on doing it if you think there's value. I've pasted the ChatGPT response to my original hunch which confirmed what I thought just for your reference. Again, this is an outstanding piece of work and you should be exceptionally proud of this.

Cheers,

Rick

====================
ChatGPT's response to me
====================

Your instinct is correct

The statement on the SpeakoFlow website is factually wrong as written.

It says:

“GitHub retired its Intel build machines in December 2025, so there's no way to produce and test an Intel build right now.”

GitHub retired the old macos-13 Intel runner on December 4, 2025, but explicitly replaced it with macos-15-intel. GitHub currently also lists macos-26-intel. Intel-hosted macOS Actions runners remain available until at least 2027. (The GitHub Blog)

So the accurate statement would be:

“We currently do not publish or test an Intel build.”

That is very different from:

“There is no way to build or test one.”

The repository contradicts the website

The repository’s own BUILD.md contains dedicated Intel-Mac instructions:

brew install onnxruntime

ORT_LIB_LOCATION=$(brew --prefix onnxruntime)/lib \
ORT_PREFER_DYNAMIC_LINK=1 \
bun run tauri build

The maintainer therefore already knows that an Intel-native build is theoretically supported.

The README is even more explicit:

“If you're on an Intel Mac you can still build from source.”

Meanwhile, the release workflow excludes Intel based on the mistaken assertion that no Intel GitHub runner exists.

That is not an architectural limitation. It is a CI configuration mistake combined with a lack of actual testing.

Is the source Intel-compatible?

From what I inspected, mostly yes.

The application is built with Tauri, Rust, React and native C/C++ speech engines. Rust and Tauri support the standard Intel target:

x86_64-apple-darwin

The project’s Cargo configuration does not globally exclude Intel macOS. Its macOS speech backend uses Metal, and the Apple Intelligence integration is correctly compiled only on ARM64, meaning an Intel build should simply omit that optional feature rather than fail.

The built-in llama.cpp assistant downloader also explicitly recognizes Intel macOS and looks for:

llama-<version>-bin-macos-x64.tar.gz

So the source contains deliberate Intel handling—not merely accidental generic code.

The one legitimate complication

There is a difference between:

  1. Building it for yourself on your Intel iMac

  2. Publishing a portable Intel .dmg for arbitrary Intel Macs

The first looks very achievable.

The second needs some packaging work because Intel builds use Homebrew’s ONNX Runtime dynamically. A locally built app can find that library because it exists under your Homebrew installation. A distributed .dmg may fail on another Mac unless the required ONNX .dylib files are copied into the application bundle and their load paths are rewritten appropriately.

The current build script says macOS has no ONNX Runtime staging step because the normal Apple Silicon build embeds it statically. That assumption does not necessarily hold for the Intel instructions using ORT_PREFER_DYNAMIC_LINK=1.

So my honest assessment is:

Question | Answer -- | -- Can the source compile natively on an Intel Mac? | Probably yes Does the repository already claim this is supported? | Yes Can GitHub Actions test an Intel build? | Yes Is the current Intel workflow configured? | No Would the first build necessarily succeed untouched? | Not guaranteed Could a distributable Intel .dmg need library-packaging changes? | Yes

What likely happened

The maintainer noticed that macos-13 disappeared, concluded that every remaining standard macOS runner was ARM, and never noticed the replacement macos-15-intel label.

The commit history repeats that assumption several times, even though GitHub’s announcement plainly identifies the Intel replacement. The reasoning in the repository is therefore internally coherent—but built on a false premise.

The sensible test

On GitHub Actions, the missing matrix entry would roughly be:

- platform: "macos-15-intel"
  args: "--target x86_64-apple-darwin"
  target: "x86_64-apple-darwin"

The workflow would also need an Intel-only preparation step:

- name: Install ONNX Runtime for Intel macOS
  if: inputs.target == 'x86_64-apple-darwin'
  run: |
    brew install onnxruntime
    echo "ORT_LIB_LOCATION=$(brew --prefix onnxruntime)/lib" >> "$GITHUB_ENV"
    echo "ORT_PREFER_DYNAMIC_LINK=1" >> "$GITHUB_ENV"

Then the result should be inspected with:

file SpeakoFlow.app/Contents/MacOS/speakoflow
otool -L SpeakoFlow.app/Contents/MacOS/speakoflow

The first must report x86_64. The second will expose whether ONNX Runtime is still pointing into Homebrew and therefore needs bundling.

Bottom line

No, there is not “no way.”

There is a perfectly credible route to an Intel build, both locally and through GitHub Actions. The project simply has not done the engineering validation and packaging work necessary to call Intel an officially supported release target.

Your Intel iMac is actually an ideal machine for proving this. The correct next move is a clean source build first—not changing code, not inventing cross-compilation, and not accepting the documentation’s premise.

Your instinct is correct

The statement on the SpeakoFlow website is factually wrong as written.

It says:

“GitHub retired its Intel build machines in December 2025, so there's no way to produce and test an Intel build right now.”

GitHub retired the old macos-13 Intel runner on December 4, 2025, but explicitly replaced it with macos-15-intel. GitHub currently also lists macos-26-intel. Intel-hosted macOS Actions runners remain available until at least 2027. (The GitHub Blog)

So the accurate statement would be:

“We currently do not publish or test an Intel build.”

That is very different from:

“There is no way to build or test one.”

The repository contradicts the website

The repository’s own BUILD.md contains dedicated Intel-Mac instructions:

brew install onnxruntime

ORT_LIB_LOCATION=$(brew --prefix onnxruntime)/lib \
ORT_PREFER_DYNAMIC_LINK=1 \
bun run tauri build

The maintainer therefore already knows that an Intel-native build is theoretically supported.

The README is even more explicit:

“If you're on an Intel Mac you can still build from source.”

Meanwhile, the release workflow excludes Intel based on the mistaken assertion that no Intel GitHub runner exists.

That is not an architectural limitation. It is a CI configuration mistake combined with a lack of actual testing.

Is the source Intel-compatible?

From what I inspected, mostly yes.

The application is built with Tauri, Rust, React and native C/C++ speech engines. Rust and Tauri support the standard Intel target:

x86_64-apple-darwin

The project’s Cargo configuration does not globally exclude Intel macOS. Its macOS speech backend uses Metal, and the Apple Intelligence integration is correctly compiled only on ARM64, meaning an Intel build should simply omit that optional feature rather than fail.

The built-in llama.cpp assistant downloader also explicitly recognizes Intel macOS and looks for:

llama-<version>-bin-macos-x64.tar.gz

So the source contains deliberate Intel handling—not merely accidental generic code.

The one legitimate complication

There is a difference between:

  1. Building it for yourself on your Intel iMac
  2. Publishing a portable Intel .dmg for arbitrary Intel Macs

The first looks very achievable.

The second needs some packaging work because Intel builds use Homebrew’s ONNX Runtime dynamically. A locally built app can find that library because it exists under your Homebrew installation. A distributed .dmg may fail on another Mac unless the required ONNX .dylib files are copied into the application bundle and their load paths are rewritten appropriately.

The current build script says macOS has no ONNX Runtime staging step because the normal Apple Silicon build embeds it statically. That assumption does not necessarily hold for the Intel instructions using ORT_PREFER_DYNAMIC_LINK=1.

So my honest assessment is:

Question Answer
Can the source compile natively on an Intel Mac? Probably yes
Does the repository already claim this is supported? Yes
Can GitHub Actions test an Intel build? Yes
Is the current Intel workflow configured? No
Would the first build necessarily succeed untouched? Not guaranteed
Could a distributable Intel .dmg need library-packaging changes? Yes

What likely happened

The maintainer noticed that macos-13 disappeared, concluded that every remaining standard macOS runner was ARM, and never noticed the replacement macos-15-intel label.

The commit history repeats that assumption several times, even though GitHub’s announcement plainly identifies the Intel replacement. The reasoning in the repository is therefore internally coherent—but built on a false premise.

The sensible test

On GitHub Actions, the missing matrix entry would roughly be:

- platform: "macos-15-intel"
  args: "--target x86_64-apple-darwin"
  target: "x86_64-apple-darwin"

The workflow would also need an Intel-only preparation step:

- name: Install ONNX Runtime for Intel macOS
  if: inputs.target == 'x86_64-apple-darwin'
  run: |
    brew install onnxruntime
    echo "ORT_LIB_LOCATION=$(brew --prefix onnxruntime)/lib" >> "$GITHUB_ENV"
    echo "ORT_PREFER_DYNAMIC_LINK=1" >> "$GITHUB_ENV"

Then the result should be inspected with:

file SpeakoFlow.app/Contents/MacOS/speakoflow
otool -L SpeakoFlow.app/Contents/MacOS/speakoflow

The first must report x86_64. The second will expose whether ONNX Runtime is still pointing into Homebrew and therefore needs bundling.

Bottom line

No, there is not “no way.”

There is a perfectly credible route to an Intel build, both locally and through GitHub Actions. The project simply has not done the engineering validation and packaging work necessary to call Intel an officially supported release target.

Your Intel iMac is actually an ideal machine for proving this. The correct next move is a clean source build first.

Related

Tickets: #22

Discussion

  • Anonymous

    Anonymous - 2026-08-05

    Originally posted by: AbhishekBarali

    Rick, thank you for this. You were right, and I have fixed it.

    GitHub did replace macos-13 with macos-15-intel, available until August 2027. The README's claim that there was "no way to produce and test" an Intel build was simply wrong, and the same wrong assumption had spread into three workflow files. All corrected in [#22], credited to you.

    An Intel build is now green in CI. It produced a working SpeakoFlow_x64.dmg and passed every check, including launching the bundled binary on a real Intel runner:

    file      -> Mach-O 64-bit executable x86_64
otool -L  -> @rpath/libonnxruntime.dylib, no Homebrew path
LC_RPATH  -> @executable_path/../Frameworks
smoke     -> transcribe.cpp compute devices: 1

    Two real obstacles turned up, and you predicted both.

    Metal is off on Intel. You were right that Intel would just omit optional features, but Metal was not actually arch-gated, so Intel was silently inheriting it. ggml's Metal backend targets Apple Silicon, and there are open upstream reports of corrupted output on Intel Macs with AMD GPUs, so it is now gated to arm64 and Intel builds CPU only. Transcription works. Small Whisper models are fine, large ones are slow.

    ONNX Runtime is bundled. Your instinct was right, and it is worse than "may fail": pykeio's ort has dropped x86_64-apple-darwin entirely, so there is no static build to embed. It also cannot simply be dropped, because ort backs vad-rs (Silero VAD, used by every recording) as well as Parakeet. CI now copies Homebrew's dylib, rewrites its install name to @rpath before linking, and ships it inside Contents/Frameworks. The audit fails the build if otool -L still shows a Homebrew path.

    One catch you will want to know before spending any time on it. Homebrew only publishes an Intel onnxruntime bottle for Sonoma now, and that dylib reports minos 14.0, so the current build needs macOS 14 or newer. What version is that iMac on, and what does sysctl -n machdep.cpu.brand_string say? If it is on 14 or 15 I will send you the build. If it is older, the honest answer is that lowering that floor means compiling ONNX Runtime from source with a lower deployment target, which I would rather scope properly than rush.

    On your offer to build a DMG: I would much rather take you up on the testing than the binary, if that is alright. Not for lack of trust. I cannot audit or reproduce a binary built on another machine, and this app installs a system wide keyboard listener, so provenance matters. What is genuinely valuable is exactly what you offered first, which is a real Intel Mac telling us whether it actually works.

    Intel stays in test builds only until it is confirmed on real hardware. Once it is, it goes into the release matrix as a community tested target. Worth noting that macos-15-intel itself retires in August 2027, so this has a natural horizon.

     

    Related

    Tickets: #22

  • Anonymous

    Anonymous - 2026-08-05

    Originally posted by: hellosimplerick

    Happy to test the dmg. My iMac:
    macOS: 26.5.2
    CPU: Intel(R) Core(TM) i5-10500 CPU @ 3.10GHz

     

  • Anonymous

    Anonymous - 2026-08-07

    Originally posted by: AbhishekBarali

    Happy to test the dmg. My iMac: macOS: 26.5.2 CPU: Intel(R) Core(TM) i5-10500 CPU @ 3.10GHz

    If you had time to test it would love to know how was experience . Did you face any issue ? If you do just let me know I will work on it ASAP

     

Log in to post a comment.