Translating a message on a phone often means leaving the conversation, opening a translator, pasting the text, copying the result, and returning to the original app.
I wanted to remove that loop.
The idea behind AI Translator Keyboard was simple: type in the text field you are already using, tap one translation key, review the result, and send it yourself.
The implementation was not simple at all.
A third-party keyboard is one of the most sensitive pieces of UI on a phone. It runs inside other apps, interacts with many kinds of text fields, and has to remain fast enough that people never feel that typing is blocked by an AI feature.
Here are the most important things I learned while building the keyboard for both iOS and Android.
1. A keyboard is not a smaller version of a normal app
On iOS, the keyboard is an app extension with a lifecycle and constraints that are different from the containing app. The extension may appear in Messages, WhatsApp, Instagram, a browser, or a text field that behaves in a completely unexpected way.
On Android, the keyboard is an input method service. It receives information about the active editor, but every host app can configure its text field differently.
That means the same action has to survive many environments:
- plain and multiline text fields;
- partially composed text from another input method;
- emoji and complex Unicode sequences;
- right-to-left languages;
- apps that update the cursor or selection unexpectedly;
- fields that are incorrectly labeled by the host app.
The happy path is easy. The real work is making the keyboard predictable when the surrounding app is not.
2. The AI boundary should be visible
The most important product decision was to keep ordinary typing separate from AI processing.
Nothing invokes a translation engine while the user is simply pressing keys. An AI action begins only after the user taps the sparkle key. At that point, the current draft is read, translated, and replaced in the same text field for review.
Conceptually, the flow looks like this:
ordinary typing
↓
user taps ✦
↓
read the current draft
↓
run the selected translation engine
↓
replace the draft only after success
↓
user reviews and sends
This explicit boundary helped in several ways:
- users can understand when processing begins;
- typing remains independent from network or model latency;
- the original draft can be preserved if translation fails;
- the keyboard never sends a message automatically;
- privacy explanations can describe a concrete action instead of an invisible background process.
For AI interfaces, a visible moment of consent is often better than a vague promise that the system is “smart.”
3. “Private” is not a useful architecture diagram
One of the easiest mistakes in AI product copy is to call a feature private without explaining where the data goes.
The keyboard supports three translation paths, and each has a different data flow:
On-device
On supported iPhones, translation can use Apple’s on-device intelligence. On Android, a downloaded Gemma model can run locally. In this mode, the requested translation stays on the phone.
Personal provider key
A user can connect a personal key for a supported cloud provider. Only the text submitted through the explicit AI action is sent to that provider over HTTPS, subject to the provider’s own terms.
Managed service
The optional Pro path removes API-key setup. The requested text passes through an encrypted proxy to produce the result. AI Translator Keyboard does not keep a history of messages or translations.
These modes should not be collapsed into one generic privacy claim. Local processing, direct provider processing, and managed cloud processing are different choices. The interface and privacy documentation should say so plainly.
4. Password fields need a separate threat model
Secure fields are not ordinary text fields.
On iOS, the system replaces a third-party keyboard with Apple’s keyboard when a properly configured secure text field becomes active. The third-party keyboard does not appear in that field.
Android provides input-type signals that a keyboard can use to identify password fields. In those fields, AI Translator Keyboard disables suggestions, autocorrect, and translation actions.
There is an important limitation: a keyboard depends on the host app describing its field correctly. If an Android app labels a sensitive field incorrectly, the operating system and keyboard receive incomplete information. That is why responsible privacy language should explain both the protection and its boundary instead of promising the impossible.
5. Translation quality is only half of the UX
A good result is useless if the replacement behavior feels dangerous.
The keyboard should not destroy a draft because a request timed out. It should not move the cursor to a surprising location. It should not submit text before the user has reviewed it. It also needs to behave correctly with characters whose visible length does not match their underlying representation.
The practical rules became:
- Keep the normal typing path fast and local.
- Start expensive work only after an explicit action.
- Preserve the original draft until a replacement is ready.
- Make failure recoverable.
- Let the user review the translated text before sending.
This sounds obvious, but AI features often prioritize the generated result and treat the surrounding editing experience as an afterthought. In a keyboard, the editing experience is the product.
6. Local AI changes the latency problem; it does not remove it
Network requests have variable latency. Local models have startup time, memory pressure, download size, and device compatibility constraints.
So “on-device” does not automatically mean “instant.” The product still needs to handle:
- the model not being downloaded yet;
- a cold model startup;
- insufficient storage or memory;
- unsupported devices;
- a user switching apps during processing;
- the keyboard disappearing before a result returns.
The main defense is architectural separation: translation work must never sit in the critical path of ordinary key presses.
7. One promise, two platform-specific implementations
The product promise is the same on iOS and Android:
Type where you already are, tap the translation key, and review the result in place.
But the implementation should respect each platform rather than forcing identical internals.
The iOS app uses Swift, SwiftUI, UIKit, StoreKit 2, and a keyboard extension. The Android app uses Kotlin, Jetpack Compose, an input method service, LiteRT-LM, Google Play Billing, and Play Integrity. A TypeScript backend runs on Cloudflare Workers for the managed path and supporting services.
Sharing the product model is valuable. Pretending the operating systems have the same keyboard architecture is not.
8. Test host apps, not only your own text field
A keyboard that works perfectly in a demo screen can fail in the apps people actually use.
My useful test matrix grew to include:
- WhatsApp;
- iMessage;
- Instagram;
- Telegram;
- Gmail;
- browsers;
- multiline editors;
- search fields;
- secure fields;
- slow or unavailable networks;
- missing local models;
- language switching and right-to-left text.
Every host app exposes a slightly different edge case. Testing only inside the containing app gives false confidence.
9. Naming is part of the product architecture too
The project originally launched as Geminate. It was a distinctive name, but it did not explain what the product did.
After the Android version shipped, I renamed it AI Translator Keyboard. The new name is less abstract and makes the cross-platform purpose immediately clear.
That rebrand affected much more than an icon and a title: store listings, deep links, structured data, documentation, analytics attribution, support pages, and legacy brand references all had to remain consistent.
Technical systems remember old names longer than users do.
What I would prioritize if I started again
If I were beginning the project today, I would establish these rules before building the first AI feature:
- define the exact moment text becomes eligible for processing;
- document every engine’s data path;
- design secure-field behavior before general autocomplete;
- keep model and network work outside the typing path;
- build a real-app test matrix early;
- make every generated result reviewable and reversible;
- choose a name that communicates the product before investing in distribution.
The biggest lesson is that an AI keyboard is not primarily a model integration. It is a trust, input-system, and failure-recovery problem with a model inside it.
AI Translator Keyboard is now available for iPhone and Android, supports 17 typing layouts and 51 translation targets, and works directly inside the apps where people already write.
You can see the product and its privacy documentation at getaikeyboard.app.
I would be interested to hear from other mobile developers: what is the strangest text-field or input-method edge case you have encountered?
AI disclosure: This article was drafted and structured with AI using implementation details from the actual iOS, Android, and backend codebase.
Top comments (0)