azooKey-Desktop: A Swift macOS IME Built Around the Zenzai Neural Converter
azooKey-Desktop is an open-source Japanese input method for macOS, written in Swift and powered by the Zenzai neural kana-kanji converter. It provides live conversion, optional LLM-based “Magic Conversions”, and Tuner-backed personalization for a smooth, desktop typing experience.
At a glance
- What is it?
- azooKey-Desktop is an MIT-licensed Japanese input method for macOS that replaces the usual dictionary lookup with a neural kana-kanji converter and adds an optional LLM conversion path. It is alpha software, and the README says so in the first paragraph.
- Who is it for?
- Adopt azooKey-Desktop if you type Japanese on macOS 15, want Zenzai's neural conversion rather than a static dictionary engine, and can tolerate alpha software that the README explicitly does not guarantee. Do not adopt it on a managed or production machine where an input method failure blocks all typing, and do not expect a stable configuration surface: v1.0 is still tracked as a roadmap issue.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The conversion engine, not the keyboard layout, is the point
Most Japanese IMEs on macOS convert kana to kanji by scoring candidate paths through a dictionary and a statistical language model. azooKey-Desktop replaces that scoring step with Zenzai, described in the README as a high-accuracy neural kana-kanji conversion engine. The project is the macOS port of azooKey, which originated as an iOS keyboard, so the conversion stack is shared with a mobile implementation rather than written from scratch for the desktop.
The intended user is someone who types Japanese all day on a Mac and finds the stock converter's candidate ordering wrong often enough to notice. That is a narrower audience than "anyone who writes Japanese". If the built-in IME already returns the right candidate first most of the time, a neural converter buys you little, and you take on an alpha input method that sits between your keyboard and every application.
What the README lists as features, and what each one implies
The feature list is short and specific: Zenzai conversion, a profile prompt function, history learning, a user dictionary, integration with an external personalization system called Tuner, LLM-based "Magic Conversions", live conversion, and native AZIK support.
Profile prompt and history learning both imply that conversion quality depends on accumulated local state. That has two consequences the README does not spell out. First, a fresh install will not convert as well as one that has been used for weeks. Second, if that state lives outside the app bundle, you need to know where it is before you migrate machines or reset the input source, because the README's troubleshooting section already tells you that removing and re-adding the input source is a normal recovery step during development.
AZIK support is the most concrete item. AZIK is a kana input extension, and supporting it natively rather than through a key-remapping layer means the IME has to handle the extended key sequences itself. The README does not describe how AZIK interacts with live conversion, which is the combination most likely to produce surprising behavior.
Zenzai weights ship as submodules, and Git LFS is mandatory
The repository does not contain the neural model in the normal sense. The README states that submodules hold the zenz GGUF weights and a language model file with a .marisa extension, and that these are stored via Git LFS on Hugging Face. A plain clone gives you pointer files.
The build prerequisites are macOS 15 or later, Xcode 26.1 or later, Git LFS, and SwiftLint, installed with:
brew install git-lfs swiftlint git lfs install
The clone must be recursive:
git clone https://github.com/azooKey/azooKey-Desktop --recursive
If you already cloned without LFS, the README gives the repair sequence:
git submodule update --init git -C azooKeyMac/Resources/zenz-v3.1-small-gguf lfs pull git -C azooKeyMac/Resources/base_n5_lm lfs pull
The verification step is a file size check on azooKeyMac/Resources/zenz-v3.1-small-gguf/ggml-model-Q5_K_M.gguf. The README says tens of megabytes means the real weights and roughly 134 bytes means you still have a pointer. That number is worth remembering, because the README also lists degraded conversion accuracy as the symptom of a failed LFS pull. A developer who skips this check will conclude the model is bad when the checkout is.
Signing is the first real obstacle to building from source
install.sh performs an archive build, which means code signing has to be configured in Xcode before the script will succeed. The README's instructions for developers without an Apple Developer Program membership are to open azooKeyMac.xcodeproj, switch the azooKeyMac target's Team to a Personal Team under Signing & Capabilities, and replace the repository's bundle identifiers (it gives dev.ensan.inputmethod.azooKeyMac as an example) with a prefix you own, such as dev.yourname.inputmethod.azooKeyMac.
Both steps are required. Changing the Team without replacing the bundle ID, or the reverse, will still fail. This is a friction point that the Homebrew path avoids entirely:
brew install azooKey
but the README notes that even the Homebrew route requires logging out and back in, then adding azooKey under System Settings > Keyboard > Input Sources. Upgrades use brew upgrade azooKey and may require a restart. For most users the release .pkg or the Homebrew formula is the right entry point, and the source build is for people changing the code.
Alpha status is a stated position, not a disclaimer
The README opens with a line stating that the software is currently alpha and that operation is not guaranteed at all. That is unusually direct, and it should be read literally. An input method is not a peripheral utility. If it hangs or crashes, the user cannot type in any application, including the terminal they would use to remove it.
The environment statement is equally narrow: macOS 15 is the verified configuration, macOS 14 and macOS 26 are said to work but are not tested. Xcode 26.0 is called out as possibly unable to build the project, with Xcode 16.x or 26.1 and later recommended. The version numbering in the release list (v0.1.5-beta.1, v0.1.4, v0.1.4-beta.2) is consistent with pre-1.0 software, and the README points to a roadmap issue for the v1.0 release rather than announcing one.
The practical failure mode to plan for is recovery, not conversion quality. The README's own development notes describe killing the azooKey process to pick up a new build, removing and re-adding the input source, and logging out and back in as routine reset operations. Anyone installing this should know how to reach System Settings and remove an input source without being able to type.
Where azooKey-Desktop is the wrong tool
Three cases stand out. The first is a managed Mac where you cannot log out, cannot add input sources freely, or cannot install a signed .pkg. The install flow assumes all three are available.
The second is a machine where typing must never fail. Alpha software with no stated stability guarantee does not belong on a system you use to join incident calls.
The third is a non-macOS environment, and here the README is useful rather than evasive. It lists community forks: fcitx5-hazkey for Linux, azooKey-Windows for Windows, and azoo-key-skkserv, an SKK server implementation for SKK clients that includes a macOS GUI application. These are separate projects by different authors, not ports maintained by this repository, so their state is independent of azooKey-Desktop. If you are on Linux, fcitx5-hazkey is the relevant starting point, and you should evaluate it on its own terms.
The alternative, and where the approaches actually diverge
The default comparison is macOS's built-in Japanese input. The difference is architectural. The system IME converts using a bundled dictionary plus a statistical model, all of it fixed at OS release time; improvements arrive with macOS updates. azooKey-Desktop converts using a neural model whose weights are shipped as repository artifacts, so the converter can be updated on its own schedule, and the README describes per-user adaptation through history learning, a user dictionary, profile prompts, and Tuner integration.
That is a real trade. You gain a converter that can be revised independently of the OS and that adapts to one user's writing. You give up the system IME's zero-install property, its Apple-signed and Apple-tested status, and its independence from a third-party process running inside every text field. For a developer who types Japanese in an editor and a terminal all day, the trade can be worth it. For someone who types Japanese occasionally in a browser, it is not.
A second alternative is the iOS azooKey keyboard, which the README links as the origin of this codebase. If your Japanese typing is mostly on a phone, that is the mature target, and the macOS port is the newer and less proven one.
Licence, maintenance, and what to check before you commit
The project is MIT licensed. That permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are included. It also means no warranty, which lines up with the README's alpha warning. Two things follow for anyone embedding this in a product. First, the repository bundles third-party model weights and a .marisa language model as submodules; the MIT licence on the repository code does not automatically tell you the terms attached to those artifacts, and the README does not state them. Second, the community forks listed in the README are separate repositories under their own authors, so their licensing is unrelated to this one. This is not legal advice; if you plan to redistribute a build, read the submodule sources yourself.
On maintenance, the observable facts are the release cadence (v0.1.4 in May, v0.1.5-beta.1 in June, per the release list) and an active development guide with a troubleshooting section. The project also acknowledges support from IPA's 2024 Mitou IT talent program, which is a funding statement rather than a maintenance commitment. The upgrade path through Homebrew is a single command but the README warns a restart may be needed, and after any upgrade you may have to re-add the input source. Budget for that interruption, not for a silent background update.
Editorial conclusion
Adopt azooKey-Desktop if you type Japanese on macOS 15, want Zenzai's neural conversion rather than a static dictionary engine, and can tolerate alpha software that the README explicitly does not guarantee. Do not adopt it on a managed or production machine where an input method failure blocks all typing, and do not expect a stable configuration surface: v1.0 is still tracked as a roadmap issue. Before installing, verify that the release .pkg corresponds to a tagged build, and if you build from source, check that azooKeyMac/Resources/zenz-v3.1-small-gguf/ggml-model-Q5_K_M.gguf is tens of megabytes rather than a Git LFS pointer.
Community notes