react-native-keyboard-controller: one keyboard manager for iOS and Android

What react-native-keyboard-controller is for

React Native's built-in KeyboardAvoidingView is the usual first attempt at keeping an input above the on-screen keyboard, and it is the reason this package exists. The README describes the project as "a universal keyboard handling solution for React Native" whose selling point is that it behaves the same on iOS and Android. That is the actual problem: the two platforms report keyboard geometry differently, and the workarounds tend to be platform branches scattered through screen code.

The audience is specific. This is for teams shipping chat screens, comment threads, search bars with results below them, and long forms where the focused field must stay visible. The README lists prebuilt components aimed at exactly those cases, including a reworked KeyboardAvoidingView, KeyboardStickyView, KeyboardAwareScrollView and KeyboardChatScrollView for "messenger and AI chats". If your app has one login form and nothing else, the native install cost is hard to justify. If the keyboard is central to the product, the alternative is maintaining your own platform-specific layout math.

How keyboard movement becomes animated values

The core mechanism the README advertises is mapping keyboard movement to animated values, with Reanimated support listed as a feature. That is a different model from a component that simply adds bottom padding. Instead of a boolean "keyboard is open", the library exposes the keyboard's position as a value your own animations can read, so a header can shrink, a send button can slide, or a list can offset itself in the same frame as the keyboard.

The second mechanism is the event surface. The README states that keyboardWillShow and keyboardWillHide are now available on Android, which is the part Android developers usually have to fake, since the platform historically only announced that the keyboard had already changed. Having the will-show event on both platforms is what makes a shared animation timeline possible.

The third is a set of overlay primitives rather than layout helpers. OverKeyboardView displays anything over the keyboard without dismissing it, KeyboardBackgroundView matches the keyboard background, KeyboardExtender adds custom buttons or UI to the keyboard, KeyboardEffects changes its appearance, and KeyboardToolbar provides previous, next and done buttons. KeyboardChatScrollView is the higher-level piece built from these. The README also mentions preloading the keyboard to avoid first-time focus lag and changing the soft input mode on Android, both of which are native-side capabilities rather than JavaScript ones.

Installing react-native-keyboard-controller

The README does not inline install steps. It says to check the installation section of the docs at kirillzyusko.github.io/react-native-keyboard-controller, so treat that page as the source of truth for your React Native version and follow it rather than any snippet you find elsewhere. What the repository layout tells you is what kind of install this is: the package ships android/, ios/, common/ and a react-native-keyboard-controller.podspec, and the files list includes react-native.config.js. That combination means autolinking and a native rebuild, not a JavaScript-only drop-in.

Start by adding the package to your app.

yarn add react-native-keyboard-controller

On iOS the podspec is part of the published files, so a pod install is the expected next step in your app directory.

cd ios && pod install

After that, rebuild the app on both platforms. The repository's own example app wires this up through a bootstrap script that installs example dependencies, installs root dependencies and then installs pods, which is a useful reference if your monorepo layout confuses autolinking:

yarn bootstrap

For a first real use, the smallest meaningful step is to replace one existing KeyboardAvoidingView with the library's version and confirm the screen still behaves. The README lists a reworked KeyboardAvoidingView among the prebuilt components, so the import surface is familiar. If your screen instead needs content pinned above the keyboard, KeyboardStickyView is the component named for that job. Verify on a physical Android device as well as iOS, because the will-show event behavior on Android is the feature you are paying the native install for.

Where react-native-keyboard-controller gets in the way

The cost is native. Because the package ships android/ and ios/ directories and a podspec, it cannot be used in a workflow that does not allow custom native code. The related searches include people asking about Expo Go, and that is the failure mode to understand before you start: Expo Go runs a fixed set of native modules, so a package with its own native keyboard code needs a development build instead. If your team depends on scanning a QR code to test, this changes your workflow.

The second constraint is that the library wants to own keyboard behavior. Overlay components like OverKeyboardView and KeyboardExtender assume they are the layer managing the keyboard, so mixing them with a screen that also manipulates keyboard state through a third-party input or modal library is where double-offsets and stuck offsets appear. The README does not document rollback or a partial-adoption story, so plan the migration screen by screen rather than converting the whole app at once.

Third, the animated-value API is the load-bearing part. If your project pins an older Reanimated version, or has not adopted Reanimated at all, you lose the main reason to choose this over a layout-only solution. The README lists Reanimated support as a feature, and the docs installation page is where the version requirement lives; check it before you plan the work.

react-native-keyboard-controller vs KeyboardAvoidingView and keyboard-aware-scroll-view

The built-in KeyboardAvoidingView is the default comparison, and the difference is where the logic lives. KeyboardAvoidingView adjusts a view's offset or padding in JavaScript based on keyboard events, and on Android it reacts after the fact because the will-show event was not available. This library pushes the work into native code and exposes movement as animated values, which is why it can offer will-show events on Android and why the same screen code can run on both platforms.

The other common alternative is react-native-keyboard-aware-scroll-view, a long-standing JavaScript component that wraps a ScrollView and scrolls the focused input into view. Its approach is scroll-position management inside one component; it does not give you an animated keyboard position to drive unrelated UI, and it does not provide toolbar, extender or overlay primitives. The trade-off is scope against weight: keyboard-aware-scroll-view is a component you drop in, while react-native-keyboard-controller is a native module that changes how the keyboard is represented across the app. If all you need is a form that scrolls, the smaller component is the honest answer. If you need a chat layout with a pinned composer, a toolbar above the keyboard, and an overlay that does not dismiss the input, the component-level approach runs out of room.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-22, one day before this writing. Recent releases are 1.22.5 on 2026-09-11, 1.22.4 on 2026-08-17 and 1.22.3 on 2026-08-05, so the project is being published on a roughly monthly cadence. Upgrades are ordinary semver releases of a native module, which means the real cost is not reading a changelog but rebuilding both platforms and retesting keyboard behavior on the screens you converted. Budget for that per upgrade, not per year.

The licence is MIT, stated in the README and in the LICENSE file at the repository root. For a native dependency inside an app, MIT is permissive: you can ship it in a closed-source product, and the obligation is essentially to keep the copyright and permission notice with the distributed software. This is a description of what the licence says, not legal advice for your situation; if your legal team has a policy on native dependencies, the LICENSE file is the document they will want.

Editorial conclusion

Adopt it if you are building chat, comment or form screens in a bare React Native app and you have already been bitten by KeyboardAvoidingView behaving differently on each platform. Do not adopt it if your project lives entirely in Expo Go, because the package ships native android/ and ios/ directories plus a podspec, which means a native rebuild. Before you commit, verify two things on the docs installation page: your React Native version against the current release, and whether your Reanimated version satisfies the peer requirement, since the animated-value API is the part most of the other components assume.

Frequently asked questions

Official sources

1. kirillzyusko/react-native-keyboard-controller on GitHub
2. License: MIT
3. Project website
4. README
5. Releases