Why Mac Spell Check Stops Working in Some Apps

Mac spell check works in native Apple apps but disappears entirely in many of the most popular productivity, developer, and messaging tools on macOS. This is not a glitch or a settings problem. It is an architectural boundary: macOS spell check is built into Apple's text framework, and any app that does not use that framework is completely outside its reach. Understanding why explains what you can - and cannot - do to fix it.

Why does macOS spell check only work in some apps?

macOS spell check is implemented as a component of AppKit - Apple's native application framework. Specifically, it is integrated into NSTextView, the component that provides editable text areas in native Mac applications. When you type inside an app that uses NSTextView - which is the case for Apple's own apps such as Mail, Notes, Pages, and TextEdit, as well as many third-party apps built natively for Mac - the spell checker can see your keystrokes, monitor the words you type, and annotate misspellings.

The key phrase here is "apps that use NSTextView." NSTextView is not a universal standard. It is Apple's own implementation, used by apps that choose to build natively for macOS using Apple's frameworks. An app that does not use AppKit - that is, one that uses a different framework to render its user interface - never touches NSTextView at all. To that app, macOS text services simply do not exist.

The result is a clear split. Apps built natively for macOS - using AppKit and NSTextView - have spell check. Apps built on other frameworks do not. This division is not visible to the user: the app might look and behave like any other Mac app, but its text rendering is happening in an entirely different stack.

What kinds of apps bypass macOS text services?

The most prevalent category is apps built on the Electron framework. Electron is a toolkit that allows developers to build desktop applications using web technologies (HTML, CSS, JavaScript) by packaging a Chromium browser engine inside a native app shell. The application you see on screen looks like a Mac app - it has a window, a menu bar, and a dock icon - but everything inside the window is rendered by Chromium, not by AppKit.

Chromium has its own text rendering pipeline. The text fields inside an Electron app are web-based text fields, rendered by a browser engine. macOS text services - including spell check - have no mechanism to inject themselves into a Chromium rendering pipeline. They are two separate systems that do not communicate.

Studies on professional Mac usage suggest that knowledge workers spend more than 60% of their active typing time in non-native applications. The category of apps affected by this limitation is not a niche: it includes a broad swath of the productivity tools, developer environments, messaging platforms, and project management apps that professionals use all day.

Beyond Electron, other non-native frameworks present the same issue:

• Qt-based apps: Qt is a cross-platform C++ framework. Apps built with Qt render their own UI components using Qt's own graphics engine. macOS text services cannot access Qt text fields.
• Java Swing and JavaFX apps: Java's desktop UI toolkits render controls using the Java Virtual Machine's own graphics stack. They are outside the AppKit layer and invisible to macOS text services.
• Flutter for desktop: Flutter renders its entire UI using its own rendering engine (Skia or Impeller). Text fields in Flutter apps are drawn directly by Flutter, not by AppKit.
• React Native for desktop and similar web-based wrappers: Any framework that relies on web rendering (WebKit or Chromium) rather than native AppKit components will bypass macOS text services.

Some apps in these categories implement their own spell checking - a spell checker built into the app itself rather than relying on the OS. Many do not. When an app provides no spell checking at all, users are left writing in a completely unassisted environment.

Is this something Apple can fix?

This question comes up often among frustrated users, but the answer is no - not without the cooperation of the app developers.

macOS text services are designed to work with apps that opt in to the AppKit text framework. Apple cannot force a third-party rendering engine (such as Chromium) to route its text through Apple's spell checker - that would require Apple to modify another company's software. And even if Apple could inject macOS text services into a Chromium rendering pipeline, the behaviour could break or conflict with Chromium's own text handling in unpredictable ways.

The only path to spell check inside a non-native app is either for the app developer to implement their own spell checking, or for a tool to operate at a level below the application layer - below the point where AppKit versus Chromium makes any difference at all.

This is exactly why Charm takes the approach it does.

How does Charm fix spelling in every app?

Charm uses CGEventTap - a macOS kernel-level API that intercepts hardware input events before they reach any application. The critical word here is "before." CGEventTap sits in the input event pipeline below the application layer. When you press a key, the keystroke flows through CGEventTap before it arrives at any app, regardless of which app is frontmost and regardless of which text framework that app uses.

This means Charm sees every keystroke typed on your Mac. It does not matter whether the active app uses AppKit, Chromium, Qt, Flutter, or anything else - at the level where CGEventTap operates, those distinctions do not exist. All input passes through the same kernel event pipeline.

When you complete a word (by pressing a space, a return key, or a punctuation character), Charm evaluates the word against its correction models. If it identifies a misspelling, it uses the macOS Accessibility API to inject the corrected form in place of the original. The process completes in under 200 milliseconds. A brief cyan glow around the corrected word is the only visible signal, and writing continues without pause.

Because CGEventTap operates at the kernel level, below the application framework layer, Charm's coverage is universal. A messaging app built on Electron is just as fully covered as Mail. A developer tool built on Qt is just as fully covered as Xcode. A note-taking app built on a web-based framework is just as fully covered as Notes. The framework the app was built with is irrelevant.

A 2024 survey by the International Association of Privacy Professionals found that 68% of enterprise employees were unaware that productivity tools could transmit their keystrokes to third-party servers. Charm addresses the opposite concern: all correction processing happens locally on your Mac, with no data transmitted anywhere. The kernel-level access serves correction, not surveillance.

For a full explanation of how Charm's technical approach compares to macOS built-in tools, see the complete guide to spelling correction on Mac. To see what apps are affected by the macOS spell check gap and how Charm handles them, see how to get automatic spelling correction in every app.

Frequently asked questions

Why does Mac spell check not work in some apps?

macOS spell check is built into the AppKit text framework. It only works in apps that use Apple's native NSTextView components. Apps built on non-native frameworks (such as Electron or Chromium) provide their own text rendering, which completely bypasses macOS text services. There is no bug - it is an architectural boundary.

What types of Mac apps does spell check not work in?

Spell check does not work in apps built on Electron (which uses a Chromium browser engine), apps using Qt, Java-based UI frameworks, Flutter for desktop, or any other non-native rendering stack. These apps provide their own text pipeline that macOS text services cannot access.

Will Apple ever fix spell check to work in all apps?

This is not a bug Apple can fix. It is a boundary between two different architectural stacks. An app using a non-native text framework is responsible for its own text services. Apple cannot inject macOS text services into a foreign rendering pipeline without the cooperation of the app developer.

How does Charm make spell check work in every app?

Charm uses CGEventTap, a kernel-level macOS API that intercepts hardware input events before they reach any application. Because it operates below the application layer, it is framework-agnostic - it sees every keystroke regardless of which app is active or what text framework that app uses.

Is there a setting to make Mac spell check work in more apps?

No. There is no macOS setting that extends spell check to non-native apps. The only solution is a tool that operates at a lower level than the application framework - such as Charm, which uses CGEventTap to intercept keystrokes at the kernel level regardless of the active app.