Gõ Nhanh is a Vietnamese input method that treats English words and IDE latency as first class problems

One cask, and a promise of no ads and no data collection

Gõ Nhanh is a Vietnamese input method whose repository description calls it a modern, high performance input engine for macOS. The primary language of the codebase is Rust, and the licence is BSD-3-Clause.

The README makes three promises in one line, and they are the ones that decide whether you should try it: install it and use it, no advertisements, no data collection. For an input method, which sits between you and every keystroke you type, that last promise is the one that matters most, and the project backs it with a source you can read.

The project also presents itself as free software with a community around it, listing sponsors, code contributors and community members in the README, with the full list in CONTRIBUTORS.md. The release badges for macOS and Linux sit at the top of the file, and the project has a homepage at gonhanh.org.

What it is not is a general purpose input method for many languages. It is built for one language, on one platform, with the specific annoyances of Vietnamese typing on a Mac in mind. The feature list is short and every item is about a problem that Vietnamese typists recognise.

Homebrew cask for macOS, tarball for Linux, nothing yet for Windows

Installation on macOS is a single command, and the README marks Homebrew as the recommended route:

brew install --cask gonhanh

Updates are handled two ways. The app checks for a new version every 24 hours on its own, or you can manage the upgrade through Homebrew with:

brew upgrade --cask gonhanh

The download table shows three platforms with very different maturity. macOS is marked ready, with a GoNhanh.dmg download and an install guide at docs/install-macos.md. Linux x86_64 is marked beta, with a gonhanh-linux.tar.gz download and docs/install-linux.md. Windows is marked beta as well, with no download listed but a guide at docs/install-windows.md.

That table is the honest answer to the question of who should install this today. A macOS user gets a supported product. A Linux user gets something to try. A Windows user gets instructions but no binary, which in practice means building it yourself.

The install guides are in the repository under docs/, so the detail for each platform is there rather than on a separate site.

macOS will not let the app run until you clear the quarantine flag

The README has a troubleshooting section for the case where the app does not open on macOS, and the fix is a command you run in Terminal after dragging the app into Applications:

# Chạy lệnh này trong Terminal sau khi kéo app vào Applications
xattr -cr /Applications/GoNhanh.app

That clears the extended attributes, which is what the quarantine flag is, and it is the standard way to get a downloaded macOS application to start. The comment on the command explains the order: run it after the app has been moved into Applications.

There is a second step after that, and it is not optional. The README then points you to System Settings, Privacy and Security, Accessibility, and asks you to enable GoNhanh. An input method has to see and intercept keystrokes, and macOS treats that as an accessibility permission, so without it the typing hooks simply are not active.

The combination is worth expecting. A first-time install is a cask command, a drag, one Terminal line and one permission toggle. That is the whole onboarding, and it is the same path any input method on macOS has to take.

Auto-restore puts back the English words your keyboard mangled

The feature list leads with something called Highlight, and the first item under it is fixing the stuck text problem in Chrome, Spotlight, Arc, Claude Code and JetBrains, automatically correcting characters in the address bar, the search bar and the Arc history. The second item is auto-restore of English.

The auto-restore behaviour is specific and, for anyone who types in both languages, immediately recognisable. Typing text, expect, user, push or sort and then pressing space restores the English word automatically. The README describes it as typing the word, getting the Vietnamese form, and pressing space to get the original back.

There is a second route to the same result. Typing user, seeing the Vietnamese rendering, and pressing ESC returns the English word, and the README stresses that you do not have to turn the input method off to type English. That is the detail that separates this from a method where switching modes is a manual chore.

The third item in the list is a smart mode that remembers ON or OFF per application, and the README's example is the point of the feature: code in VS Code means off, chat in Slack means on, and the method switches by itself. For a developer who moves between an editor and a chat window all day, that is the feature that removes the most friction.

A per-app delay slider for editors that eat keystrokes

The second troubleshooting block in the README covers a specific and recognisable bug: characters being swallowed when using Claude Code inside an IDE such as VS Code, Cursor or Windsurf. The fix it gives is a four step procedure.

Open the menu bar icon for the app, go to the settings, and switch to the advanced tab. In the section for per-application customisation, press the plus button and pick the IDE you are using. Then drag the Delay slider to the right until it reads very high. The setting saves on its own.

The README then adds the caveat that matters for anyone deploying this across a team: every machine and every IDE has a different response delay, so the level has to be tuned for each case. That is an honest admission that the timing is machine specific rather than a fixed value baked into the app.

The root cause is worth understanding, because it explains the slider. The input method has to observe keystrokes and transform them, and an editor that processes input asynchronously can lose characters when the transformation is not fast enough. Rather than pretending the problem does not exist, the project gives you a knob that delays the transformation until the editor is ready. The Makefile also carries a perf target for checking RAM and leaks, and a debug log target, so the timing behaviour is something the project instruments.

A Rust core with per-platform shells and a Linux Fcitx5 build

The repository layout explains the architecture. The root holds core/, platforms/, scripts/, docs/ and assets/ directories, along with a Makefile, a package.json, a .env.example, a .mcp.json and a .claude/ directory.

The separation is the point: core/ holds the engine, platforms/ holds the per-OS integration, and the engine is Rust while the macOS side is a native app that needs the Swift tooling the Makefile mentions in its format target.

The Makefile is the best documentation of the development workflow, and it prints its own help. The development targets are test for the Rust tests, format for Rust and Swift, lint for clippy and swiftformat, build for a build that auto-opens the app, build-linux for a Linux Fcitx5 build, and clean. The debug targets are watch to tail the debug log, perf to check RAM and leaks, test-dict for the dictionary tests, test-22k for heavy 22k tests that also generate typing orders, and test-100k for English 100k tests. The install targets are setup, install and dmg.

Two of those deserve attention. The build-linux target tells you the Linux build is an Fcitx5 input method framework plugin, which is a completely different integration surface from the macOS accessibility based one. And the dictionary targets show the project measures its own coverage: the help text records the dictionary tests at 100 percent for Vietnamese and 97 percent for English, and the 22k and 100k runs are stress passes over the typing corpus.

Semantic releases, Apple notarisation, and a version number in the hundreds

The version numbering is unusual and worth understanding before you file anything. The recent tags are v1.0.165, v1.0.164 and v1.0.163, with v1.0.165 published on 2026-10-03 and the last push to the repository on 2026-10-20. The high patch number comes from the release automation: the package.json configures semantic-release with the commit analyzer, the release notes generator and the GitHub plugin, running on the main branch.

So the version does not mean what a version number usually means. There is no 1.1 or 2.0 in sight, because the project releases continuously and the counter simply climbs. What you should read is the commit history, not the number.

The macOS signing story is documented in the .env.example file at the root, which is where the release process details live. It expects an Apple team id, a code signing identity such as a Developer ID Application certificate, an Apple ID email and an app-specific password for notarisation, with the example values left empty for you to fill in. The file also names the command that lists your signing identities, security find-identity -v -p codesigning.

The licence is BSD-3-Clause, which is a permissive choice for a tool you may want to bundle or modify, and the presence of CONTRIBUTING.md and a .github/ directory means the project has a normal contribution path rather than ad hoc patches.

Editorial conclusion

Gõ Nhanh fits Vietnamese developers and writers on macOS who type English inside Vietnamese sentences every day, and who want an input method that restores English words instead of leaving them mangled, and it fits teams that want a free, ad-free, data-free input method they can install with one command. It is the wrong choice if you are on Linux or Windows and need a supported daily driver, since both are marked beta, and it is the wrong choice if you want the large word and phrase dictionary of a more established Vietnamese input method. Verify first that your macOS version opens the app after the xattr step, that the Accessibility permission is granted in System Settings, and that the per-app delay you set for your IDE actually matches its response time, since the README asks you to tune that slider per machine and per editor.

Frequently asked questions

Official sources

1. khaphanspace/gonhanh.org on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases