Talkify: on-device dictation that crosses the system clipboard for half a second

Dictated text crosses the system clipboard for about half a second

The privacy section states two caveats and both are about the clipboard rather than the network. Dictated text is inserted by pasting it, so it passes through the system clipboard for up to about half a second before your previous clipboard is put back, and a clipboard manager or Universal Clipboard can see it during that window. Read Aloud has the same shape for a different reason: it reads a selection through Accessibility where it can, and by copying it where it cannot, which the documentation names as any web page, so the selection passes through the clipboard and the previous contents are restored afterwards. Read that next to the claim that the app makes no network requests, stores no audio and keeps no history beyond local usage metrics, and the shape of the privacy model is clear. Audio never leaves and never persists; the words do transit a shared system buffer briefly, and on a Mac with Handoff or a clipboard manager running that buffer is not private.

macOS 26 on Apple Silicon is the entire requirements list

One line, no alternatives: macOS 26 (Tahoe) on Apple Silicon. There is no Intel build and no earlier system in the stated support, which follows from what the app is built on. Recognition uses Apple's `SpeechAnalyzer` and `SpeechTranscriber`, Read Aloud uses `AVSpeechSynthesizer`, translation uses the `Translation` framework, and prompt shaping uses `FoundationModels`. Four Apple frameworks, all on-device. The last one is the interesting case because it is a language model: the documentation is explicit that it is Apple's, that it runs locally, and that there is no key, no account and no request. So on-device here means Apple-supplied rather than Talkify-supplied, which is a distinction worth holding on to when someone asks whether the app can work on a machine with no Apple services available.

brew install --cask needs the full three-part name to trust one cask

The Homebrew line looks unusual and the reason is explained rather than incidental:

brew install --cask tornikegomareli/talkify/talkify

The tap is `tornikegomareli/talkify` and the cask inside it is also called `talkify`, so the full name repeats the word. Homebrew 6 will not load anything from a third-party tap until you trust it, and installing by full name is what adds the tap and trusts this one cask on its own, nothing else in the tap, with no separate `brew trust` step. The documentation points at `Casks/talkify.rb` for anyone who would rather read what the cask does first, and that file sits at the root of the repository, which is the layout Homebrew expects for a tap. The other two routes are the `Talkify.dmg` attached to the latest release, and building from source:

git clone https://github.com/tornikegomareli/Talkify.git
cd Talkify
open Talkify.xcodeproj   # ⌘R

or headless, with `xcodebuild -project Talkify.xcodeproj -scheme Talkify -configuration Debug build`.

The prompt-shaping framing is fixed and not editable

Prompt shaping is the beta feature and its design puts one instruction outside your control. Turning on Shape dictation with a prompt in Settings, the prompt you pick rewrites finished dictation through Apple's on-device model before insertion, and the framing that keeps the model rewriting your words instead of answering them is fixed and not editable. Everything around it is yours: three prompts ship built in, covering tighter grammar, bullet lists with filler words removed, and the library shows each one's instruction under its name so you choose by reading. You can edit any prompt or write your own, the instruction is the whole prompt for most of them, and a closing instruction plus a worked example sit under Advanced. There is a Try button that takes a sample sentence and runs it through the same on-device model a real session uses, so the preview is the real path rather than a simulation. That is a well-designed exception, and it is still an exception.

Shaping fails safe at ten seconds and inserts the raw words

The beta label is paired with a specific failure rule rather than a disclaimer. Any error, or an answer slower than ten seconds, inserts your raw words unchanged, the history keeps what you actually said, and nothing leaves your Mac. So the worst case of the feature is that it does nothing, not that it substitutes wrong words for your own. The interaction is also designed around the idea that you should know which prompt is active. While you dictate, a caption under the notch names the prompt the session will shape with, coloured from your Edge Glow palette and moving with your voice, and the bare arrow keys cycle through your prompts or None, which inserts the words exactly as spoken. After you release the key the island stays up and the same caption names the prompt while the rewrite runs, so the state is visible on both sides of the operation.

Two languages get two triggers, and the shortcut does not change

Translation is bound to a modifier rather than to a language, so there is one shortcut to remember no matter which language you are writing in. Pick a language in Settings and the Translate key writes in it: hold right ⌘, speak English, and Spanish lands in the document. Translation runs on your Mac through Apple's Translation framework, and the notch shows the language pair before you speak so you can see what it heard. If it fails, nothing is pasted and your words go to the clipboard, which is a deliberately non-destructive fallback. A second language in Settings gets its own trigger, so fn is English and right ⌥ is German with no setting to change in between, and both are rebindable to a keyboard key or a supported mouse button. The same idea runs the other way: with Translate before speaking on, Read Aloud speaks a selection in a language you do not read using your own voice's language.

A pure reducer, one-way callbacks, and an appcast with no visible explanation

The architecture section describes a small set of rules: code is organised into folders, callbacks flow one way from the main wiring point, and a pure reducer handles the state. `App/` holds the composition root, the settings store and the status item. `Input/` holds the global key event tap and the recorded bindings. `Dictation/` holds the session machine, `DictationSessionMachine`, described as a pure tested reducer, plus the speech and insertion services and the HUD surface and voice visuals that only dictation draws. `Translation/` holds the coordinator both callers talk to, the rules, and the two files that import Apple's Translation framework, and the list is cut off at an entry beginning `Pr`. Two things in the tree go unexplained. There is a `appcast.xml` at the root, the standard Sparkle update feed, and no visible part of the README says how updates arrive. And there is `Talkify.entitlements` next to a global key event tap, which is where the accessibility permission the documentation never lists actually bites.

Editorial conclusion

Use Talkify if you dictate all day on a Mac and want the transcription to stay on the machine, since every model it calls is an Apple framework running locally with no key and no account. Two things to weigh first. Dictated text is inserted by pasting, so it is readable by a clipboard manager or Universal Clipboard for roughly half a second, and that is a wider exposure than the no-network-requests line suggests. And the platform floor is one line wide, macOS 26 Tahoe on Apple Silicon, with prompt shaping still labelled beta and its framing fixed rather than editable, so verify that your team is on that OS before standardising on it.

Frequently asked questions

Official sources

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