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.
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.
Can you actually build a production system keyboard — an Android IME, an iOS Custom Keyboard Extension — entirely in React Native? Not a demo, not a toy, but something you'd ship to real users on both platforms from one codebase?
Yes. This is the proof, and the library that makes it repeatable.
Every mobile app that wants a custom system keyboard has run into the same wall: Android IMEs and iOS Custom Keyboard Extensions are native surfaces. Building one has always meant writing (and maintaining) two separate native UIs in Kotlin and Swift — even if your app is otherwise 100% React Native. Most teams either give up on the idea or pay for a fully native rewrite of a single screen.
react-native-keyboard-bridge removes that wall. You write one component — plain View,
Text, TouchableOpacity, useState — and it runs live on both platforms, as a real, live React
Native surface hosted inside the IME process on Android and the Custom Keyboard Extension process
on iOS. Not a schema. Not a subset. Real React Native, running where conventional wisdom said it
couldn't.