# react-native-avoid-softinput: a native fix for keyboard-covered inputs

> This React Native library listens for soft input events on the native side and translates the root view, or pads a scroll view, so a focused field is never hidden behind the keyboard. It supports the New Architecture, falls back to a View on out-of-tree platforms, and works with Expo development builds but not Expo Go.

**mateusz1913/react-native-avoid-softinput** — Native solution for common React Native problem of focused views being covered by soft input view.

- Repository: https://github.com/mateusz1913/react-native-avoid-softinput
- Website: https://mateusz1913.github.io/react-native-avoid-softinput/
- Stars: 805 · Forks: 22
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mateusz1913-react-native-avoid-softinput

## The fix is applied natively, and only when it is needed

The problem is the classic React Native one: a focused view ends up underneath the soft input view and the user cannot see what they are typing. The README describes the solution as a native one, solved by listening for soft input events and applying translation to the React root view, or bottom padding if the focused element's parent is a scroll view, entirely on the native side, and only if the currently focused view is covered by the soft input frame. Three design decisions follow from that sentence. Doing it natively means the adjustment does not cost a JavaScript round trip per keyboard frame. Doing it at the root view means you do not have to wrap every input. And conditioning on whether the focused view is actually covered means a layout that is already clear of the keyboard is left alone, so there is no spurious movement on screens that did not need it.

## Scroll views, plain views and modals are all handled differently

The library supports focused views positioned in scroll views and in regular views, and the example app demonstrates both the form case and the sticky footer case. The distinction matters because the remedy differs. When the focused element's parent is a scroll view, the library applies bottom padding rather than translating the whole tree, so the scroll content can still move. When the focused element is in an ordinary view, the root view is translated instead. Modal content is supported as well, but through a different entry point, the AvoidSoftInputView component, which you wrap the modal content in. That is the piece of the API worth noting before you plan your layout, because it means modal screens need an explicit wrapper rather than picking up the behaviour automatically. The docs site carries separate guides for using the module and for using the view, and the README defers to both.

## Installation is a package add and a pod install

The library supports Android and iOS, and for out-of-tree platforms the View component is used as a fallback. The install itself is a package manager add:

```sh
yarn add react-native-avoid-softinput
```

or with npm:

```sh
npm i --save react-native-avoid-softinput
```

On iOS you then install the pods:

```sh
npx pod-install
```

That third step is the one people forget, and it is easy to miss because the JavaScript side will import cleanly while the native module is absent at runtime. The Getting Started section of the documentation site is the reference for the full flow. The repository itself is a Yarn workspace with packages/* and the actual library in packages/react-native-avoid-softinput, and the root package.json is marked private with the author as Mateusz Mędrek. The project publishes with a versioned release script rather than by hand, with separate release, release:pre-release, release:major, release:minor and release:patch scripts.

## Expo works, but only with a development build

The Expo section is two lines and they are decisive. You can use the library with Development Builds, and no config plugin is required. You cannot use it in the Expo Go app, because it requires custom native code. That is a hard boundary for anyone whose workflow is Expo Go, and it is the kind of thing better to find out before writing the layout than after. The absence of a config plugin is the good news: there is no plugin to add to your app.json, no prebuild hook to wire up, and the native module is picked up from the development build like any other. For teams already on development builds the cost of adopting this is close to the install cost. For teams on Expo Go the cost is a migration to development builds, which is a project decision rather than a library decision.

## Support follows the React Native releases policy

The support statement is specific and worth reading literally. The library follows the React Native releases support policy, and it is supporting the latest version and the two previous minor series. You may find it working correctly with some older React Native versions, but that is a use at your own risk case. That is a sensible policy for a library with native code on both platforms, because the React Native release cycle determines when the underlying view and keyboard APIs change. The README also states that the library supports the New Architecture, which matters if your app has already migrated. The version history is moving briskly, with v9.0.0 on 2026-05-13 and v9.0.1 on 2026-09-13 after v8.0.2 on 2025-10-02, and the last push was on 2026-10-08, so the 9.x line is the one to read the docs for.

## Native code on both platforms, with linting for each

The repository layout shows what it takes to maintain a native module properly. There is a packages/ directory holding the library, separate from the root, and the root scripts reveal the toolchain. Linting is split by language: lint:js runs eslint over the JavaScript and TypeScript and then prettier with the project config, lint:android runs the Gradle wrapper in the library's android directory with the spotlessCheck task, and lint:ios:objc runs a scripts/clang-format.sh script in lint mode. Formatting mirrors that split with format:js, format:android running spotlessApply, and format:ios:objc running the same clang-format script in format mode. There is a .clang-format file at the root, a lefthook.yml for git hooks, an eslint.config.mjs, a .prettierrc.js, and a PUBLISHING.md describing the release process. The native code is in Objective-C on iOS and Java or Kotlin on Android, and the library ships a TypeScript interface over both.

## What it does not do, and where to look instead

The limitation to be clear about is scope. The library adjusts a view so it is not hidden by the keyboard. It does not reflow your layout around the keyboard, it does not tell you the keyboard height in JavaScript, and it does not give you a scroll-into-view behaviour the way a native text field does on iOS. If your screen needs the keyboard to push content up rather than the focused field to move, this is the wrong shape of tool. The README anticipates exactly this and points to an alternatives section on the documentation site, so the honest evaluation path is to read that page first, because there may be a different library or a platform-level behaviour that fits your case better. The MIT licence and the LIMITATION of the mechanism both point the same way: use it when your problem is precisely that a focused view is covered, and read the alternatives when it is not.

## Conclusion

Adopt react-native-avoid-softinput if you have a React Native form where the keyboard covers the focused input, and you want the fix applied natively rather than computed in JavaScript on every keystroke. Do not adopt it if your app ships in Expo Go, because the library requires custom native code, and check the alternatives section first if your layout needs something the translation approach cannot express. Before you commit, read the usage guides for the module and the view, confirm your React Native version is within the supported window of the latest version and the two previous minor series, and remember that the last push was on 2026-10-08.

## FAQ

### What is react-native-avoid-softinput?

It is an MIT licensed React Native library that provides a native solution to the common problem of focused views being covered by the soft input view. It listens for soft input events and applies translation to the React root view, or bottom padding if the focused element's parent is a scroll view.

### How do I install react-native-avoid-softinput?

Add the package with yarn add react-native-avoid-softinput or npm i --save react-native-avoid-softinput, then on iOS install the pods with npx pod-install. The library supports Android and iOS, and falls back to a View component on out-of-tree platforms.

### Can I use react-native-avoid-softinput with Expo Go?

No. It works with Expo Development Builds with no config plugin required, but it cannot be used in the Expo Go app because it requires custom native code.

### Which React Native versions does react-native-avoid-softinput support?

It follows the React Native releases support policy, covering the latest version and the two previous minor series. Older versions may work but are a use at your own risk case, and the library supports the New Architecture.

## Sources

- [License: MIT](https://github.com/mateusz1913/react-native-avoid-softinput/blob/main/LICENSE)
- [mateusz1913/react-native-avoid-softinput on GitHub](https://github.com/mateusz1913/react-native-avoid-softinput)
- [Project website](https://mateusz1913.github.io/react-native-avoid-softinput/)
- [README](https://github.com/mateusz1913/react-native-avoid-softinput/blob/main/README.md)
- [Releases](https://github.com/mateusz1913/react-native-avoid-softinput/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mateusz1913-react-native-avoid-softinput