MSIME runs one Rust input engine behind six native Chinese input method hosts

One engine, six native hosts

MSIME, 水杉输入法, is a multi-platform Chinese input method covering Android, iOS, macOS, Linux, Windows and HarmonyOS, written primarily in Rust and licensed GPL-3.0-only. The project homepage is msime.app, and the repository's default branch is develop, with the last push on 2026-10-20.

The architecture is the interesting part. Each of the six platforms has its own native input method host, and all of them connect to one shared input runtime. The platform host is what the operating system actually recognises as an input method: the Android input method service, the iOS keyboard extension, and the macOS input method entry, with the same pattern for the other three. The input algorithm itself comes from msime-engine.

The README is explicit that Tauri is a shared component and not the product body of any platform. What is installed, launched and registered with the system is always the native host under platforms/<os>, and Tauri and React only host shared panels on the platforms that use them.

That decision shapes everything else, including where the settings screens live. The rationale is straightforward: an input method has to be a first class citizen of each operating system, and the parts that can be shared are shared.

The release history shows the same structure at the packaging level. There are per platform tags, with macos-v0.54.0 published on 2026-10-19, a macos-symbols dSYM artifact the following day, and a nightly build published on 2026-10-15. The README badges for each platform read the version from that platform's version.txt file, so the version of every platform is visible in the repository at any time.

Settings ownership differs by platform, and the README admits the seams

The settings story is where a shared engine meets six different operating systems, and the README describes the arrangement with some candour.

macOS, Linux and HarmonyOS share one React settings page. Windows, iOS and Android each have their own native settings interface. The stated rule is that business rules should live in the shared Rust layer and the platform interfaces should only handle the interface, and the README notes that some rules are still written in the native interfaces.

How the shared page is reached also differs. On macOS and Linux, the React settings page calls the plain Rust business library through Tauri. On HarmonyOS it does not go through Tauri at all: the page is packaged as a rawfile, loaded by ArkWeb, and the ArkTS native bridge calls Rust through NAPI.

The Windows arrangement is the most tangled, and the README spells it out rather than glossing over it. The Windows published package has a native settings program, msime-client-settings.exe, which the tray and the start menu open, and requests that do not involve a panel also open it. The React settings page still ships with the Tauri application MSIME.exe and can be run directly, but no settings entry points to it.

There is a second thing worth noticing on iOS and Android: those published packages do not include the React pages at all.

The shared panels that Tauri does host, on the three desktop platforms, are emoji and symbols, handwriting, the on-screen keyboard, voice, the cloud dictionary and the cloud clipboard.

A dependency direction that keeps the libraries free of the user interface

The crate layout is the clearest statement of the design discipline, and the README gives it as a set of module boundaries rather than a list of directories.

The four host independent client crates have a strict dependency direction, base to core, then core to services and core to providers. None of the four depends on Tauri, on a user interface, or on a platform host.

client-base holds storage, file locks, text predicates, calendar handling and simplified to traditional conversion. client-core holds local configuration and versions, themes, punctuation, the clipboard, translation, the cloud candidate and cloud clipboard protocols, and the fixed resource generation install. client-services holds accounts and sessions, the community features, usage statistics, announcements, update checks, diagnostics, the clipboard relay, skins, plugins, dictionaries, common phrases and typing statistics. client-providers holds voice, service credentials, AI, and resource packages that are downloaded on demand.

The split is meaningful. The services layer is the part that talks to the network, and the core layer is the part that holds local state, so the boundary between them is also the boundary between what needs credentials and what does not.

Two more crates are deliberately outside that group. crates/input-runtime handles session orchestration, focus cancellation, candidate paging and selection tagged with a generation number, and the README notes that it does not duplicate the engine's composition state machine. crates/host-api is a versioned C interface with thread bound session handles and explicit response release, and all six platform hosts link it.

The engine was ported from C++ to Rust, and the toolchain is pinned

crates/engine, published as msime-engine, is a pure Rust input engine. The README describes it as handling composition state, the various input schemes, dictionary lookup and learning replay, and states that it was ported from the original C++ MSIME-Engine.

A port of this kind is where the interesting engineering risk sits, because the behaviour of an input method is a set of subtle rules about composition, candidate ordering and learning, and a port that changes any of them is not a port. The separate input-runtime crate, which explicitly does not duplicate the engine's composition state machine, is a sign that the boundary between the two was drawn deliberately.

The toolchain is pinned and modern. The workspace package sets edition 2021 and rust-version 1.89, and the README badge says Rust 1.89 or newer. The Cargo workspace lists twenty members, with a default-members list that excludes the desktop application so that a bare cargo test covers the libraries, and the comment in the manifest explains why: msime-desktop needs a built frontend and a packaged platform bundle before its build script will run.

That is a small but telling piece of engineering. A workspace where one member cannot be tested in isolation is a workspace where a newcomer runs cargo test and gets a confusing failure, so the default member list removes that case.

Continuous integration is split in the same spirit, with separate badges for a Core CI workflow and a Native Platform CI workflow, plus scheduled CodeQL and cargo audit runs. The repository also carries a fuzz/ directory, a flake.nix for reproducible development environments, a rust-toolchain.toml, and an .oss-scanner/ directory for software supply chain checks.

The privacy defaults are the part worth reading twice

The README states the question directly, because an input method can see everything you type, and then points at a document, PRIVACY.md, that answers it item by item.

The short version is in the README. With a fresh install and the default configuration, no feature sends what you type off the device. Cloud candidates, which send the pinyin you are composing to Google's input tools, only work if you accept the first prompt or turn them on in settings. The other network features need you to supply your own credentials or choose a service before they do anything.

There is one outbound flow that is on by default, and it does not carry what you type. All six platforms send daily active user, session and crash records, where a crash record is an error summary plus a call stack with directories removed, to api.msime.app. You can turn it off in the settings, under the anonymous usage statistics entry, and PRIVACY.md lists the fields, the per platform differences and where the data is written to disk. The repository does not integrate any third party analytics or crash reporting SDK.

That is a better answer than most input methods give, and it is worth noting that it was answered with a document rather than a promise. The same transparency is applied elsewhere in the README, for example in the note that the name MSIME is short for Metasequoia IME and has no connection to Microsoft, and that the shuangpin_profile named microsoft is the Microsoft Shuangpin key layout, one of five layouts alongside Xiahe, Ziranma, Shoudao and Smart ABC.

Where MSIME is the wrong choice

Three cases rule it out.

The first is a project that only needs one platform. The whole point of the design is that one engine serves six hosts, and the cost of that is six native code paths to test, six release streams to watch and six sets of platform specific behaviour. If you need a Chinese input method on one system, a platform native implementation of the same scheme will be smaller, easier to build and easier to reason about.

The second is a fork. The licence is GPL-3.0-only, which is fine for people using the input method and awkward for a vendor who wants to embed a modified version in a product that is not otherwise GPL. The README links a code signing policy document for the Windows repository, which is a reminder that shipping a signed build is its own piece of work.

The third is a user who wants the cloud candidate feature without thinking about it. Cloud candidates mean sending what you are typing, in pinyin form, to Google's input tools, and the project is careful that this is opt in. A user who does not read PRIVACY.md and assumes the default is private may be wrong about the feature, and the project is right to make it explicit.

For the user who does read it, the picture is favourable. The engine is shared, the privacy defaults are conservative, the cloud features are opt in, and the anonymous statistics can be switched off, and the repository was last pushed on 2026-10-20 with per platform releases following the same day.

Editorial conclusion

MSIME fits a user or team that wants a Chinese input method with the same engine behaviour on Android, iOS, macOS, Linux, Windows and HarmonyOS, and who is willing to read the privacy document before turning on cloud features, because the defaults keep typed content on the device and the optional cloud candidate path is opt in. It is the wrong choice for a developer who needs a single platform implementation with a small maintenance surface, since each platform host is a separate native code path. Before adopting it, read PRIVACY.md for the data that leaves the device, check that your platform's release matches the version file for that platform, and note that the repository's default branch is develop with nightly and per platform tags, so pin a release rather than tracking the branch.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. metasequoiaime/msime on GitHub
3. Project website
4. README
5. Releases