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.
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:
The happy path is easy. The real work is making the keyboard predictable when the surrounding app is not.
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:
For AI interfaces, a visible moment of consent is often better than a vague promise that the system is “smart.”
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 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.
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.
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.
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.
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:
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.
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 main defense is architectural separation: translation work must never sit in the critical path of ordinary key presses.
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.
A keyboard that works perfectly in a demo screen can fail in the apps people actually use.
My useful test matrix grew to include:
Every host app exposes a slightly different edge case. Testing only inside the containing app gives false confidence.
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.
If I were beginning the project today, I would establish these rules before building the first AI feature:
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.