Yap: on-device macOS dictation built on Apple's SpeechAnalyzer

The problem Yap picks, and the one it refuses to solve

Dictation on macOS has a cost problem that is not about money. The open source options the README surveys mostly ask you to download a model: Whisper weights run to hundreds of megabytes, sit in RAM, and the README claims that on slower machines a single paragraph can take thirty seconds to a minute to come back. Others are Electron apps, so a browser engine idles in memory to draw a menu bar icon. A third group is closed source, which means you cannot verify the claim that audio stays local.

Yap's answer is to carry no model at all. macOS 26 added SpeechAnalyzer and SpeechTranscriber, which do streaming on-device speech to text using models the OS ships and manages. Yap is a thin native client over those APIs: roughly three thousand lines of Swift in a 4 MB app, idling around 60 MB of memory by the README's own numbers. The README cites a third-party benchmark at get-inscribe.com that put Apple's API at 2.12% word error rate on clean audio and 4.56% on noisy, against 3.74% and 7.95% for Whisper Small, and about three times faster across 5,559 LibriSpeech clips. That is the project's cited evidence, not an independent measurement here.

The audience is narrow and the README says so: Apple Silicon, macOS 26 or later. If you are outside that, Yap is not slow or degraded, it is unavailable. That is a deliberate boundary, not an oversight.

Audio capture, SpeechAnalyzer, and the clipboard paste that decides everything

The capture path starts on the default input device through AVAudioEngine, converted to whatever format the analyzer requests. One detail matters more than it looks: capture begins before the speech stack finishes initializing, and buffers recorded in that window are held and flushed once the transcriber attaches. Without that, the first word of every sentence gets clipped, which is the kind of bug users blame on their own microphone.

Transcription goes through SpeechAnalyzer with volatile results enabled, which is what produces the live preview and waveform. There is no fallback path. The README is explicit that older APIs such as SFSpeechRecognizer can silently route to Apple's servers when a locale has no on-device model, so Yap does not use them. If SpeechAnalyzer cannot handle your language locally, dictation stops. That is the design promise expressed as a failure mode.

Insertion is where most dictation tools quietly break. Yap writes the transcript to the clipboard, drives Command-V through System Events, then restores your previous clipboard contents. The restore is delayed on purpose, because Chromium-based apps read the pasteboard asynchronously and more than once; restoring too early hands the renderer stale data. The README calls that single detail the difference between working everywhere and working only in native apps. It is also the reason the app needs both Accessibility and Automation permissions.

State is centralised in RecordingCoordinator, a small state machine whose dependencies are all protocols, which is why the logic is unit-testable without a microphone. The repository layout backs this up: Sources/ and Tests/ sit at the top level alongside project.yml, install.sh and release.sh.

Install Yap with Homebrew and run a first dictation

The README gives two install routes: the website at frigade.com/yap, or the Homebrew cask. The cask is the one worth scripting.

brew install --cask frigadehq/tap/yap

That pulls the signed and notarized release build, so macOS opens it without a Gatekeeper complaint. Later upgrades are the same tap:

brew upgrade --cask yap

If you prefer the disk image, the README points at the Releases page for the .dmg; drag it into Applications. Building from source is possible but the README states it needs Xcode 26, and the repository carries project.yml and install.sh for that route.

On first launch Yap asks for four permissions and explains each: Microphone to hear you, Speech Recognition to transcribe on device, Accessibility to see which app you are typing into, and Automation to paste the result there. Accessibility must be switched on by hand in System Settings. macOS requires that of any app that types on your behalf and there is no programmatic grant, so budget a trip to System Settings rather than expecting a single dialog to finish the job.

Then open any text field, press the default shortcut Command-Shift-D, speak, and press it again. A small window appears near the bottom of the screen with a live waveform and a running preview; on the second press the text lands in the field you were already in. The README notes the shortcut is fully rebindable and that a single modifier key can be used instead, with right shift called out as a comfortable spare-thumb option. Pressing escape twice discards a dictation in progress.

Where Yap is the wrong tool

The hard limit is the OS floor. Yap requires macOS 26 (Tahoe) on Apple Silicon; Intel Macs are not supported. The README is candid about why: the only way to transcribe on those machines was an API that sends audio to Apple, and that breaks the one promise the app makes. So on an Intel Mac or an older macOS release there is no degraded mode to fall back to, and a user who needs dictation there should look elsewhere rather than wait for a port.

The second limit is language coverage. Because Yap refuses the SFSpeechRecognizer path, any locale without an on-device SpeechAnalyzer model simply cannot be dictated. That is a correctness-over-coverage choice, and it is defensible, but it means the app's usefulness is bounded by what Apple ships for your language, not by what the Yap project does.

The third limit is architectural rather than functional. Yap delegates recognition quality, model updates, and language support to a framework it does not control. If Apple's on-device model regresses for your accent after an OS update, Yap has no lever. A project that bundles its own weights has a slower, heavier app but a fallback. Yap has none, by design.

Finally, the insertion mechanism is inherently fragile. Driving Command-V through System Events and racing the pasteboard against asynchronous readers is a workaround, not an API. The README describes the delay as tuned for Chromium-based apps, which implies other pasteboard behaviours are handled by the same heuristic rather than by a contract.

Yap against a Whisper-based dictation app

The obvious alternative is any of the open source macOS dictation tools that bundle Whisper weights, and the difference is not a feature list, it is where the model lives. A Whisper-based app downloads hundreds of megabytes, keeps that model resident, and pays inference cost on the local machine. The README's cited figures put Whisper Small at 3.74% word error rate on clean audio and 7.95% on noisy, with roughly three times the latency of Apple's API, and warns that on slower machines a paragraph can take thirty seconds to a minute.

Yap inverts every one of those properties. Nothing to download, nothing resident before the first word, no per-minute cost, and a 4 MB app. What you give up is control. A Whisper-based tool lets you pick the model, run a larger one on a fast machine, and dictate in languages Apple has not shipped a local model for. Yap cannot do any of that, because the model is the operating system's.

There is a second axis: process weight. Electron-based dictation apps keep a browser engine alive to render a menu bar icon and a settings window. Yap is Swift and SwiftUI, and the README describes it as living in the menu bar, the Dock, both, or neither, with either icon hideable from Settings so it can run on the shortcut alone. For someone who wants a dictation tool that is invisible until invoked, that is a real difference in feel, not a marketing one.

Release cadence, licence, and what upgrading costs you

Yap is MIT licensed, which is permissive: you can read the source, build it, and ship modified versions, subject to the usual attribution terms. The practical implication for a team is that there is no per-seat cost and no vendor account, and no legal review needed beyond what your organisation already applies to MIT dependencies. This is not legal advice; check your own policy.

The repository is not archived and the last push was on 2026-09-15, the same day as the v0.1.12 release. The three most recent releases listed are v0.1.12 on 2026-09-15, v0.1.11 on 2026-09-08, and v0.1.10 on 2026-08-12. That is a weekly-to-monthly rhythm across the visible window, and it is the only maintenance signal available here.

Upgrade cost is unusually low for a native app, because there is no model to re-download and no migration to run. The Homebrew cask updates in place with brew upgrade --cask yap. The real upgrade risk sits one layer down: because Yap depends on SpeechAnalyzer and the speech models macOS ships, an OS update can change recognition behaviour without Yap changing at all. That is the cost of carrying no model, and it is worth naming before a team standardises on the app.

Version numbers are still in the 0.1.x range, which is worth reading literally. The README documents the core loop and the permission model well, but it does not document rollback, migration of the local transcript history between versions, or what happens to in-progress dictation during an app update.

Editorial conclusion

Adopt Yap if you are already on macOS 26 with an Apple Silicon Mac and you want dictation that cannot phone home, installed with brew install --cask frigadehq/tap/yap. Do not adopt it if you are on Intel or an older macOS: the README states Intel support was dropped deliberately, because the only on-device path there was an API that sends audio to Apple. Before relying on it, verify two things on your own machine: that Accessibility and Automation are both switched on in System Settings, since macOS will not grant Accessibility programmatically, and that your working language has an on-device SpeechAnalyzer model, because the README says dictation stops rather than falling back to a server when it does not.

Frequently asked questions

Official sources

1. FrigadeHQ/yap on GitHub
2. License: MIT
3. Project website
4. README
5. Releases