vChewing-macOS: a native Chinese input method built in Swift

What the project is, and where the code actually lives

vChewing is a third-party native Chinese input method for macOS, offering native simplified Chinese and native traditional Chinese with phonetic and pinyin input. The repository description calls it possibly the most feature-rich free third-party macOS input method, and the README explains the ambition: to make the whole product as usable as possible within what is achievable, paired with dedicated simplified and traditional Chinese lexicons.

The most important practical detail is the split between GitHub and Gitee. The README states that the repository can only guarantee that the latest content is available on Gitee, and gives the Gitee release download page and the Gitee code repository. Everything about how the project is developed and managed is conducted on Gitee, while the GitHub repository is where the mirror and the English-facing writing live.

The homepage is vchewing.github.io, and the README directs readers to the product page for the latest information about both the repository and the input method. There is also a Simplified Chinese version of the README alongside the Traditional Chinese original.

The primary language is Swift, the default branch is main, the last push was on 2026-10-20, and the recent releases are 4.9.1 from 2026-10-15, 4.9.0 from 2026-10-14 and 4.8.8 from 2026-10-11. The project is not archived, and the release cadence is steady.

The repository tree is large and tells you what a modern macOS input method project contains: vChewing.xcodeproj/ and a vChewing-Packages.code-workspace file at the root, Sources/, Packages/, Plugins/ and DevLab/, a LegacyZone/ directory, Scripts/ and ValueAdd/, localisation resources, and an AGENTS.md, a CLAUDE.md and a CONTRIBUTING.md alongside the code. There is also a COPYING file and separate licence files for Simplified Chinese, Traditional Chinese and Japanese locales.

The input methods: phonetic, pinyin and the double-pinyin claim

The feature list in the README is where the product differentiation is claimed, and the first item is a quantitative one. The project states that it is the phonetic input method supporting the greatest number of phonetic arrangements and the greatest number of input pinyin types in the industry, thanks to its own phonetic-and-character parallel input engine, and that unlike the reference implementation based on the standard arrangement it achieves a genuinely large parallel input across the full set of characters.

The pinyin side has a similar claim. There is a pinyin parallel input mode so that people who do not know phonetic symbols can still benefit from the stable average typing speed the method brings, and the comparison with a two-key pinyin scheme such as the small-crane variety is that the division of labour between the two hands is clear and the duplicate-code rate is only one fifth of that of a two-key scheme. The duplicate-code rate is the metric that matters here, because a two-key scheme has to resolve more collisions.

There is also a mode the README calls the rapid pinyin mode, which inherits the typing experience of the intelligent rapid pinyin and Sogou pinyin approaches once the pinyin typing mode is enabled.

Compatibility is treated as a first-class feature. The input method is fully compatible with the mainland phonetic arrangement, so users unfamiliar with the Taiwan, Penghu, Kinmen and Matsu arrangements encounter no difficulty with character readings, and the reverse is also true. There is an on-screen simulated keyboard, but only for the traditional large and traditional Yi layouts, which is the kind of detail that shows the layouts are not treated as an afterthought.

Output conversion is a separate axis again. Traditional Chinese typed by the user can be output automatically converted to Japanese JIS new characters, including basic word conversion, or to the Kangxi forms. And the simplified and traditional corpora are kept separate, which the README says eliminates the errors that any conversion process can cause.

Sandboxing, the composition area and the Shift key question

The security section of the README is specific, and it makes two claims that are unusual to see in a project like this.

The first is that vChewing is the safest third-party Chinese input method for macOS, for two reasons. It has the Sandbox feature enabled, so in principle it cannot obtain global keyboard access, unlike third-party input methods that do not enable it. And it has a hardened composition area protection mode, which prevents software that receives typing from accessing the contents of your composition area ahead of time.

The second is a dedicated statement about the Shift key monitoring feature. The README says it is implemented only by observing the contextual relationships of the NSEvent signal stream, touching only the NSEvent stream delivered by the IMKServer built into macOS, without listening to system-wide keyboard events and without requesting the auxiliary permissions that such behaviour might raise security concerns about, and without transmitting any of your data anywhere. The Sandbox feature introduced in version 2.3.0 removes that possibility entirely.

The Shift key mode switch requires at least macOS 10.15 Catalina. That is a small constraint, but it is stated rather than assumed.

For an evaluator, the honest reading is that the sandbox claim is architectural rather than a promise, and the shift monitoring claim is a design commitment that can be checked by inspecting what the process asks for. The composition area protection is the piece that matters most in practice, because it is the difference between your in-progress text being readable by other software or not.

Building it: Swift 6.4, Xcode 27, and the Intel Mac problem

The build requirements are the most demanding part of the project, and the README is unusually thorough about them, because the current state is genuinely awkward.

Swift 6.4 or newer is a hard floor, with two ways to satisfy it. Either Xcode 27 or newer, which requires macOS 26.6 or newer, or Xcode 26.x, which is the last generation usable on an Intel Mac, plus a separately installed Swift 6.4 open-source toolchain.

The catch is spelled out in detail. Xcode cannot use a separately installed open-source toolchain to resolve a Swift package, because its package resolution is fixed to its own built-in toolchain. So on an Intel Mac, where Xcode tops out at 26.x with a built-in Swift below 6.4, this repository can no longer be built with Xcode at all. It can only be built from the SwiftPM command line, with targets such as make spmDebug and make release and a 6.4 or newer toolchain. Apple silicon is unaffected. The reason given is that Swift 6.x only supports 6.4 and above, and the 6.2 and 6.3 packages are explicitly refused by a blocking manifest in the repository, because those versions demand an explicit main-actor conformance for default-isolated downstream conformance, and the dependency closure has no usable product shape under them.

The make targets for that path are short:

spmDebug:
	swift build -c debug

spmRelease:
	swift build -c release

The main build flow is otherwise the familiar one. You configure Xcode to allow it to build directly into the build folder under the project directory, by choosing Preferences then Locations, then File then Project or Workspace Settings then Advanced, and picking Custom then Relative to Workspace, and the README warns that the make process will fail if you skip this.

Then, in the cloned repository, make update fetches the latest lexicon resources using a remote Swift Package plugin, make release builds the universal binary for arm64 and x86_64 into Build/Products/Release/, make archive produces an .xcarchive with dSYM into the Xcode Archives directory, and make debug is a fast single-architecture debug build. You can also open the Xcode project directly and build the vChewingInstaller scheme.

There is a legacy path for building installers for macOS 10.9 to 10.10, which needs Xcode 15, a MacOSX13.3.sdk and a Swift 5.10.1 open-source toolchain, driven by make debugLegacy, make releaseLegacy and make archiveLegacy, and it is explicitly for local use only and is not part of continuous integration.

The configuration assistant, and why it needs no Node

The configuration assistant lives in the ValueAdd/WebConfigAssistant/ directory and is written in TypeScript, compiled into a single self-contained assistant.html that is an interactive setup wizard running in the browser and generating configuration packages that can be imported into vChewing. Its own README in that directory covers the details, and the root README only covers how it relates to the build.

The relationship is deliberately loose. It is not a build dependency of the input method itself: without building it, make debug, make release and make archive all work exactly as before. When tsc is detected on the path, those targets, plus the legacy targets and the Xcode project, additionally compile the assistant and bundle it into the app at the assistant resource path inside the application bundle. When tsc is not detected, a warning is printed, the input method build is not interrupted, and the resource is not bundled. So if you find the assistant missing from the app, the README's advice is to check that tsc is on the path.

The dependency story is the part that is worth noting. The development environment needs exactly one thing, tsc, the native executable from TypeScript 7, and neither node nor npm is required. The reason is that the npm version of tsc is a launcher that starts with a shebang pointing at node, so using it would mean still depending on node, and the make check-tsc target detects that by inspecting whether the executable starts with a shebang and blocks it.

Since a certain phase, the assistant's build chain uses JXA on macOS, with osascript running JavaScript, as the JavaScript host instead of Node. The native tsc can be obtained by three routes, the npm registry platform package, GitHub Releases, or NuGet, and the assistant's own instructions give the steps.

The assistant can also be built on its own, by changing into the ValueAdd/WebConfigAssistant directory and running make bundle to produce the dist/assistant.html, with make audit as a pre-commit check and make serve for a local preview.

Licensing, history and the parts that are not in this repository

The application licence is the Mulan Public Software License, version 2.0, MulanPSL-2.0, released by the vChewing project with the copyright years 2021 to 2022, and the full text is in the LICENSE.txt file in the repository.

The component licensing is where the interesting detail is, because the engines are licensed differently from the application. The phonetic parallel input engine is by Shiki Suen under LGPL v3.0 or later, with the Swift App Development exception. The composition engine, Homa, is by the same author under the same terms. The vChewing lexicon, the pioneer corpus, is also maintained by Shiki Suen and released under MulanPSL-2.0, and the README notes that the word frequency data inside it comes from elsewhere, with the compliance of that source data explicitly outside the maintainer's responsibility before it is organised into the pioneer corpus.

There is a separate note about the fork projects and the lexicon, which are maintained by Shiki Suen and whose content is legally distributable and can be publicly shown on Gitee, and the same disclaimer applies to the original data before it was tidied into the pioneer corpus.

History has its own repository. The records for the input method before version 4.1.3 are all kept in a separate repository named vChewing-macOS-AncientArchive, which is a clean way to keep the working tree readable.

The README also opens with a dedication, commemorating Chiien-Hua Chi, 1921 to 2001, and the repository carries an AUTHORS file, a CREDITS file, a FUNDING.yml and a code-of-conduct.md. The Makefile contains targets for generating a keyboard shortcut manual as a set of HTML pages, with a generator written in Swift that needs only swift on the path and does not participate in any build, and it works entirely offline. The make shortcuts target checks for the homepage repository and falls back to the synchronised copy in this repository when it is absent, and there is a check variant and a list variant.

Editorial conclusion

Adopt vChewing if you type Chinese on macOS and want a native input method with a real phonetic engine rather than a pinyin approximation, and if you care about how the input method handles your keystrokes and your composition buffer. Do not adopt it expecting a turnkey build, because Swift 6.4 is a hard floor and on an Intel Mac the project can no longer be compiled with Xcode at all, only from the SwiftPM command line. Before you commit, read the security section on the sandbox and the composition area protection, confirm that the Gitee repository rather than the GitHub mirror is where you get the current code, and check the MulanPSL-2.0 and LGPL component terms in LICENSE.txt if you intend to redistribute anything built from it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vChewing/vChewing-macOS on GitHub