HowtoDictateIntoAnyApplicationonMac

"Works in any app" is the claim every dictation tool makes and the one most of them quietly qualify. In practice, dictation on macOS tends to work beautifully in the app it ships with, acceptably in Apple's own apps, and unpredictably everywhere else. Understanding why makes the failures much easier to diagnose — and makes it obvious which tools can actually make the claim.

The boundary you keep running into

macOS is deliberately hostile to one application typing into another. That isolation is a security property, not an oversight: if any app could silently inject keystrokes into any other, a single malicious download would own every password field on your machine.

So the operating system puts the capability behind a gate. The sanctioned route is the Accessibility APIs — the same subsystem that lets screen readers describe interfaces and lets assistive hardware drive them. An app that wants to type on your behalf has to ask for Accessibility permission, and you have to grant it explicitly in System Settings.

That is the entire reason the permission prompt looks more alarming than a microphone request. It is more powerful, and it should be treated that way.

How cross-app injection actually works

Once permission is granted, the sequence is roughly:

1. Identify the frontmost application.
2. Walk its accessibility tree to find the element that currently has keyboard focus.
3. Confirm that element accepts text.
4. Insert the transcribed string at the insertion point.

Every one of those steps can fail independently, which is why "dictation is broken" is rarely a useful bug report. The interesting question is always which step.

Where it goes wrong

• The app draws its own text fields. Some editors and terminals render text themselves rather than using a standard control. There is no accessible element to target, so focus resolution finds nothing.
• Focus is ambiguous. Overlays, command palettes, and modal sheets can leave two plausible focus targets. The tool picks one; sometimes it is not the one you were looking at.
• The field is read-only to the API. Web views occasionally expose a field that reports itself as text-capable but rejects programmatic insertion.
• Permission was granted to a different copy. macOS keys permissions to an app's location and signature. Running from the DMG, then moving to Applications, invalidates the grant.

That last one accounts for a surprising share of "it stopped working" reports. Install to Applications first, launch from there, and grant permissions once.

What reliable coverage looks like

A tool that genuinely works across apps is not one that never fails — it is one that fails in a recoverable way. The properties worth checking:

• The captured text survives a failed insertion. If injection fails and your words are gone, that is a data-loss bug, not a compatibility limitation.
• There is a paste fallback. When the field cannot accept programmatic input, putting the text on the clipboard is a reasonable degradation.
• Failure is visible. Silent failure trains you to distrust the tool everywhere, including where it works.

Warp keeps the captured text available when insertion fails and falls back to paste, so a bad field costs you a keystroke rather than a paragraph. The recovery guide covers the sequence.

Testing your own setup

Rather than discovering coverage gaps inside a message you actually cared about, spend five minutes up front. Test one field in each category:

• Native — Mail, Notes, Messages. These should be flawless; if they are not, the problem is your permissions, not the app.
• Electron — Slack, VS Code, Notion. Usually fine, occasionally surprising in modal composers.
• Terminal — your shell, and any TUI you live in.
• Browser — a Google Docs body and a plain textarea, which behave differently.

Current field coverage is tracked on the supported apps page.

Frequently asked questions

Why does dictation work in some Mac apps but not others?

Text injection depends on how each app exposes its text fields to the macOS Accessibility APIs. Native Cocoa apps expose them consistently. Electron apps, web views, and custom-drawn editors sometimes expose a field that cannot accept programmatic input, which is where insertions fail.

Do I need Accessibility permission for this?

Yes. Accessibility is the sanctioned macOS path for one application to read a selection and type into another. Without it a dictation tool can transcribe your speech but has no way to deliver the text into the app you are working in.

What should I do when text does not arrive?

Retry once in the same field, then fall back to pasting the captured text. If a specific app fails repeatedly, report it with the app name, the field type, and roughly when it happened — field-level behaviour differs enough that the specific field matters more than the app.