FUTO Keyboard: an offline LatinIME fork you build yourself

What FUTO Keyboard is and who it is for

FUTO Keyboard is an Android input method built from AOSP's LatinIME, the Android Open-Source Keyboard. The README states the goal plainly: make a good modern keyboard that stays offline and does not spy on the user, with significant changes made to the upstream code. That framing tells you who the project is for. Someone who wants a system keyboard that does not depend on a network round trip for typing, and who cares more about that property than about the breadth of a commercial keyboard's feature set.

The repository you are looking at is not the development home. It is the official issue tracker and a source mirror of https://gitlab.futo.org/keyboard/latinime. Registration on the internal GitLab is closed, so GitHub is where issues and pull requests go. If you are evaluating the project rather than contributing to it, the practical consequence is that the GitHub tree is a copy, and the canonical source of truth sits elsewhere.

The project is Android-only. Nothing in the README, the topics, or the repository layout suggests an iOS, Windows, or Linux build. The topics list android, futo, keyboard, offline, privacy, and voice-input, and the top-level directories include java/, native/, voiceinput-shared/, dictionaries/, and translations. That is the shape of a native Android app with a C++ core, not a cross-platform library.

How the LatinIME fork is put together

The layout of the repository is the clearest statement of the architecture. java/ holds the Android-side code, native/ holds the C++ that the primary language field refers to, and common/ and libs are shared code and vendored dependencies. The .gitmodules file at the top level confirms that some of those dependencies arrive as submodules rather than as ordinary directories, which is why the build instructions insist on a recursive clone.

Two directories stand out for anyone thinking about what the keyboard does. dictionaries/ holds the language data used for suggestions and corrections. voiceinput-shared/ is a shared module for voice input, matching the voice-input topic. The README does not describe how voice input is wired, whether it runs on-device, or what it depends on, so treat the directory name as the only confirmed fact.

The build tooling is conventional Android. build.gradle, settings.gradle, gradle.properties, and the gradle/ wrapper directory sit at the top level, and the README gives Gradle commands rather than a bespoke build script. There are also .ci/ and .github/ directories, .gitlab-ci.yml, and shell helpers such as setUpPropertiesCI.sh, syncTranslations.sh, uploadNightly.sh, and uploadNightlyBranch.sh. Those names indicate an automated pipeline that produces nightly artifacts, though the README does not document the pipeline itself.

Installing FUTO Keyboard and building the APK from source

If you want the app rather than the code, the README points to the FUTO Keyboard website at keyboard.futo.tech for downloads and more information. The homepage field on the repository lists keyboard.futo.org instead, so the two addresses do not agree; check both before concluding a download page has moved.

For a source build, the README requires a recursive clone because the project depends on submodules. Run this from a directory where you want the tree to live:

git clone --recursive https://gitlab.futo.org/keyboard/latinime.git

If you already cloned without the flag, the README gives the repair command:

git submodule update --init --recursive

After that you can open the project in Android Studio, or build from the command line. The README lists two Gradle targets, one for the unstable debug variant and one for the stable release variant:

./gradlew assembleUnstableDebug
./gradlew assembleStableRelease

The variant names matter. assembleUnstableDebug produces a debug build, which is what you want while reading the code. assembleStableRelease is the release path. The README does not state where the resulting APK lands, what signing configuration a local release build uses, or which JDK and Android SDK versions are required, so expect to resolve those from the Gradle files themselves.

The README also documents APK signature verification for official builds. It publishes an MD5, a SHA1, and a SHA-256 fingerprint for all versions except the Google Play build. If you install an APK claiming to be FUTO Keyboard, comparing the signature against those published values is the check the project itself offers.

The FUTO Source First License and what it means for contributors

The licence is the part of this project most likely to surprise an engineer who assumes an AOSP fork is Apache-2.0. The README states the code is licensed under the FUTO Source First License 1.1, and the repository's licence metadata is NOASSERTION, meaning GitHub's tooling could not classify it. Source First is not an OSI-approved open source licence in the ordinary sense, so if your organisation has a policy that only permits approved licences, this project will need a separate review. That is a policy question, not a legal one, and it is worth raising before you build a product on the fork.

Contributing has its own gate. Because of the custom licence, pull requests to this repository require signing a CLA at cla.futo.org, which you can do after opening a PR. Layout contributions are the exception: the separate layouts repository at github.com/futo-org/futo-keyboard-layouts is Apache-2.0 and does not require a CLA. If you only want to add a keyboard layout, that is the cheaper path.

The README also takes an explicit position on AI-generated contributions. It asks contributors not to submit AI-generated pull requests, and states that pull requests with clear heavy use of AI may be closed without comment. The same request applies to issues. Whatever you think of that policy, it is a real constraint on how you contribute, and it is stated more directly than most projects manage.

Where FUTO Keyboard is the wrong choice

The clearest limitation is platform. This is an Android input method. If you searched for how to install an Android keyboard on an iPhone, or how to use one on a PC, this project does not answer that. The code is an Android app with a native component, and the README describes no other target. Anyone who needs one keyboard across phone, tablet, and desktop should look elsewhere.

The second limitation is the contribution path. The canonical source is on a GitLab instance where registration is closed. You can file issues and open pull requests on the GitHub mirror, but you cannot browse the internal instance or join it. If your workflow assumes you can push branches to the upstream repository, or that the public mirror is where merges happen, that assumption is wrong here.

The third is documentation depth. The README covers cloning, building, signing verification, licensing, and contribution rules. It does not cover rollback, migration between versions, the internals of voice input, or the CI pipeline. The release list shows 0.1.30, 0.1.30-rc1, and 0.1.29.1, so the project does publish release candidates, but nothing in the README tells you how to move between them or what changes. If you need a documented upgrade path before you commit, that documentation does not exist yet.

Alternatives and the difference in approach

The obvious alternative is the upstream project this one forked: AOSP's LatinIME, the Android Open-Source Keyboard. The relationship is direct. LatinIME is the base, and FUTO Keyboard is a fork with significant changes, as the README puts it. The difference in approach is licensing and governance rather than architecture. Upstream LatinIME is part of the Android platform tree; FUTO Keyboard is a separately distributed app with its own licence, its own release cadence, and its own contribution rules including the CLA. If you want the keyboard that ships inside Android itself, or you need a licence that your legal review already accepts, upstream is the safer starting point. If you want a maintained fork with a stated offline goal and a downloadable APK, this project is the one that exists.

The second alternative is the commercial keyboard you probably already have installed. The README's framing is the whole argument against it: this one stays offline. The trade-off runs the other way too. A commercial keyboard has a support organisation, a documented settings surface, and a feature roadmap. FUTO Keyboard is at version 0.1.x, its issue tracker is a GitHub mirror, and its internals are documented mainly by the repository layout. You are trading feature breadth and support for a build you can inspect and a stated privacy property.

Maintenance, releases, and upgrade cost

The repository is not archived, and the last push was on 2026-09-23, one day before this writing. The release list shows 0.1.30 on 2026-08-04, preceded by 0.1.30-rc1 on 2026-07-28 and 0.1.29.1 on 2026-06-22. That pattern, a release candidate followed by a stable tag roughly a week later, is the cadence the tags themselves show. Nothing in the README commits to a schedule.

The upgrade cost for a user is low: install a new APK. The upgrade cost for a contributor is higher. Every pull request requires a CLA signature, the canonical repository is closed to registration, and the README warns that AI-heavy contributions may be closed without comment. If you plan to carry local patches, you are maintaining a fork of a fork against a moving upstream that you cannot browse directly.

On licence, the FUTO Source First License 1.1 is the governing document, and the repository's metadata does not classify it. The practical implication is that you cannot assume the permissions an Apache-2.0 or MIT project would give you, including for redistribution or for building a derivative product. Read LICENSE.md and NOTICE before you ship anything derived from this tree. The layouts repository is the one clearly permissive piece, at Apache-2.0.

Editorial conclusion

Adopt FUTO Keyboard if you want an Android keyboard whose stated goal is to stay offline, and you are willing to install a signed APK or build the fork yourself. Do not adopt it if you need iOS or desktop coverage, or if you expect to drive development through GitHub pull requests without signing the CLA. Before installing anything, verify the APK signing fingerprint published in the README, and if you build from source, use a recursive clone so the submodules are present.

Frequently asked questions

Official sources

1. futo-org/android-keyboard on GitHub
2. Issues
3. Project website
4. README
5. Releases