You hold down a key, you say a sentence, and the words appear in whatever you were writing. That is what a dictation app is for. The interesting part is the last step. Once the app has turned your speech into text, it has to get that text into the document, the email, or the message you had open. There are two ways to do that on a Mac, and the choice between them says more about an app than almost anything else it does.
The first way is to type the text for you, simulating the keystrokes as if you had entered them yourself. The second way is to put the text on the clipboard and let you paste it. They look almost identical from the outside. Underneath, they ask for very different amounts of trust.
What “typing into another app” actually requires
macOS does not let one app reach into another and enter text without permission. That boundary is deliberate, and it is the same boundary that stops malware from doing the same thing.
To synthesize keystrokes into whatever app is in front, a Mac app posts fake input events with CGEvent, the Core Graphics event API. On its own that is not enough. For those events to land reliably in other applications, the app has to be trusted for Accessibility through the AXUIElement family of APIs, the same control layer that screen readers and automation tools use to drive the entire interface. Watching the keyboard the other direction, to know when your hotkey is pressed while another app is focused, can pull an app toward Input Monitoring, the permission macOS uses to gate anything that observes your keypresses system wide.
Read that list again from the point of view of someone deciding what to install. An app that can see every key you press and enter text into any window is asking for exactly the capabilities a keylogger would want. There are good and honest apps that need those permissions, and macOS makes you grant each one by hand for that reason. But for a dictation tool it is a large amount of trust to ask for what is, in the end, a convenience.
Apple’s own review guidelines treat the Accessibility APIs as reserved for accessibility. An app that reaches for them to move text around is using them for something they were not meant for, and that is a common reason a Mac app is turned away.
The clipboard is a different kind of request
The clipboard is the part of macOS built precisely for moving a piece of content from one place to another. An app writes text to it through NSPasteboard, and that call needs no special permission at all. It works from inside the App Sandbox, the container that limits what an app can touch, without any exception.
The difference that matters is the last step. When an app copies text for you, nothing has entered your document yet. You press Command and V, and you decide where the words go and when. That one keystroke is a small piece of friction, and it is also the whole point. The app never touches another application. It hands you the text, and you place it.
That single design choice removes the entire pile of permissions above. No synthetic events, no Accessibility trust, no input monitoring. The clipboard hand-off is boring in the best way.
The only permission a dictation app really needs
Strip the problem down and a dictation app has one genuine requirement. It needs to hear you. That means the microphone, and macOS already has a clear, visible way to ask for it, the same authorization prompt every app must go through to record audio. You see the request, you grant it or you do not, and a menu bar indicator shows you when the mic is live. Recording the audio uses AVAudioEngine, Apple’s standard audio framework.
The transcription can stay on the Mac too. Speech to text used to mean sending audio to a server, but that is no longer necessary. OpenAI’s Whisper speech recognition model can be compiled to run on device, and open projects like WhisperKit run it through Core ML on Apple’s Neural Engine. The model ships inside the app. There is no account, no upload, and no network call. An app built this way can leave the network permission out of its sandbox entirely, which means the system will refuse any connection it might attempt, on purpose.
Add it up and the honest version of a dictation app asks for one thing, the microphone, and hands its results to you through the clipboard. It never types into another app, it never watches your keyboard system wide, and it never sends your voice anywhere. What it gives up is the half second it takes you to press Command and V. What it keeps is a permission list short enough to read in a sentence.
The tradeoff, stated plainly
Typing text in for you is genuinely more convenient. Pretending otherwise would be dishonest. But the cost of that convenience is a set of permissions broad enough that you have to take the app entirely on faith, and a design that reaches into every other app on your Mac. The clipboard costs you one keystroke and asks for none of that.
For a tool whose entire promise is that your voice stays private, the clipboard is not a compromise. It is the design being consistent with the promise. It is the approach we take in our own dictation app. You press a key, you speak, and the text is waiting on your clipboard for you to paste wherever you want it. The only thing it ever asks for is the microphone, and nothing you say leaves your Mac.