FUTO cracks swipe typing — the last closed model on your phone

What happened

FUTO — the Austin-based outfit behind FUTO Keyboard and a growing constellation of anti-surveillance Android software — published a swipe typing model and the inference code that runs it. The launch page at swipe.futo.tech hit 456 on Hacker News, which for a niche IME announcement is a small earthquake. The model decodes gesture traces into text entirely on-device, with no network call, no telemetry, and weights you can download and inspect.

The project is the missing piece of FUTO Keyboard, which has otherwise been a credible Gboard alternative for over a year but lacked the one feature that keeps normal humans on Google's product: glide-to-type. The keyboard already had on-device voice transcription (via a fine-tuned Whisper) and on-device next-word prediction. Swipe was the holdout because the published research on gesture decoding is thin and the training data is gated inside the two companies — Google and Microsoft (SwiftKey) — that own the category.

FUTO's approach reads as a transformer-based sequence model trained on synthesized gesture traces over a known vocabulary, with the inference path optimized to run inside an Android IME's tight latency budget. The page is light on architectural detail but heavy on the demo: type a sentence, watch the trace, see the decoded candidates. It works.

Why it matters

The IME is the most privileged piece of software on a phone and almost nobody audits it. Your keyboard sees every password you type before your password manager does, every 2FA code before your bank does, every DM before Signal encrypts it. Gboard's privacy policy carves out 'snippets of typed text' for 'service improvement.' SwiftKey's 2016 breach leaked email addresses and phone numbers users had never sent anywhere. The threat model is not theoretical.

Until now, the practitioner answer was: pick your poison. AOSP keyboard has no swipe. Hacker's Keyboard has no swipe. Simple Keyboard has no swipe. The moment a user wanted gesture input — which, on a phone screen, is just 'wanted to type at adult speeds' — they were back on Gboard or SwiftKey, which is to say back on a model trained on, and continuously fed by, billions of other people's keystrokes.

The technical reason this took so long is genuinely interesting. Swipe decoding is not a small problem. A gesture is a noisy continuous path; the decoder has to jointly solve segmentation (where does one word end), spatial fuzz (the finger never quite hits the letters), and language modeling (what word was probably meant). Google's published Gboard work uses a neural touch-point decoder feeding into a finite-state transducer with a heavy LM rescorer. SwiftKey's stack is similar in shape. Reproducing that without their proprietary touch-trace corpora — which is what makes it work, not the model architecture — was the open-source bottleneck. FUTO appears to have side-stepped the data moat by generating synthetic gesture traces from a known keyboard layout plus a large text corpus, which is the same trick that unlocked open ASR after Whisper.

The Hacker News thread is unusually substantive. Users report the model handles less common words better than Gboard for them, which is plausible — Gboard's LM is tuned toward population-level frequency and routinely 'corrects' technical jargon into common words. A local model with a swappable vocabulary doesn't have that incentive. Several commenters noted the keyboard now works offline on GrapheneOS and CalyxOS in a way Gboard never has, which matters to a non-trivial slice of the security-conscious crowd.

What this means for your stack

If you ship a mobile app, the keyboard is a dependency you don't track in your SBOM. Every input field in your app is rendered by a third-party process you didn't choose, running a model whose weights you can't see, with network permissions you can't audit. That's been an acceptable risk because there was no alternative; it stops being acceptable the moment one exists. Expect security and compliance teams at regulated shops — finance, health, defense — to start asking whether corporate-issued devices can mandate an auditable IME. FUTO's licensing (source-available, not OSI-open) will complicate the procurement conversation, but the artifact existing changes the conversation at all.

For on-device ML engineers, the more interesting takeaway is methodological. FUTO is quietly becoming a case study in shipping useful local models in domains where the incumbent moat was assumed to be training data: keyboards, voice, OCR-adjacent tasks. The synthetic-data-plus-small-model recipe keeps working in places people assumed required a hyperscaler. If you've been told 'we can't build this locally because we don't have the data,' it's worth re-checking whether you actually need the data or just need a plausible generator and a tighter model.

If you maintain an Android app with custom input handling — a code editor, a terminal, a chat client — verify your IME interaction code against a non-Gboard keyboard. The assumptions baked in (auto-correction behavior, composing region timing, gesture event shape) vary more than you'd think, and the FUTO release will move a small but loud chunk of your users.

Looking ahead

The interesting question is not whether FUTO Keyboard takes meaningful share from Gboard — it won't, the distribution gap is unbridgeable — but whether the model itself becomes the de facto open swipe decoder that other privacy-focused keyboards (OpenBoard, FlorisBoard, HeliBoard) ship. The Whisper moment for on-device input would be a single set of weights that every open keyboard could drop in, and FUTO just shipped a candidate. Watch the HeliBoard issue tracker over the next 60 days; the velocity there will tell you whether this becomes infrastructure or stays a single-product feature.