Talkify: on-device voice dictation for macOS, triggered from the notch

The problem Talkify targets: dictation that does not leave your Mac

Cloud dictation tools solve accuracy by sending audio to a server. That means an account, a network dependency, and a privacy policy you have to read. Talkify takes the opposite position: the README states that everything is on-device, using Apple's SpeechAnalyzer and SpeechTranscriber for recognition, AVSpeechSynthesizer for Read Aloud, the Translation framework for translation, and FoundationModels for prompt shaping. The README is explicit that FoundationModels is a language model running locally, with no key, no account and no request.

The intended user is a macOS user who dictates into other applications all day and does not want a subscription or a data trail. It is a menubar app, not a document editor: the output lands in whatever text field has focus. The README also notes that Talkify stores no audio and keeps no history beyond local usage metrics shown in Insights.

How the fn key, the notch island and the clipboard actually connect

The interaction model is built around a hold-and-release gesture. According to the README's gesture table, you hold fn, speak, and release; a quick tap of fn starts a hands-free session that ends on a second tap. Right Option dictates in a second language, and right Command dictates and translates. Escape cancels mid-session.

The visual surface is the notch. A caption appears under it naming the prompt a session will use, and after release the island stays up while a rewrite runs. That is a design choice worth noting: the feedback loop lives at the top of the screen, not in a floating window near the cursor.

Insertion is the part that deserves scrutiny. The README says dictated text is inserted by pasting, so it passes through the system clipboard for up to about half a second before the previous clipboard is restored. A clipboard manager or Universal Clipboard can observe text during that window. This is a real architectural constraint, not a bug, and it is the kind of detail most dictation tools omit from their documentation.

Installing Talkify and running a first dictation

The README gives Homebrew as the primary install path. The full tap-qualified name matters: the README explains that Homebrew 6 will not load anything from a third-party tap until you trust it, but installing by full name adds the tap and trusts this one cask on its own, with no separate brew trust command.

brew install --cask tornikegomareli/talkify/talkify

After that, launch the app. The README's gesture table is the whole onboarding: hold fn, speak, release. If the fn key is already bound to something else in your setup, the README says the trigger and the Read Aloud shortcut are rebindable in Settings → Shortcuts.

If you would rather build from source, the README gives the Xcode path and a headless variant:

git clone https://github.com/tornikegomareli/Talkify.git
cd Talkify
xcodebuild -project Talkify.xcodeproj -scheme Talkify -configuration Debug build

The README also documents running the tests the way CI does, with xcodebuild test against the macOS destination. There is a prebuilt Talkify.dmg linked from the latest release if you want neither Homebrew nor Xcode.

Prompt shaping is a beta with a ten-second fail-safe

Prompt shaping rewrites finished dictation through Apple's on-device model before insertion. The README ships three built-in prompts: tighten grammar, bullet lists, and remove filler words. You can edit them or write your own, and the README notes that for most prompts the instruction is the whole prompt, with a closing instruction and a worked example available under Advanced.

The README labels shaping a beta and describes its failure behaviour directly: any error, or an answer slower than ten seconds, inserts your raw words instead. That fail-safe is the right call for a dictation tool, because a rewrite that hangs would otherwise swallow the sentence you just spoke.

One constraint is easy to miss. The framing that keeps the model rewriting your words rather than answering them is fixed and not editable. If you want to change how the model is instructed at that level, the README does not offer a path. The README also does not document rollback for a shaping result you dislike, beyond cycling to None before you speak.

Where Talkify is the wrong tool

The requirements section is unambiguous: macOS 26 (Tahoe) on Apple Silicon. That single line disqualifies Intel Macs, any macOS version before 26, and every non-Apple platform. There is no Linux or Windows build, and the topics list confirms the scope is macOS and Apple Silicon.

A second boundary is the clipboard. Because insertion pastes, text is visible to clipboard managers and Universal Clipboard for up to about half a second. If you dictate credentials, personal data, or anything covered by a policy that treats the system clipboard as shared state, that window matters.

Read Aloud has a related caveat. The README says it reads a selection through Accessibility where it can, and by copying it where it cannot, which the README states is any web page. The previous clipboard is restored afterwards, but the selection still passes through the clipboard.

Finally, the README does not document rollback for the app itself, and it does not describe what happens to in-flight transcription if the app quits mid-session. Treat those as unverified rather than absent.

How Talkify differs from Whisper-based local dictation

The obvious alternative category is local dictation built on OpenAI's Whisper models, typically wrapped in a menubar app or a command-line tool. The difference is where the model comes from. Whisper-based tools ship or download a model file and run inference themselves, which usually means you choose a model size and accept the memory and latency that come with it.

Talkify does none of that. It calls Apple's SpeechAnalyzer and SpeechTranscriber, so the recognition model is whatever the operating system provides. There is no model download step in the README, no model picker, and no quantization decision. The benefit is that you never manage weights. The cost is that you cannot swap in a different model, and you inherit Apple's accuracy on your language and accent without a fallback.

The same pattern repeats across the app: Translation is Apple's framework, Read Aloud is AVSpeechSynthesizer, shaping is FoundationModels. Talkify is a careful integration layer over first-party APIs, not a model project. If your reason for wanting local dictation is control over the model itself, a Whisper-based tool fits better. If your reason is that audio should not leave the machine, Talkify satisfies that with far less setup.

Licence, release cadence and what you are maintaining

Talkify is MIT-licensed, which permits commercial and private use with the usual attribution requirement. The repository includes a Talkify.entitlements file and an appcast.xml at the top level, the latter consistent with a distribution channel that publishes updates outside the Mac App Store. The README does not describe an auto-update mechanism in the text available here, so check the app's own settings rather than assuming one.

The last push to main was on 2026-09-08, and v0.8.2 was released the same day, following v0.8.1 on 2026-09-06 and v0.8.0 on 2026-09-03. That is a fast release cadence across a single week, and the shaping feature is still labelled beta in the README. For an adopter, the maintenance cost is mostly upgrade friction: the app targets macOS 26 specifically, so OS upgrades and Xcode toolchain changes are the events most likely to break a source build. If you install the cask or the dmg, that burden shifts to the maintainer. If you build from source, it does not.

Editorial conclusion

Adopt Talkify if you are on macOS 26 with Apple Silicon and want dictation that never leaves the machine, installed with brew install --cask tornikegomareli/talkify/talkify. Skip it if you need Intel Macs, older macOS, Windows or Linux, or if a half-second clipboard window for inserted text is unacceptable in your workflow. Before relying on it, verify the fn trigger does not collide with your existing function-key bindings, and read Casks/talkify.rb to confirm what the cask installs.

Frequently asked questions

Official sources

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