Android already had this — just never wired up​

CustomKeyboardService.kt already passes useDevSupport = BuildConfig.DEBUG and allowPackagerServerAccess = true to ReactHostImpl. Reading ReactHostImpl's own source confirmed something surprising: whenever both flags are true, it already pings the packager on every surface creation and transparently swaps in a Metro-fetched bundle instead of the committed asset one. This is core upstream React Native behavior — nothing the library needed to add. It silently wasn't working before only because the dev workflow never had Metro running with adb reverse tcp:8081 tcp:8081 set up for the app.

Zero code changes. Just: run npx react-native start, run adb reverse tcp:8081 tcp:8081 (or use react-native run-android, which does it for you), install a debug build, and real Fast Refresh on save just works.

iOS needed an actual code change​

RNKeyboardBootstrap.swift's bundleURL() hardcoded the committed main.jsbundle unconditionally — even in DEBUG builds — because RCTReactNativeFactory has no automatic "check if Metro is up" fallback the way Android's ReactHostImpl does. The fix mirrors the standard RN iOS app template exactly:

override func bundleURL() -> URL? {
    #if DEBUG
    RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
    #else
    Bundle(for: KeyboardReactNativeDelegate.self).url(forResource: "main", withExtension: "jsbundle")
    #endif
}

RELEASE builds are completely unaffected — they still load the committed bundle, unchanged.

The one new requirement: temporary network access​

A DEBUG keyboard extension reaching Metro needs network access, which extensions don't have by default. Two one-time, reversible toggles:

1. Set NSExtension > NSExtensionAttributes > RequestsOpenAccess to true in the extension's Info.plist.
2. Enable "Allow Full Access" for the keyboard in Settings, once it's installed.

Both should flip back to false/off before a release build — RequestsOpenAccess: true is a real, user-visible permission request with no reason to ship if your keyboard has no other need for network access.

If Metro isn't running when a DEBUG build launches, there's no fallback to the committed bundle — same as any standard debug React Native app. The one difference: an extension process has no UIWindow to present a red error screen in, so the failure can be silent from the UI's perspective. Check Console.app logs for "Could not connect to development server" if the keyboard doesn't render.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

The four settings functions​

function openInputMethodSettings(): void;
function showInputMethodPicker(): void;
function isKeyboardEnabled(): Promise<boolean>;
function isKeyboardSelected(): Promise<boolean>;

These run from the host app's own screen — an onboarding step in App.tsx, typically — never from inside the keyboard itself. Enabling or switching a keyboard is something only the app the user already has open in the foreground can prompt them to do.

Android: a real three-state flow​

function EnableKeyboardScreen() {
  const [enabled, setEnabled] = useState(false);
  const [selected, setSelected] = useState(false);

  useEffect(() => {
    isKeyboardEnabled().then(setEnabled);
    isKeyboardSelected().then(setSelected);
  }, []);

  if (selected) return <Text>You're all set — this keyboard is active.</Text>;
  if (enabled) {
    return <Button title="Switch to this keyboard" onPress={showInputMethodPicker} />;
  }
  return <Button title="Enable keyboard" onPress={openInputMethodSettings} />;
}

openInputMethodSettings opens system Settings' keyboard-management screen directly on Android — the user toggles your keyboard on and returns to your app. showInputMethodPicker then opens the system's own keyboard-switcher sheet so they can make it active without leaving the app at all.

iOS: a shorter deep link, then manual navigation​

openInputMethodSettings still works on iOS, but Apple exposes no deeper deep link than this app's own Settings page — there's no API to jump straight to General > Keyboard > Keyboards. The user still navigates the last step themselves. showInputMethodPicker, isKeyboardEnabled, and isKeyboardSelected have no iOS equivalent at all (no API lets a containing app query or drive keyboard-picker state), so they resolve a safe default (false/no-op) instead of throwing — meaning the same EnableKeyboardScreen component above degrades gracefully to just the "Enable keyboard" button on iOS, with a caption explaining the one extra manual step.

Design around the asymmetry, don't hide it​

The honest version of this screen tells iOS users explicitly: "tap Enable, then go to General > Keyboard > Keyboards > [Your App] and turn on Allow Full Access if prompted." Trying to make the two platforms look identical here usually means one of them silently doesn't work — better to show each platform's real, shortest path.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

Haptic feedback on every key press​

function performHapticFeedback(): void;

One call, no configuration. On iOS, this silently no-ops until the user has granted "Allow Full Access" — a platform restriction on extensions, not a bug — so don't rely on it as the only signal a key press succeeded.

Click sounds, with named effects​

function playClickSound(effect?: string): void;

const SoundEffect = {
  STANDARD: 'standard',
  SPACEBAR: 'spacebar',
  DELETE: 'delete',
  RETURN: 'return',
  INVALID: 'invalid',
};

<TouchableOpacity
  onPress={() => {
    playClickSound(SoundEffect.STANDARD);
    commitText('a');
  }}
>

iOS has exactly one system click sound regardless of which named effect you pass — the effect argument is accepted but ignored there. Android maps each name to the matching AudioManager.FX_KEYPRESS_* constant.

Auto-capitalizing like the system keyboard​

function getCursorCapsMode(reqModes?: number): Promise<number>;

const CapsModeRequest = {
  CHARACTERS: 1 << 0,
  WORDS: 1 << 1,
  SENTENCES: 1 << 2,
};

useEffect(() => {
  getCursorCapsMode(CapsModeRequest.SENTENCES).then((mode) => {
    setShift(mode !== 0);
  });
}, [cursorPosition]);

This mirrors android.text.TextUtils.CAP_MODE_* — request SENTENCES and you get a non-zero result exactly when the cursor sits at the start of a sentence, the same signal the system keyboard uses to auto-capitalize the next letter. On iOS it's an approximation (a heuristic over documentContextBeforeInput, not Android's exact locale-aware algorithm) but close enough that users won't notice the difference in normal typing.

Adapting the return key to context​

function performEditorAction(actionCode: number): void;

const EditorActions = {
  GO: 2, SEARCH: 3, SEND: 4, NEXT: 5, DONE: 6,
};

A search box sets IME_ACTION_SEARCH; a single-line form field often sets IME_ACTION_NEXT. Reading which one is active (via getCurrentEditorInfo/onEditorInfoChange on Android) lets your "return" key render "Search" or "Next" instead of a generic newline — and performEditorAction lets pressing it actually trigger that action instead of inserting \n into a field that doesn't want one. This is Android-only (no generic "perform action" API exists on iOS), so it's a safe no-op there — see the feel-and-polish tutorial for wiring all of this into one component.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

The end goal was one command​

yarn add react-native-keyboard-bridge

Everything folds into that single package now: the JS bridge/settings functions, gestures, layouts, word prediction, the Android native module (android/), the iOS native module and setup CLI (ios/, bin/). Two real bugs got fixed in the process of merging, not just files moved around:

1. Android's <service> declaration for CustomKeyboardService used to live only in the example app's own manifest, hardcoded with that app's own package name. It now lives in the library's own manifest, using a Gradle placeholder resolved to the consuming app's applicationId at merge time — verified by inspecting the actual merged manifest output.
2. The host-app-facing native module needed a manual MainApplication.kt line before; it's now declared as this dependency's autolinked packageInstance in react-native.config.js.

iOS still can't be a zero-step install — and that's fine​

This is an Apple platform constraint, not a gap in the library: a custom keyboard requires its own Xcode App Extension target, and no CocoaPod or npm install can fabricate a new Xcode target from outside Xcode's own project file format. setup_xcode_targets.rb handles the one step that genuinely can't be automated away — discovering the consumer's own .xcodeproj, its app target, and its bundle identifier, all without a single hardcoded path to any specific project name.

A second flattening, later​

Even after the four-package merge, the published package still lived nested two levels deep — packages/react-native/, with its own inner src/ folder for pure TypeScript. Since there's only ever been one package since the consolidation, that nesting stopped serving a purpose. It's since been flattened to src/ at the repo root, with the inner TypeScript folder renamed to core/ — a purely mechanical rename, verified with a full rebuild on both platforms, that finally makes the repo's layout match what a "one package" library should look like on disk, not just in package.json.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

UITextDocumentProxy is the entire surface​

Everything a keyboard extension can do to the host text field goes through UITextDocumentProxy/UIInputViewController — there's no lower-level access, no InputConnection-equivalent with dozens of methods. The bridge-function parity table exists precisely because this surface is so much smaller than Android's:

• Fully supported: inserting text, reading text before/after the cursor, reading the current selection, advancing to the next input mode.
• Approximated: deleting after the cursor (no forward-delete API — deleteSurroundingText's after argument is silently ignored on iOS), "switch to previous input method" (iOS has no distinct "previous," so it calls the same "next" API), cursor caps-mode (a heuristic over documentContextBeforeInput, not Android's exact locale-aware algorithm).
• Not possible at all: absolute-offset selection, key-event injection, generic "editor action" dispatch, marked/composing text, batch edits, or a keyboard dismissing itself.

None of these iOS-only gaps throw. Every function the library exposes is defined on both platforms; the ones with no iOS equivalent are safe no-ops (or resolve a safe default value) specifically so a shared KeyboardApp.tsx never needs an if (Platform.OS === ...) branch.

Full Access is an explicit, visible user choice​

Any network request from inside the extension process requires the user to grant "Allow Full Access" in Settings — and that toggle only appears at all if the extension's Info.plist sets RequestsOpenAccess to true. There's no way around this for anything that needs the network, including connecting to a Metro dev server during development.

This library ships RequestsOpenAccess: false by default in the scaffolded Info.plist — a production keyboard that has no other reason to need network access should ship with no reason to prompt the user for it. Development is the one carve-out: flip it to true locally to get Metro live reload, and flip it back before a release build.

Enabling a keyboard is always the user's decision​

Neither platform lets an app silently register itself as active — openInputMethodSettings opens this app's own Settings page on iOS (Apple exposes no deeper deep link than that), from which the user still navigates to General > Keyboard > Keyboards themselves. There's no API for a containing app to enable, switch to, or query the enabled/selected state of a keyboard on iOS the way Android allows — see the settings screen tutorial for how to design an onboarding flow around that asymmetry instead of fighting it.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

Why not the classic bridge?​

The obvious first approach — ReactInstanceManager, the classic (pre-New-Architecture) bridge — turned out to be a dead end: current React Native versions unconditionally throw when you try to construct one outside of an Activity-hosted flow. An InputMethodService is not an Activity.

The validated replacement is ReactHostImpl + ReactSurface — bridgeless, New Architecture, Fabric — and critically, com.facebook.react.runtime.ReactSurfaceView is a plain View with no Activity dependency, confirmed by reading the framework source directly rather than assuming.

The shape of it​

class CustomKeyboardService : InputMethodService(), DefaultHardwareBackBtnHandler {
  private var reactHost: ReactHost? = null

  override fun onCreate() {
    super.onCreate()
    reactHost = buildReactHost().also { it.start() }
  }

  override fun onCreateInputView(): View {
    val surface = reactHost!!.createSurface(this, "KeyboardApp", Bundle())
    surface.start()
    return surface.view ?: View(this)
  }
}

buildReactHost() wires a DefaultReactHostDelegate with KeyboardBridgeModule (the native counterpart to the JS bridge functions) in its package list, and a Hermes JSRuntimeFactory. The IME owns its own ReactHost — not a shared one with the containing app — so its lifecycle (onStartInputView/onFinishInputView) maps directly onto ReactHost.onHostResume/ onHostPause.

Zero manual Android wiring, on purpose​

Two real integration bugs got fixed while building this, not just moved around:

1. CustomKeyboardService's <service> declaration lives in the library's own AndroidManifest.xml, using the ${applicationId}.MainActivity Gradle placeholder — it merges into your app's manifest automatically. No manual manifest edit.
2. KeyboardSettingsModule (the host-app-facing native module — openInputMethodSettings and friends) is declared as this dependency's autolinked packageInstance in react-native.config.js. No manual MainApplication.kt edit.

Autolinking only supports one auto-instantiated package per dependency, which is exactly why the IME-only KeyboardBridgeModule is not autolinked the same way — CustomKeyboardService constructs its own standalone ReactHost directly, and the host app's own ReactHost should never see it. Two native modules, two very different registration paths, by design.

The only things Android still asks you to supply are the two resources that are legitimately app-specific: res/xml/method.xml (your keyboard's language subtypes) and res/values/strings.xml's keyboard_service_label — every app names its own keyboard.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

The interface​

interface WordPredictor {
  suggest(prefix: string, options?: SuggestOptions): string[];
}
interface SuggestOptions {
  limit?: number; // default 3
}

That's the entire contract: given what's been typed so far, return candidate completions. Nothing in the bridge or the UI layer cares how suggest is implemented — frequency-weighted, ML-backed, server-fetched, whatever your app needs.

The built-in default​

StaticDictionaryPredictor is deliberately small: an in-memory word list, case-insensitive prefix match, ranked shortest-then-alphabetical.

const predictor = new StaticDictionaryPredictor(['hello', 'help', 'helm', 'held']);
predictor.suggest('hel'); // ['held', 'help', 'helm'] — 'hello' cut off by the default limit of 3
predictor.suggest('hel', { limit: 5 }); // all four, same ranking

It's meant as a starting point and a reference implementation, not the ceiling of what's possible — swap it for anything that satisfies WordPredictor once you need frequency weighting or a larger vocabulary.

Wiring it into a keyboard​

const predictor = useMemo(() => new StaticDictionaryPredictor(WORDS), []);
const [current, setCurrent] = useState('');
const suggestions = predictor.suggest(current);

function press(letter: string) {
  commitText(letter);
  setCurrent((c) => c + letter);
}

function acceptSuggestion(word: string) {
  deleteSurroundingText(current.length, 0);
  commitText(word + ' ');
  setCurrent('');
}

The pattern: track the in-progress word locally (current), show suggestions in a bar above the keys, and on tap, delete exactly what's been typed so far (current.length characters back) and commit the full word instead. current resets on space, punctuation, or a suggestion tap — same as any predictive keyboard's word-boundary handling.

This composes with everything else in the library: run it against the sequence keysAlongPath returns from a swipe gesture, or against plain typed input from tap-based keys. See the word prediction tutorial for the complete suggestion-bar component.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

The data shape​

Gesture matching works on the same Key/KeyRow shape used for layout — no separate schema:

interface Key {
  id: string;
  label: string;
  width: number; // in "standard key" units
  action: KeyAction;
  value?: string;
}
interface KeyRow {
  keys: Key[];
}

computeGeometry(rows, rowHeight) lays these out on a grid (row-major, left to right) in the same units as width/rowHeight — not pixels. keysAlongPath(rows, path) uses that geometry internally and returns the ordered, de-duplicated sequence of keys a raw touch path crossed:

function keysAlongPath(rows: KeyRow[], path: TouchPoint[], rowHeight = 1): Key[];
interface TouchPoint { x: number; y: number; }

Both are pure, synchronous, and have zero React Native dependency — they're plain TypeScript, so you can unit test your layout's gesture behavior without a simulator.

Wiring it to a real gesture​

The one thing the library doesn't do for you is capture the raw touch path — that's a PanResponder (or react-native-gesture-handler) concern, and it means converting pixel coordinates into the same grid units your Key.width/rowHeight use:

const KEY_SIZE_PX = 36;
const path = useRef<TouchPoint[]>([]);

const responder = useRef(
  PanResponder.create({
    onStartShouldSetPanResponder: () => true,
    onPanResponderMove: (_, gesture) => {
      path.current.push({
        x: gesture.moveX / KEY_SIZE_PX,
        y: gesture.moveY / KEY_SIZE_PX,
      });
    },
    onPanResponderRelease: () => {
      const visited = keysAlongPath(ROWS, path.current);
      const word = visited.map((k) => k.value ?? k.label).join('');
      commitText(word);
      path.current = [];
    },
  }),
).current;

Where dictionary correction fits in​

keysAlongPath gives you the literal letters a finger crossed — real swipe keyboards then run that sequence (or, more precisely, the shape of the path) against a dictionary to correct for imprecise swipes. That's exactly where WordPredictor composes with this: treat the joined letters as a prefix, or score dictionary candidates against the visited key sequence, and offer the result as a suggestion rather than committing directly. See Word Prediction in ~50 Lines for the predictor side, and the swipe-typing tutorial for the full gesture-to-commit flow.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

The library makes no assumption about script​

commitText takes a plain Unicode string:

function commitText(text: string): void;

Not a character code, not an ASCII byte, not a Latin-alphabet-shaped enum. Whatever string you pass — 'a', 'অ', 'ا', 'あ', '的' — gets inserted at the cursor exactly the same way. There is no script whitelist anywhere in the bridge.

A Bangla row is exactly as valid as a QWERTY row​

const BANGLA_ROW_1 = ['ঙ', 'অ', 'আ', 'ই', 'ঈ', 'উ', 'ঊ', 'ঋ', 'এ', 'ঐ'];

<View style={styles.row}>
  {BANGLA_ROW_1.map((letter) => (
    <TouchableOpacity key={letter} onPress={() => commitText(letter)}>
      <Text style={styles.key}>{letter}</Text>
    </TouchableOpacity>
  ))}
</View>

No special-casing, no separate rendering path, no "non-Latin mode" flag threading through the component tree. It's the same commitText(letter) call as any other key.

Right-to-left scripts​

Arabic keys work identically:

<TouchableOpacity onPress={() => commitText('ا')}>
  <Text style={styles.key}>ا</Text>
</TouchableOpacity>

The keyboard UI itself rendering right-to-left (row order, key alignment) is a React Native layout concern you control with flexDirection and I18nManager, exactly like any other RN screen — the library doesn't need to know about text direction at all, because it never interprets the string, it only inserts it.

Multiple layouts, one keyboard​

The natural next step is a language switch key:

const [language, setLanguage] = useState<'en' | 'bn'>('en');
const rows = language === 'en' ? ENGLISH_ROWS : BANGLA_ROWS;

<TouchableOpacity onPress={() => setLanguage((l) => (l === 'en' ? 'bn' : 'en'))}>
  <Text>🌐</Text>
</TouchableOpacity>

This is in-app layout switching — a useState toggle that swaps which row data you render. It's a different concern from switchToNextInputMethod, which asks the OS to switch to a different installed keyboard entirely. Most bilingual keyboards want the former: one installed keyboard, two (or more) layouts, one language-switch key. See the multi-language tutorial for the complete bilingual example.

Frequently asked questions​

Can a React Native keyboard support non-English languages like Bangla or Arabic?​

Yes. commitText takes a plain Unicode string with no script restriction — Bangla, Arabic, Devanagari, CJK, Cyrillic, and any other script work identically to English, with no separate API or "non-Latin mode."

How do I switch between languages inside one keyboard?​

Use local useState to track the active language and swap which row of key data you render — a 🌐 key that toggles state, not a call into the native bridge. This keeps multiple layouts inside one single installed keyboard app.

Does this support right-to-left (RTL) languages?​

Yes — commitText('ا') (Arabic) works exactly like commitText('a'). RTL layout direction (row/key alignment) is handled with standard React Native flexDirection/I18nManager, the same way any RTL screen is built.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

Start with the keys​

A keyboard component is just state plus a grid of buttons. No special base class, no required props shape:

import { useState } from 'react';
import { View, Text, TouchableOpacity, StyleSheet } from 'react-native';
import { commitText, deleteSurroundingText } from 'react-native-keyboard-bridge';

const ROWS = [
  ['q', 'w', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p'],
  ['a', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l'],
  ['z', 'x', 'c', 'v', 'b', 'n', 'm'],
];

export default function KeyboardApp() {
  const [shift, setShift] = useState(false);

  function press(letter: string) {
    commitText(shift ? letter.toUpperCase() : letter);
    if (shift) setShift(false);
  }

  return (
    <View style={styles.container}>
      {ROWS.map((row, i) => (
        <View key={i} style={styles.row}>
          {row.map((letter) => (
            <TouchableOpacity key={letter} style={styles.key} onPress={() => press(letter)}>
              <Text style={styles.label}>{shift ? letter.toUpperCase() : letter}</Text>
            </TouchableOpacity>
          ))}
        </View>
      ))}
    </View>
  );
}

commitText is the one function doing the real work — it inserts text at the cursor through InputConnection on Android and textDocumentProxy on iOS. Everything else here is plain React Native UI.

Add shift, backspace, space, and enter​

<TouchableOpacity onPress={() => setShift((s) => !s)}>
  <Text>⇧</Text>
</TouchableOpacity>

<TouchableOpacity onPress={() => deleteSurroundingText(1, 0)}>
  <Text>⌫</Text>
</TouchableOpacity>

<TouchableOpacity onPress={() => commitText(' ')}>
  <Text>space</Text>
</TouchableOpacity>

<TouchableOpacity onPress={() => commitText('\n')}>
  <Text>⏎</Text>
</TouchableOpacity>

deleteSurroundingText(before, after) removes characters relative to the cursor — (1, 0) is a standard single-character backspace. There's no special "enter" API to call; committing a newline character is exactly what a hardware Return key does from the text field's point of view.

Register it​

import { AppRegistry } from 'react-native';
import KeyboardApp from './src/keyboard/KeyboardApp';

AppRegistry.registerComponent('KeyboardApp', () => KeyboardApp);

The name KeyboardApp is fixed — both native modules request a surface with exactly this component name. Run npx react-native-keyboard-bridge setup-ios once for the iOS App Extension target, and Android needs no extra wiring at all.

That's a fully working keyboard in under 60 lines. From here, the full tutorial continues into multi-language layouts, swipe typing, word prediction, and the polish details (haptics, click sounds, auto-capitalization) that make a keyboard feel native.

Frequently asked questions​

How do I make a custom keyboard in React Native?​

Write a plain component using View/Text/TouchableOpacity, call commitText/ deleteSurroundingText from react-native-keyboard-bridge on key presses, and register it under the fixed name KeyboardApp in your index.js. No schema or special base class required.

Do I need a different component for Android and iOS?​

No — the exact same KeyboardApp.tsx file runs unmodified on both platforms.

How does the backspace key work?​

deleteSurroundingText(before, after) removes characters relative to the cursor — deleteSurroundingText(1, 0) deletes exactly one character before the cursor, the same as a standard backspace.

Try it yourself​

This is a real, working library, not a proof-of-concept — install it and build your own keyboard:

yarn add react-native-keyboard-bridge

• 📖 Full documentation & tutorial
• ⭐ Source on GitHub
• 📦 Package on npm

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.

What "runs live" actually means​

This isn't a schema you configure, and it isn't a compiled subset of JSX rendered by a hand-written interpreter. It's Hermes + JSI + Fabric — the exact same New Architecture stack any other React Native screen in your app uses — hosted inside a process that most people assumed couldn't afford it.

import { useState } from 'react';
import { View, Text, TouchableOpacity, StyleSheet } from 'react-native';
import { commitText, deleteSurroundingText } from 'react-native-keyboard-bridge';

export default function KeyboardApp() {
  const [shifted, setShifted] = useState(false);
  return (
    <View style={styles.row}>
      {['q', 'w', 'e', 'r', 't', 'y'].map((key) => (
        <TouchableOpacity key={key} onPress={() => commitText(shifted ? key.toUpperCase() : key)}>
          <Text style={styles.key}>{shifted ? key.toUpperCase() : key}</Text>
        </TouchableOpacity>
      ))}
      <TouchableOpacity onPress={() => deleteSurroundingText(1, 0)}>
        <Text style={styles.key}>⌫</Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  row: { flexDirection: 'row', justifyContent: 'space-around' },
  key: { fontSize: 18, padding: 8 },
});

That's the entire keyboard. No KeyLayout schema to learn, no proprietary DSL, no platform-specific branch in your component. commitText takes a plain Unicode string, so this works identically whether you're typing English, Bangla, Arabic, or any other script.

One install​

yarn add react-native-keyboard-bridge

The JS bridge, the Android native module (autolinked), the iOS native module, gesture/ swipe-typing helpers, word prediction, and the iOS setup CLI all ship in this single package. See the Installation guide to get a keyboard running in your app today, or read Building Your First Keyboard for a full walkthrough.

Frequently asked questions​

Can you build a custom keyboard app with React Native?​

Yes. react-native-keyboard-bridge hosts a real, live React Native runtime — Hermes, JSI, and Fabric — directly inside the Android IME process and the iOS Custom Keyboard Extension process. Your keyboard component runs unmodified, the same way any other React Native screen does.

Is it a real Android IME and a real iOS Custom Keyboard Extension, or just a demo?​

Both are real, installable system keyboards. On Android, CustomKeyboardService extends InputMethodService directly. On iOS, KeyboardViewController extends UIInputViewController inside a genuine Xcode App Extension target. Once installed and enabled, either one appears in the OS keyboard list exactly like any native keyboard app.

Do I need to write any native Kotlin or Swift code?​

No. The native side (Kotlin on Android, Swift on iOS) is entirely provided by the library — it only wires up the runtime and a text-editing bridge. Your own code is 100% React Native/TypeScript.

Does it support languages other than English?​

Yes — commitText takes a plain Unicode string with no script whitelist, so Bangla, Arabic, Devanagari, CJK, Cyrillic, and right-to-left layouts all work identically to English. See How to Support Multiple Languages in a React Native Keyboard.

What React Native version does it require?​

React Native 0.74 or later (New Architecture / Fabric), since the library depends on ReactHost on Android and RCTReactNativeFactory on iOS — both New Architecture APIs.

Try it yourself​

• 📦 Install: yarn add react-native-keyboard-bridge
• 📖 Full docs & step-by-step tutorial: developerrejaul.github.io/react-native-keyboard-bridge
• ⭐ Source & issues: github.com/DeveloperRejaul/react-native-keyboard-bridge
• 📦 Package: npmjs.com/package/react-native-keyboard-bridge

If you've ever been told "you can't build a real keyboard in React Native," this library — and the working example app in the repo — is the counter-argument.