A lot of Mac AI writing tools make the same promise in different words:
Works anywhere you type.
That sounds great, but it is not completely honest.
On macOS, a writing assistant that helps inside other apps usually depends on Accessibility APIs. That is the system layer that lets approved apps inspect focused UI elements, read selected text when an app exposes it, and send input back into a text field.
That unlocks useful workflows, but it also creates real limits.
The happy path
The best case is a normal macOS text field.
Think about places like:
- Apple Notes
- TextEdit
- browser text areas
- many standard native input fields
In those places, a writing assistant can often detect the focused field, understand the selection, and apply a rewrite or continuation without making you copy text into a separate web app.
That is the workflow I care about most.
You are writing an email, issue comment, note, support reply, or product copy. You select a rough sentence, ask for a cleaner version, review it, and keep going in the same app.
No chat window. No paste round trip. No new document just to fix one paragraph.
Where it gets messy
Not every app exposes text the same way.
Some apps use custom editors. Some web apps wrap text in complex JavaScript surfaces. Some Electron apps expose enough information through Accessibility. Some do not. Some fields look like normal text boxes visually, but behave differently under the hood.
This is why any serious Mac writing tool should be careful with the word "anywhere."
A better promise is:
Works in compatible macOS text fields.
That phrase is less flashy, but it is more accurate.
Why this matters for AI writing UX
If the app can work in the existing text field, the whole writing flow changes.
You do not need to decide whether a sentence is important enough to move into ChatGPT. You do not need to create a scratch doc. You do not need to remember which version was the original and which version was the AI rewrite.
The field you are already using stays the source of truth.
That matters for small edits. Most writing help is not a giant generation task. It is usually:
- make this sound less stiff
- tighten this paragraph
- continue this thought
- rewrite this reply more clearly
- make this less awkward
Those are tiny interventions. If the tool forces a context switch, it often costs more attention than it saves.
Local AI adds another constraint
Running AI locally on a Mac is also not magic.
It means the app needs a capable machine. It means there may be a model download. It means the result depends on local resources instead of a huge cloud model hidden behind an API.
But the tradeoff is meaningful for writing.
A lot of the text people want help with is private before it is polished: emails, notes, drafts, internal docs, support replies, personal writing, half-formed thoughts.
For that kind of work, keeping assistance on the device is not a gimmick. It is a product decision.
What I built
I built DraftKey around this exact shape of workflow: private, on-device AI autocomplete and instruction-based rewriting inside compatible macOS text fields.
It is a native Mac app for Apple Silicon Macs, and it is designed for the small writing moments where opening a separate AI chat would break flow: https://www.getdraftkey.com/
It also includes mechanical keyboard typing sounds, which is admittedly a different kind of feature, but it fits the same idea: make writing on the Mac feel better without moving your work somewhere else.
The honest version of the promise
The strongest version of Mac AI writing is not "AI that replaces your editor."
It is AI that stays close to the field you are already using, respects the limits of macOS, and gets out of the way when you ignore it.
That means being honest about compatibility.
It means the user should review every change.
And it means the best writing assistant might not be a giant blank AI document at all.
It might be a small local layer next to the words you were already typing.
Top comments (0)