react-native-haptic-feedback puts Core Haptics in a trigger call

One call over two different native stacks

The library's pitch is that it is the most complete haptic feedback library for React Native, with Core Haptics on iOS, a rich Composition API on Android, custom patterns and a developer-friendly hook. The basic usage is a single import and a call:

import RNHapticFeedback from "react-native-haptic-feedback";

RNHapticFeedback.trigger("impactMedium");

// With options
RNHapticFeedback.trigger("notificationSuccess", {
  enableVibrateFallback: true, // iOS: vibrate if Core Haptics unavailable
  ignoreAndroidSystemSettings: false,
});

Named exports are also available, so the same behaviour is available as an import of trigger alone. What the API hides is the fact that the two platforms are doing genuinely different work. On iOS the type names map onto UIKit generators and the Taptic Engine, and on Android they map onto the vibration effect system with amplitudes and the Composition API for patterns. The library exists to give you one vocabulary across both, which is a reasonable trade for an app that ships to both, and the cost is that the fullest features are not equally available everywhere.

Two options decide what happens at the edges

The trigger function takes an options object with two switches, and they are worth understanding before you set either. enableVibrateFallback defaults to false, and on iOS it makes the library play AudioServicesPlaySystemSound as a last resort on devices with no Taptic Engine, for example an iPod touch. The documentation is careful to add that it has no effect on devices that do have a Taptic Engine, since those use the UIKit generators automatically, so enabling it is a compatibility switch rather than a way to change the feel on modern hardware. ignoreAndroidSystemSettings also defaults to false, and on Android it controls whether the haptic fires even if vibration is disabled in the system settings. That one has a user-facing consequence, because a user who turned vibration off for a reason can still get buzzes from your app if you set it to true.

Custom intensity behaves differently on each platform

Beyond the named types, the impact function plays a haptic with a custom intensity between 0.0 and 1.0, and the type defaults to impactMedium while the intensity defaults to 0.7. The platform mapping is stated precisely. On iOS the intensity is applied precisely via CHHapticEngine, and on Android it maps to the VibrationEffect amplitude. So the same number does not feel the same on both, since one is a parameter of a haptic engine and the other is an amplitude in a vibration, but at least the number is the same. The named exports version is short:

import { impact } from "react-native-haptic-feedback";

impact("impactHeavy", 0.3); // gentle heavy tap
impact("rigid", 1.0); // full-force crisp tap

The pair of examples is a good illustration of the idea, since a heavy tap at low intensity and a rigid tap at full intensity are two very different textures produced by the same two parameters. There is also a stop function that cancels the current haptic player and stops the engine, and an isSupported function that synchronously returns true if Core Haptics is supported on the device on iOS 13 and newer hardware, and always returns true on Android if the device has a vibrator.

Patterns and AHAP files, and the bundling trap

Two more levels of control exist. triggerPattern plays a custom sequence of haptic events, where each event has a time in milliseconds from the pattern start, an optional type of transient or continuous, a duration for continuous events, and intensity and sharpness values between 0 and 1. The second is playAHAP, which plays an Apple Haptic and Audio Pattern file and is iOS only, resolving immediately on Android. The file name is passed without any path prefix, and the native code searches in two locations in order, a haptics/ subdirectory inside the app bundle and then the bundle root. The trap is documented at length. AHAP files must be added to the iOS app bundle and they are not bundled by Metro or CocoaPods, so the setup is a manual Xcode step: create a haptics/ folder in the project directory, put the files in it, add them to the app target, and confirm they are listed under Copy Bundle Resources in the Build Phases.

A companion app for feeling the notation

The project ships a way to try the feedback types before you write code, and it is worth knowing about because haptic design is hard to iterate on without a device in your hand. Haptic Feedback Tryout is a companion app that lets you tap through all the available feedback types and compose your own patterns interactively using the o O . - = notation. It is on the App Store and on Google Play. The notation itself is the interesting part, because a pattern written in a string is compact enough to put in a config file or a database, and the tryout app is effectively the editor for that string format. For a team that has to ship a consistent set of haptics across screens, having a shared notation with a visual editor is more valuable than it sounds, since the alternative is every developer inventing a bespoke vibration.

The platform floor and the install

The requirements table is short and defines who can use the library. iOS needs 13.0 because of Core Haptics, Android needs API 23, which is Android 6.0, React Native needs 0.71.0, and the web needs browsers with the Vibration API. Installation is the standard two lines:

npm install react-native-haptic-feedback
# or
yarn add react-native-haptic-feedback

React Native 0.71 and newer uses auto-linking, so no extra steps are needed. The peer dependencies in the package manifest agree with that floor, with React at 18.0.0 or newer and React Native at 0.71.0 or newer, and the React peer is marked optional. The platform list also tells you what will not work. A web build is limited to the Vibration API, so a custom pattern or an AHAP file is not going to do anything there, and an Android device without a vibrator will make isSupported report false.

How the package is built and released

The repository is a conventional React Native library with a native side in ios/ and android/ and a podspec at the root, and it also carries a cpp/ directory in the published files list, which suggests a shared native component. The build script is bob build, the tests run under jest with a separate setupTests.js and jest.config.js, the type check uses a dedicated test tsconfig, and husky is wired to the prepare script for the git hooks. The documentation is a VitePress site with dev, build and preview scripts. The exports map is written out in full, with separate entry points for import, require and react-native conditions and a types entry, and the files list shows what actually ships, with the source, the built lib, the native folders, the app.plugin.js and the podspec, and explicit exclusions for the build directories, the gradle wrapper and the test fixtures. The releases are v3.0.0 published on 2026-03-29 with two next prereleases a fortnight earlier, the last push was on 2026-06-10, the licence is MIT, and there is a full example application in the example/ directory covering both the native projects and the app code.

Editorial conclusion

react-native-haptic-feedback fits a React Native team that wants haptics that feel deliberate rather than a generic buzz, since it covers the iOS generator types, custom intensity, multi-event patterns and real AHAP files, and the same call shape works on Android with the Composition API. It does not fit an app that must run below iOS 13 or Android API 23, and it does not fit a project that expects the library to ship audio pattern files for you. Before you add it, read the AHAP setup steps, because those files are not bundled by Metro or CocoaPods and have to be added to the Xcode target by hand, and check the pattern notation in the companion Tryout app so your custom patterns are written in the form the library expects.

Frequently asked questions

Official sources

1. License: MIT
2. mkuczera/react-native-haptic-feedback on GitHub
3. Project website
4. README
5. Releases