Before this, changing a single line in KeyboardApp.tsx meant a full rebundle and reinstall on both platforms — no Fast Refresh, no live reload, just the standard edit-rebuild-reinstall loop every time. It turns out the fix required two completely different investigations, because Android and iOS started from opposite places.

Shipping a keyboard is only half the job — a user still has to find Settings, enable it, and select it before it ever appears. Neither Android nor iOS lets an app skip that flow, so the best you can do is make it as short as possible from your own app's screen.

A keyboard that only commits the right characters still feels wrong if it doesn't vibrate, click, or auto-capitalize the way the system keyboard does. Those details are small individually, but they're the difference between "a keyboard" and "the keyboard I forgot wasn't the system one."

Early on, this library was four separate workspace packages: a core package (gestures/ prediction/layout types), a raw Gradle module wired in through a hand-edited settings.gradle, a Swift-sources-plus-Ruby-script package hardcoded to one example project's paths, and the actual published react-native-keyboard-bridge npm package. A real external consumer would have needed two npm installs, a git submodule or hand-copy for the native folders, and manual edits across settings.gradle, app/build.gradle, MainApplication.kt, and AndroidManifest.xml.

Apple's Custom Keyboard Extension API is deliberately narrow — narrower than most developers expect coming from Android's InputConnection. Knowing the actual boundary up front saves you from designing a feature the platform will simply never let you ship.

Android's InputMethodService has a much larger memory budget than iOS's extension model, which is exactly why the Android side of this library could go straight to "host real React Native" with none of the multi-generation caution iOS needed.

Word prediction doesn't need to be a black box. The library exposes it as one interface — WordPredictor — with a minimal built-in implementation you can use as-is or replace entirely.

Swipe-typing (dragging a finger across letters instead of tapping each one) looks like a hard geometry problem, and it's easy to over-engineer. The library reduces it to one pure function: keysAlongPath.

A huge share of "custom keyboard" tutorials quietly assume English. The layout is QWERTY, the examples commit ASCII, and anything beyond Latin script is left as "an exercise for the reader." That's backwards for a huge portion of the world's keyboard users.

This is the walkthrough version of the Tutorial — a from-scratch build of a real, usable QWERTY keyboard, explained step by step.