8 Mac Apps Where Autocorrect Doesn't Work (And What to Do)

macOS autocorrect only works in apps built with Apple's native text framework (NSTextView). Eight popular apps bypass this, leaving users without correction in their most-used tools. The reason is almost always the same: Electron. Around 73% of popular Mac productivity apps are built on Electron, which uses Chromium rendering and bypasses NSSpellChecker entirely.

1. Slack (desktop)

Slack desktop is the most-used Electron app on Mac and the clearest example of the autocorrect gap. The app uses Chromium rendering for its entire interface, which means Apple's NSSpellChecker has no access to any text field inside it - not the message compose box, not thread replies, not the search bar.

The consequence is significant: for many professionals, Slack is their highest-volume writing environment. More words go through Slack than through email, documents, or any other single app. Leaving that environment without correction means the most frequent writing context is the least protected one. The fix is Charm, which uses the macOS Accessibility API to reach Slack's text fields directly. Charm works in Slack in exactly the same way it works in native apps: real-time spelling correction with a cyan glow, grammar correction at sentence boundaries with a blue glow.

2. VS Code

VS Code is an Electron app and the same rule applies: no NSSpellChecker access, so no macOS autocorrect. For code this is arguably desirable - autocorrect changing variable names or command syntax would be actively harmful. For prose in VS Code, it is a genuine gap.

Developers write a significant amount of prose in VS Code: inline comments, docstrings, README files, commit messages, documentation. None of that text is covered by macOS autocorrect. The recommended setup is two-part: the Code Spell Checker extension for code-aware spelling (it understands camelCase and identifiers), and Charm via the Accessibility API for prose text like comments and documentation. They complement each other without interfering.

3. Discord

Discord is Electron-based and has no macOS autocorrect support. Like Slack, it is a high-volume conversational environment where errors are visible to communities and colleagues. The absence of any correction layer means every message goes out exactly as typed - typos, grammar errors, and all.

The fix is the same as Slack: Charm via the Accessibility API. Once Charm is installed and given Accessibility permission, it works in Discord's message compose fields without any additional configuration. The per-app setting in Charm's menu bar can be used to adjust which features are active in Discord specifically - for example, disabling word prediction if the Tab key is used for other purposes in that context.

4. Notion (desktop)

Notion's desktop app is an Electron wrapper around its web interface. macOS autocorrect has no effect in it. Users who write extensively in Notion - notes, documents, wikis, project plans - are doing so without any system-level correction.

Two practical options: use Notion in a browser (Chrome or Safari), where browser-level correction and Charm both work; or use Charm's desktop coverage via the Accessibility API. The browser approach works well for most Notion use cases. The desktop app offers a marginally cleaner experience, but from a correction coverage standpoint the browser version is better equipped.

5. Linear

Linear, the project management tool popular with engineering and product teams, is an Electron app. Issue titles, descriptions, comments, and updates written in Linear desktop receive no autocorrect coverage from macOS. Given that Linear is used for professional communication - writing that is read by teammates and sometimes shared externally - the absence of correction is a genuine quality risk.

The fix is Charm, which works in Linear via the Accessibility API in the same way it does in Slack and Discord. For teams using Linear heavily, this is one of the less obvious Charm use cases that turns out to be one of the more valuable ones - issue descriptions and comments are consequential writing that gets read repeatedly, and errors in them reflect on the quality of the team's work.

6. Figma (desktop)

Figma's desktop app is Electron-based. While most Figma text is design labels and layer names rather than prose, designers do write substantive text in Figma: component descriptions, annotation text, client-facing copy in designs, and text in presentation frames. None of that is covered by macOS autocorrect in the desktop app.

Charm catches description field text and annotation prose in Figma desktop via the Accessibility API. This is more useful for designers who use Figma for presentation and documentation work than for those primarily moving shapes and components. The per-app configuration option means Figma can be tuned independently - for example, enabling spelling correction for prose fields while the overall Figma workflow otherwise focuses on visual work.

7. 1Password text fields during secure input

This one is different from the others. 1Password is not blocked because it is an Electron app - it is blocked because of secure input mode. When you click into a password field in 1Password or any password manager, macOS activates secure input, which blocks all Accessibility API access as a security measure. This protects password entry from keyloggers and screen-reading tools - including legitimate ones like Charm.

The result: autocorrect, word prediction, and all Accessibility-based correction tools stop working while a password field is focused. This is correct behaviour by design. The fix for any text you want corrected in this context is to write it first in a different field - a note, a text editor - and paste it into the secure field. Do not work around secure input mode; it exists to protect sensitive data.

8. Any app using secure input mode

The secure input pattern extends beyond 1Password to any app that handles sensitive credential entry: banking apps, financial tools, enterprise login systems, and any native app that calls the macOS secure input API during password or PIN entry. While secure input is active, all Accessibility-based tools are blocked system-wide - not just in the specific app, but across every app on the screen until the secure input field loses focus.

If Charm appears to stop working intermittently with no obvious cause, a lingering secure input lock from a background app is a likely explanation. Switching focus away from the secure field - clicking elsewhere, switching apps - releases the lock and restores normal Accessibility API access. This is a macOS security architecture constraint, not a bug in any individual app.

Frequently asked questions

Why doesn't autocorrect work in Slack?

Slack desktop is built on Electron, which uses Chromium rendering rather than Apple's native text framework. macOS autocorrect uses NSSpellChecker, which only works with native text components. Electron apps bypass this entirely. Charm uses the macOS Accessibility API to reach Slack's text fields specifically, providing real-time correction where standard autocorrect has no effect.

What Mac apps don't support autocorrect?

The main apps where autocorrect doesn't work: Slack desktop, VS Code, Discord, Notion desktop, Linear, and Figma desktop - all Electron apps. Any app in secure input mode (password managers and banking apps during credential entry) also blocks all correction tools by design. Around 73% of popular Mac productivity apps are Electron-based.

How do I get autocorrect in VS Code?

For code: use the Code Spell Checker extension, which understands camelCase and variable names. For prose (comments, docs, README files): Charm works in VS Code via the Accessibility API and provides real-time spelling and grammar correction for non-code text. The two tools complement each other without conflict.

Does autocorrect work in Notion desktop?

No. Notion desktop is Electron-based and macOS autocorrect has no effect in it. Alternatives: use Notion in a browser where Charm and browser-level correction both work, or install Charm which covers the Notion desktop app via the macOS Accessibility API in the same way it covers Slack and Discord.

Why does autocorrect stop working in some windows?

Two reasons: the app is Electron-based (not Apple's native text framework), or the app has triggered secure input mode. Secure input mode is activated by password fields and blocks all Accessibility API access as a security measure. Clicking away from the secure field releases the lock and restores normal correction across all apps.