Skip to content

Sequoia 15 / Intel compatibility port - #4

Open
MohamadAbakar wants to merge 1 commit into
31Carlton7:mainfrom
MohamadAbakar:sequoia-intel
Open

Sequoia 15 / Intel compatibility port#4
MohamadAbakar wants to merge 1 commit into
31Carlton7:mainfrom
MohamadAbakar:sequoia-intel

Conversation

@MohamadAbakar

Copy link
Copy Markdown

Summary

  • Ports Plynn so it can run on macOS 15 (Sequoia) Intel, not only macOS 26 Apple Silicon.
  • Hold-to-talk, paste, dictionary, snippets, and rules polish stay. Speech uses Apple's on-device recognizer instead of Parakeet/ANE. Apple Intelligence and the MLX Qwen polish model are unavailable on this hardware, so those paths degrade cleanly.
  • ./scripts/make-app.sh now uses swift build (Command Line Tools / Xcode 16) and produces an x86_64 app with minos 15.0.

This is meant as a parallel older-Mac track, not a replacement for the Tahoe / Apple Silicon product. Happy to reshape it (branch-only, #if, etc.) if you'd rather not land it on main.

Test plan

  • On Sequoia 15 Intel: ./scripts/make-app.sh and confirm build/Plynn.app is x86_64 with minos 15.0
  • First launch: grant Microphone, Speech Recognition, and Accessibility, then relaunch
  • Enable Dictation in System Settings so the on-device English model is present
  • Hold fn (or Right Option if fn is a keyboard layer key) in a text field and confirm text pastes
  • Confirm Settings no longer offers Parakeet download, and Sparkle is off so a Tahoe release cannot overwrite this build

Made with Cursor

Retarget the app for macOS 15 on Intel so it can run without macOS 26, the Neural Engine, or Xcode 26. Speech, polish, and the build script now use APIs and toolchains available on Sequoia.

Co-authored-by: Cursor <cursoragent@cursor.com>
@31Carlton7

Copy link
Copy Markdown
Owner

Thanks for this — it's a genuinely thorough port, and the care shows: the SFSpeechRecognizer swap keeps requiresOnDeviceRecognition on, the stub actors keep the formatting pipeline compiling instead of hacking #if through every call site, and you flagged the branch-vs-main question yourself in the description. I checked it out against current main and went through it properly, so here's what I found.

It builds clean, but the test suite aborts on Apple Silicon / macOS 26.

swift build   → 0 errors
swift test    → SIGABRT (signal 6) after 5 tests; 111 of 116 never run

It dies entering AppleSpeechEngineTests/testReuseAcrossSessions. SFSpeechRecognizer is deprecated on macOS 26 and traps in this context, so on my hardware the whole suite stops at the first Apple Speech test. That's the practical blocker: I can't validate this PR on the machine I develop on, which means every future change to it would land unverified from my side.

Merging to main would also take the shipping product with it. Stacking these up:

  • Package.swift drops FluidAudio, MLX, and Sparkle, and LSMinimumSystemVersion goes 26.0 → 15.0
  • Info.plist loses SUFeedURL and SUPublicEDKey — that breaks auto-update for everyone already on 0.1.x
  • make-app.sh moves to swift build with ad-hoc signing, so no Developer ID and nothing notarization can staple. The current release chain (make-app.shnotarize.shmake-dmg.shmake-release.sh) stops working
  • AppleFMFormatter and LLMFormatter become no-ops returning input unchanged, so AI polish, command mode, and meeting summaries quietly do nothing

None of that is wrong for an Intel build — it's exactly right for one. It just can't be the state of main, which is what actually ships to Apple Silicon users.

Where I'd like to take this. Plynn being macOS 26 + Apple Silicon only was a deliberate call early on: it's what buys Parakeet on the Neural Engine, Apple Intelligence polish, and Liquid Glass. I'm not ready to walk that back, so I don't want to merge a second track I can't test or release. Two options that keep your work alive:

  1. Keep it as a standing sequoia-intel branch. Zero risk to the release pipeline, and anyone on an older Mac can build it. I'm happy to link it from the README so it's discoverable.
  2. Rework it as availability-gated code in one tree#if canImport(FluidAudio) / @available guards so a single codebase serves both, with the deps staying in Package.swift. Bigger job, and the test-crash problem needs solving first (gating the Apple Speech tests by OS version would be the start).

If you want to pursue (2) I'll review it seriously. If you'd rather leave it at (1), also completely fine — say the word and I'll set the branch up. Either way I appreciate the effort here; the Intel gap is real, I just need the main product to stay releasable while we close it.

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.

2 participants