Khmer Keyboard - NP

The problem

Khmer has far more characters than a phone-sized keyboard has room for. The script uses 33 consonants, each with a subscript (coeng) form, plus dependent vowels, independent vowels, diacritics, and digits. A naive layout either shrinks the keys until they cannot be hit accurately, or buries half the script under layer-switching that interrupts the flow of typing.

Latin keyboards solve density with a shift layer. Khmer needs considerably more than one extra layer, and the characters that need to be reachable are not the ones a shift key would conventionally hold.

The constraints

Grapheme clusters, not characters. What a reader sees as one Khmer unit is frequently several codepoints — a base consonant, one or more coeng-marked subscripts, and vowel signs positioned around the stack. Cursor movement, selection, and deletion all have to operate on the cluster. A backspace that removes one codepoint deletes a piece of a character and leaves a malformed remainder on screen. This is the single most common Khmer input bug, and it is immediately obvious to anyone who reads the language.

NiDA standard compliance. Cambodia has a national standard for Khmer encoding and keyboard layout. Text produced by the keyboard has to interoperate with everything else in the ecosystem, which means following the standard even where a different ordering would have been more convenient to implement.

The iOS keyboard extension memory ceiling. Custom keyboards on iOS run as an app extension with a substantially smaller memory budget than a normal app, and the system terminates an extension that exceeds it. The termination is abrupt and, from the user's perspective, looks like the keyboard vanishing mid-sentence. Every asset, every cached layout, and every font decision had to be made against that ceiling.

What we built

A layout where each key carries a primary character on tap and a secondary character revealed by a short downward swipe on the same key. That single interaction roughly doubles the reachable character set without adding a layer to switch between, without shrinking the keys, and without moving the user's thumb away from where it already is.

The interaction matters more than any individual assignment: the secondary character is discoverable because it is on the key you are already pressing, and committing to it is a continuation of the gesture that started the tap rather than a separate decision.

Underneath, text handling is grapheme-cluster aware throughout. Deletion removes a whole cluster. The renderer keeps coeng stacking intact rather than laying subscripts out as separate glyphs. Assets are sized to stay comfortably inside the extension's memory budget, with the keyboard's appearance options implemented so that changing the background does not multiply the resident image cost.

Outcome

Shipped on the App Store in June 2017 and maintained since. It runs entirely on the device: the keyboard does not request the "Allow Full Access" permission, has no network access, and transmits no keystrokes. For a keyboard, that is a design constraint as much as a privacy position — an extension that never talks to a server has no server-side failure mode and nothing to leak.

An Android port is in development. The IME cold-start behaviour on Android is a different problem from the iOS memory ceiling: the first keystroke after the input method is summoned has to be responsive, which constrains how much work can happen at initialisation.