Building an AI Translator Keyboard for iOS and Android: Privacy, Latency, and UX Lessons

Turning a message on a phone usually requires exiting the conversation to open a translator, copy the text, translate it, and then return to the original app. The AI Translator Keyboard aims to eliminate this process by allowing users to type directly within the field they are already using and select a translation instantly. However, creating such a keyboard proved challenging.

A third-party keyboard is one of the most sensitive UI components on a phone. It runs within other apps, interacts with numerous text fields, and must remain fast enough so that users don’t feel their typing is blocked by an AI feature. Key lessons learned from building keyboards for both iOS and Android include:

1. A keyboard is not a scaled-down version of a regular app. On iOS, the keyboard is an extension with a unique lifecycle and different constraints than the app it resides in. It may appear in various messaging apps or text fields behaving unexpectedly. Android treats the keyboard as an input method service, receiving information about the active editor, but each host app can configure its text fields differently.

The same actions must work across various environments, including plain and multiline text fields, right-to-left languages, complex Unicode sequences, and fields updated unexpectedly by other apps.

2. The AI processing boundary must be clear. The keyboard separates ordinary typing from AI processing. Translations only begin after the user taps a specific key. During ordinary typing, no translation engine is activated. This boundary helps users understand when processing begins, keeps typing independent of network or model latency, allows preserving the original draft if translation fails, and provides concrete privacy explanations, unlike an invisible background process.

3. Describing privacy clearly is crucial. The keyboard supports three translation paths with differing data flows. Local processing uses Apple’s on-device intelligence or a downloaded Gemma model on Android, keeping the translation on the phone. With a personal provider key, translations are sent to a cloud provider over HTTPS. The managed service path uses an encrypted proxy to handle all requests.

However, the keyboard does not retain any message or translation history. These different modes should not be merged into a single privacy claim; rather, the interface and documentation should explain each choice separately.

4. Secure fields require a different approach. When a proper secure text field is active, the third-party keyboard is replaced by Apple’s keyboard on iOS, and Android uses input-type signals to identify password fields. During these sessions, the keyboard disables suggestions, autocorrect, and translation actions. Responsibility in privacy language should explain both the protections and their limitations, rather than promising more than what is feasible.

5. Translation quality and UX are interdependent. A high-quality translation means little if the user experience is compromised. The keyboard must keep the normal typing path fast and local, start expensive AI work only after an explicit action, preserve the original draft until translation is complete, and make failures recoverable. The user should be able to review the translated text before sending. These requirements sound simple but are often overlooked in favor of focusing solely on the translation result.

6. Local AI processing addresses latency, but not fully. Network requests have unpredictable latency. Local models have startup time, memory constraints, download sizes, and compatibility issues. "On-device" processing does not guarantee instant translation. The keyboard must handle scenarios such as the model not yet downloaded, cold startup, insufficient storage or memory, unsupported devices, and keyboard disappearance before a result returns.

Ensuring the keyboard remains responsive in all situations is crucial to providing a seamless user experience.