# react-native-keyboard-manager: an iOS keyboard wrapper that the project itself has deprecated

> react-native-keyboard-manager fixes the classic iOS problem of the keyboard covering a text input by wrapping IQKeyboardManager, and the repository now carries a deprecation notice saying the project is in maintenance mode with no new features planned, because Android edge-to-edge has made the same problem cross-platform. The recommended replacements are KeyboardAvoidingView and react-native-keyboard-controller.

**douglasjunior/react-native-keyboard-manager** — (DEPRECATED) ⚛ Library to prevent issues of keyboard sliding up and cover inputs on React-Native iOS projects.

- Repository: https://github.com/douglasjunior/react-native-keyboard-manager
- Website: https://www.npmjs.com/package/react-native-keyboard-manager
- Stars: 1,000 · Forks: 61
- Language: Objective-C
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/douglasjunior-react-native-keyboard-manager

## The deprecation notice, and why edge-to-edge forced it

The first thing in the repository is a deprecation notice, and it explains the project's end state better than any feature list could.

The library was created to address iOS-only keyboard issues, such as the keyboard covering inputs, by integrating IQKeyboardManager. The reason it is deprecated is stated in terms of the platform shift: with Android moving to edge-to-edge by default, similar keyboard covering input problems can now happen on Android as well, and because of that, maintaining a library that only targets iOS no longer makes sense.

The consequence is a specific mode of maintenance. The project is now in maintenance mode, with bug fixes and small PRs welcome, but no new features planned. The notice closes with a thank you for the partnership and collaboration over these 9 years of the project's journey.

That nine year figure is a useful anchor for the lifecycle. The library solved a real, narrow, iOS-only problem that every React Native app with a form hit, and the problem it solved has now spread to Android, which makes an iOS-only wrapper the wrong shape.

Two alternatives are recommended. KeyboardAvoidingView, which ships with React Native itself, and an edge-to-edge approach with react-native-keyboard-controller, which is cross-platform, with a link to its repository.

The metadata is consistent with the notice. The project description is prefixed with (DEPRECATED), the repository is not archived, and the last push was on 2026-10-17. The primary language is Objective-C, the licence is MIT, and the topic tags name the territory: hacktoberfest, ios, iqkeyboardmanager, keyboard and react-native.

## The version table you need before installing anything

Before the install steps, the README carries a version compatibility table, and skipping it is how people end up with a broken build. Each React Native range has a specific published version of this library:

For RN 0.72.0 or later, use react-native-keyboard-manager@latest. For RN 0.60.0 through 0.71.X, use react-native-keyboard-manager@6.5.11-2. For RN 0.53.0 through 0.59.10, use react-native-keyboard-manager@4.0.13-12. For RN 0.47.0 through 0.52.2, use react-native-keyboard-manager@4.0.13-5. For RN 0.40.0 through 0.46.4, use react-native-keyboard-manager@4.0.13-1.

The version jumps are large, and the peer dependency range in package.json explains why. It declares react-native as >=0.60, so the older 4.x lines are pre-peer-dependency versions, and the 6.x line covers the era before the latest release. If your app is on RN 0.60 or newer, @latest is the right target and the rest of the table is history.

The published version in package.json is 6.5.16-0, and the release tags show a parallel preview line. The recent releases are 6.5.16-0 on 2024-05-06, 7.0.2-0 tagged as 7.0.2-0 (PREVIEW) on 2024-05-02, and 6.5.11-2 on 2023-06-28. A preview tagged release sitting next to the stable one is a sign of an upgrade path that was started and not finished, and the deprecated status means it will not be finished now.

So the version story is clear. The stable line for modern React Native is 6.5.x, the 7.x preview exists, and the newest published release is from May 2024 while the repository itself was pushed in October 2026.

## Installing, and the forked pod you inherit

The install has four steps, and the third one is the part people find surprising.

The JavaScript dependency, with yarn:

```sh
yarn add react-native-keyboard-manager
```

or with npm:

```sh
npm i -S react-native-keyboard-manager
```

Then the CocoaPods dependency goes into your ios/Podfile, and it is not the upstream library:

```ruby
# Add temporary IQKeyboardManagerSwift fork to solve problems with PrivacyInfo.xcprivacy
pod 'IQKeyboardManagerSwift', :git => 'https://github.com/douglasjunior/IQKeyboardManager.git', :branch => 'react-native-keyboard-manager'
```

The comment explains why. It is a temporary fork of IQKeyboardManagerSwift, on a branch named react-native-keyboard-manager, added to solve problems with PrivacyInfo.xcprivacy. That is Apple's privacy manifest requirement, and the upstream library needed a fix that the maintainer applied in a fork rather than upstream. The word temporary in the comment is doing some work, and it is worth knowing that a fork with that name may not be maintained in perpetuity, which is one more reason to consider the alternatives.

The README also notes that to automate this process on Expo you may need to create a plugin, with a link to a specific issue comment. That is the shape of the Expo story, and the known issues section says plainly that if your project is managed by Expo you will need to eject.

Then the pods install:

```sh
cd ios
pod install
```

And an optional step, to force IQKeyboardManagerSwift to update to the latest commit on the fork branch:

```sh
cd ios
pod update IQKeyboardManagerSwift
```

There is also a post install step that is not optional in practice. Because IQKeyboardManager is written in Swift, you need to enable Swift on your native Xcode project. Open ios/YourAppName.xcworkspace in Xcode, right click on YourAppName in the Project Navigator, click New File, create a single empty Swift file with the YourAppName target selected, and when Xcode asks, press Create Bridging Header and do not remove the Swift file. Then re-run the build. An empty Swift file whose only job is to trigger the bridging header is a well known React Native native module ritual, and it is the price of using a Swift based dependency in an Objective-C library.

## The JavaScript API, which is a thin pass-through to IQKeyboardManager

The usage section is honest about how much this library is. It does not need any extra library setup to work, just install and go, and if you need some configuration, there are some options available.

The configuration is done through a set of setters on a default export, and the shape of the API is one to one with IQKeyboardManager's own, which is why the documentation points you to the official IQKeyboardManager documentation for details.

```js
import { Platform } from 'react-native';
import KeyboardManager from 'react-native-keyboard-manager';

if (Platform.OS === 'ios') {
    KeyboardManager.setEnable(true);
    KeyboardManager.setEnableDebugging(false);
    KeyboardManager.setKeyboardDistanceFromTextField(10);
    KeyboardManager.setLayoutIfNeededOnUpdate(true);
    KeyboardManager.setEnableAutoToolbar(true);
    KeyboardManager.setToolbarDoneBarButtonItemText("Done");
    KeyboardManager.setToolbarManageBehaviourBy("subviews"); // "subviews" | "tag" | "position"
    KeyboardManager.setToolbarPreviousNextButtonEnable(false);
    KeyboardManager.setToolbarTintColor('#0000FF'); // Only #000000 format is supported
    KeyboardManager.setToolbarBarTintColor('#FFFFFF'); // Only #000000 format is supported
    KeyboardManager.setShouldShowToolbarPlaceholder(true);
```

The remaining options follow the same pattern, covering keyboard appearance, resigning on touch outside, input click sounds, and a promise based isKeyboardShowing query that resolves to a boolean. The inline comments carry real constraints, and two of them are worth knowing before you copy the block. setToolbarTintColor and setToolbarBarTintColor only support the #000000 format, so a hex colour with an alpha channel or a named colour will not behave as written. setToolbarManageBehaviourBy takes one of three strings, subviews, tag or position, which determines how the toolbar decides which field to navigate from.

The Platform.OS guard around the whole block is not optional decoration. The library is iOS only, and the original README says so directly: this is only for iOS, Android no needed, and for Android just add android:windowSoftInputMode="adjustResize" to your activity.

Two features need a special step. The next and previous toolbar buttons have to be switched on explicitly with setToolbarPreviousNextButtonEnable(true). And if you want those buttons inside a Modal, you need to wrap the fields in a PreviousNextView, which is imported from the package and wraps all the TextInput components in the modal.

## Known issues, jest mocking, and where the project actually stands

The known issues section is short, which is a good sign about a library in maintenance mode.

If your project is managed by Expo, you will need to eject. Pod install failed on M1 machines, with a link to a specific issue. And a problem with @react-navigation/native-stack and IQKeyboardManager on iOS is struck through, with a note that it seems to be fixed in version 6.5.16-0.

For testing, the package ships a jest mock, and the README gives the one line to add:

```js
jest.mock('react-native-keyboard-manager', () => require('react-native-keyboard-manager/jest/mock'));
```

The repository layout supports the picture that emerges. There is a ReactNativeKeyboardManager.podspec at the root, which is the CocoaPods packaging, an ios/ directory for the native side, a src/ directory for the JavaScript, a jest/ directory for the mock, a dist/ directory, and a Sample/ project with its own install.sh, metro.config.js, babel.config.js and a FormScreen.tsx that the README points to as the more complete example. There is also DEPENDENTS.md, a file whose presence tells you the author tracked who depended on the package, and a scripts/ directory with the publish script referenced from package.json.

The build is TypeScript, with the build script running tsc, and the package main field pointing at src. The development dependencies place the project at React 18.2.0 and React Native 0.74.0, with TypeScript 5.0.4, eslint, prettier, jest and babel-jest, plus the React Native eslint, metro, babel and typescript configs at 0.74.81.

The maintenance picture is a date rather than a label. The repository is not archived and the last push was on 2026-10-17, so the branch is still receiving something, but the newest published release is 6.5.16-0 from 2024-05-06 and the project declares no new features planned. The licence is MIT, with a LICENSE file at the root, so there is no complication in the code itself. The complication is operational: a deprecated library with a forked Swift pod, an empty bridging header file, and a version table that must be matched to your React Native version.

## Conclusion

react-native-keyboard-manager still fits a React Native iOS project on an older React Native version whose inputs are covered by the keyboard and that has already accepted a Swift bridging header and a forked IQKeyboardManagerSwift pod. It is the wrong choice for a new project, because the project itself is in maintenance mode and points you at KeyboardAvoidingView and react-native-keyboard-controller instead. Before adopting, check which React Native version your app is on against the version table in the notes, and remember that the installed pod is a fork rather than upstream IQKeyboardManagerSwift, so the CocoaPods line in your Podfile is part of the maintenance you inherit.

## FAQ

### Is react-native-keyboard-manager still maintained?

The project is deprecated and in maintenance mode, with bug fixes and small pull requests welcome but no new features planned. The README recommends KeyboardAvoidingView from React Native and react-native-keyboard-controller as alternatives, and the last push was on 2026-10-17.

### Which version of react-native-keyboard-manager should I install for my React Native version?

For RN 0.72.0 or later use react-native-keyboard-manager@latest. For RN 0.60.0 to 0.71.X use 6.5.11-2, for RN 0.53.0 to 0.59.10 use 4.0.13-12, for RN 0.47.0 to 0.52.2 use 4.0.13-5, and for RN 0.40.0 to 0.46.4 use 4.0.13-1.

### Why does the Podfile need a fork of IQKeyboardManagerSwift?

The Podfile entry points at a temporary fork on the maintainer's own repository, on a branch named react-native-keyboard-manager, and the comment in the README says it is there to solve problems with PrivacyInfo.xcprivacy, the Apple privacy manifest.

### How do I mock react-native-keyboard-manager in jest?

Call jest.mock with the package name and point it at the bundled mock module, so jest.mock('react-native-keyboard-manager', () => require('react-native-keyboard-manager/jest/mock')).

## Sources

- [douglasjunior/react-native-keyboard-manager on GitHub](https://github.com/douglasjunior/react-native-keyboard-manager)
- [License: MIT](https://github.com/douglasjunior/react-native-keyboard-manager/blob/main/LICENSE)
- [Project website](https://www.npmjs.com/package/react-native-keyboard-manager)
- [README](https://github.com/douglasjunior/react-native-keyboard-manager/blob/main/README.md)
- [Releases](https://github.com/douglasjunior/react-native-keyboard-manager/releases)

---

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