Listening to a keyboard that isn't yours
The defining interaction of modern dictation is a global hotkey: hold Fn or Right Option (or your key of choice) in any application, speak, release, and text lands where your cursor is. 'Global' is the hard part. Normally, key events go only to the focused application. A hotkey that works everywhere requires the OS to hand your keystrokes to a background app even while you're typing into someone else's window.
On macOS this is an event tap: the app registers with the system to observe — and optionally intercept — the stream of HID events. Windows offers low-level keyboard hooks and the RegisterHotKey API. Linux splits by display server again: trivial on X11, restricted to specific portal APIs on Wayland. In every case it is the same capability a keylogger needs, which is why it is permission-gated everywhere.
Push-to-talk versus always-listening
Two interaction models dominate. Push-to-talk holds the microphone open only while the key is held: no accidental capture, no 'the app heard my meeting' moments, and a natural boundary for the voice-activity detector. The alternative, wake-word or toggle mode, trades that safety for hands-free operation — essential for accessibility users, risky for everyone else's privacy expectations.
The best apps let you hold-to-talk and double-tap-to-lock on the same key, giving both modes without a settings trip. When comparing apps, test the hotkey in your actual workflow for a day: whether you can reach the key while mousing, whether it conflicts with your IDE or window manager bindings, and whether the app intercepts the key cleanly (so Fn doesn't also trigger its system function) are the details that decide whether dictation becomes a habit.
The three permissions on macOS — and what each one is for
A Mac dictation app typically asks for three separate permissions, and each maps to a real subsystem. Microphone is obvious: no audio, no dictation. Input Monitoring covers the global hotkey — the ability to observe keystrokes while other apps are focused. Accessibility covers text injection — the ability to read and write other applications' text fields, as covered in our injection guide.
Windows folds most of this into standard app capabilities with far fewer prompts, which is smoother to set up and weaker in isolation guarantees. Neither approach is obviously right; they are different answers to the same uncomfortable fact that a dictation app needs powers we usually associate with malware, granted on trust.
Why it breaks after updates
The classic failure — 'my dictation app stopped working after the macOS update' — is permission revocation. macOS ties permissions to a specific signed build of an app, and major OS upgrades (and occasionally app updates with changed signatures) reset or orphan those grants. The app keeps running, but its event tap or accessibility handle silently fails, so the hotkey does nothing or text never lands.
The fix is always the same: open System Settings → Privacy & Security, remove the app's entries under Accessibility and Input Monitoring, re-add them, and restart the app. Vendors hate this ritual as much as users do — it is the single largest source of support tickets in the category — but it is the price of the OS treating a background app that watches your keystrokes with appropriate suspicion.
References
- Apple — CGEventTap and event monitoring — how global hotkeys are observed on macOS
- Microsoft — RegisterHotKey and low-level hooks — the Windows hotkey APIs
Frequently asked questions
Which hotkey should I use?
Whatever your muscle memory tolerates holding — the defaults (Fn on Mac, a side mouse button or Right Ctrl elsewhere) are chosen because they're reachable and rarely bound. Avoid keys your IDE, window manager or password manager already claims.
Is it safe to grant these permissions?
They are powerful grants — the same capabilities spyware wants. Grant them to apps from vendors you trust, prefer open-source builds if you want auditability, and review the list in Privacy & Security periodically.