wix/react-native-notifications: a native-module approach to iOS and Android push
React Native Notifications
At a glance
- What is it?
- The Wix library handles remote, local and interactive notifications by shipping its own iOS and Android native code rather than wrapping React Native's PushNotificationIOS. It targets iOS 10 and Android 5.0 (API 21), and its last push to master was on 2026-04-02.
- Who is it for?
- Adopt it if you need PushKit, interactive action buttons, or notifications that arrive while the app process is dead, and you are willing to own the native iOS and Android configuration yourself. Do not adopt it if you want a managed workflow or a JavaScript-only integration; the README gives no Expo path.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 174 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 23, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem it solves, and the developers it assumes
React Native's own PushNotificationIOS covers a narrow slice of iOS behaviour. wix/react-native-notifications exists to cover the rest: remote notifications, local notifications, background notifications that can be cleared from a server, the PushKit API for VoIP and other background messages, and interactive notifications with action buttons. On Android it handles receiving notifications in any app state, including foreground, background and dead, plus notification drawer management and an Android equivalent of getInitialNotification().
The intended reader is an engineer with a bare React Native app who is prepared to edit Xcode projects and Gradle files. The README's requirements section states that apps may target iOS 10 and Android 5.0 (API 21), and that Windows, macOS or Linux can serve as the development operating system. The package is marked nativePackage: true and its peerDependencies are react and react-native with wildcard versions, which is the library telling you it will not manage your React Native version for you.
Where the JavaScript ends and the native code begins
The repository layout shows the split plainly. There is a lib/ directory holding the compiled TypeScript output that package.json points at through main: "lib/dist/index.js" and typings: "lib/dist/index.d.ts". There is an android/ directory, an iOS podspec named react-native-notifications.podspec, and a react-native.config.js file that autolinking reads. The primary language recorded for the repository is Java, which reflects how much of the behaviour on Android is implemented natively rather than in JavaScript.
That architecture has a consequence worth stating directly. The README claims that all native iOS notifications features are supported, and it also lists local notifications and a background-state Rx queue as upcoming for Android. So the two platforms are not at parity, and the gap is documented by the project itself rather than hidden. If your product depends on scheduled local notifications on Android, the README does not promise them.
There is a separate integration note for react-native-navigation, hosted in the project wiki under the title Android: working with RNN. That is a sign the library expects to be wired into a specific navigation stack rather than dropped in blind.
Installing it and getting a first notification handler running
The README does not inline installation steps. It points to a Getting Started page at wix.github.io/react-native-notifications/docs/getting-started, and the package is published to npm as react-native-notifications. The repository's own scripts show the expected local workflow: pod-install runs pod install against example/ios, and npm run build clears lib/dist and recompiles TypeScript. The example app lives under example/, with example/NotificationsExampleApp.tsx as the entry component.
Start with the package itself:
npm install react-native-notificationsOn iOS the podspec is picked up by CocoaPods. The repository exposes a script that runs the install against the bundled example project, which is the pattern to copy into your own app:
pod install --project-directory=example/iosIf you want to read the API before wiring anything, the documentation site is the only reference the README offers, and the example app is the working reference implementation. Note that the README gives no Expo installation path and no JavaScript-only fallback; the module is native on both platforms.
Where it is the wrong tool
The clearest limitation is Android local notifications. The README lists them under Upcoming alongside a background-state Rx queue described as the iOS equivalent, which means the Android side is behind and the project says so. If your feature set is scheduled reminders that fire without a server round trip, this library does not currently cover it on Android.
The second limitation is operational. Because the module ships native code for both platforms, every React Native upgrade is a potential native rebuild, and the peer dependency range is a wildcard rather than a tested matrix. The release history reinforces this: 5.1.0 was published on 2023-09-14, 5.0.0 on 2023-07-20 and 4.3.5 on 2023-05-28. The last push to master was on 2026-04-02, but the most recent tagged release is from 2023. Anyone reading the repository activity as a signal of release cadence should look at the tags instead.
The third limitation is the documentation surface. The README is a feature list and a set of links, not a reference. It does not document rollback, migration between major versions, or what changed in 5.0.0. Those answers live in CHANGELOG.md and CHANGELOG.gren.md, generated with gren, and in the Docusaurus site under website/. Budget time for reading source when the docs stop.
How it differs from Notifee and from Expo's notification module
Notifee is the alternative that appears most often in searches about this library, and the approaches differ in a way that matters. Notifee is built by Invertase as a notification library with its own API surface and its own native implementation. wix/react-native-notifications instead leans on React Native's autolinking and a podspec, and its README frames the value in terms of iOS feature completeness: PushKit, interactive notifications, background notifications that a server can clear.
Expo's notification module is a different trade again. It assumes the Expo managed or prebuild workflow and handles the native configuration for you. This library assumes the opposite: that you own the Xcode project and the Gradle files and will configure them. The README mentions no Expo integration and no config plugin.
The practical difference is who absorbs the native complexity. Expo absorbs it and constrains your native customisation. Notifee gives you a documented cross-platform API for display and channels. wix/react-native-notifications gives you the closest thing to direct access to the platform notification APIs, including the iOS-only features the README highlights, at the cost of doing the platform work yourself.
Maintenance, licensing and the upgrade bill
The repository is not archived. The last push to master was on 2026-04-02. The most recent tagged release, 5.1.0, dates to 2023-09-14, so the gap between repository activity and published releases is worth understanding before you plan an upgrade path: code can move on master without a corresponding npm version.
Upgrade cost is driven by the native surface. A version bump can require a pod install, a Gradle sync, and changes to your iOS project settings, and the README does not document a migration procedure for major versions. The CHANGELOG.md and the gren-generated CHANGELOG.gren.md are the place to look, and the example/ directory is the reference for what a working configuration looks like at a given version.
The licence is MIT, declared in package.json and in the LICENSE file, and the README restates it. MIT permits commercial use and modification with the copyright notice retained. That is a statement about the licence text, not legal advice; if your organisation has policy around notice files or attribution in distributed binaries, check the LICENSE file itself.
Editorial conclusion
Adopt it if you need PushKit, interactive action buttons, or notifications that arrive while the app process is dead, and you are willing to own the native iOS and Android configuration yourself. Do not adopt it if you want a managed workflow or a JavaScript-only integration; the README gives no Expo path. Before committing, verify three things against your own app: that your iOS deployment target is at least 10 and your Android minSdk is at least 21, that the API surface documented at wix.github.io/react-native-notifications still matches the 5.1.0 release from 2023-09-14, and that your React Native version is compatible, since the package declares react-native as a wildcard peer dependency and pins nothing.
Frequently asked questions
How do I install wix/react-native-notifications?
Install the package from npm as react-native-notifications, then run pod install for the iOS side; the repository's own pod-install script runs it against example/ios. The README does not inline the steps and instead links to the Getting Started page on wix.github.io/react-native-notifications.
Does wix/react-native-notifications work with Expo?
The README gives no Expo installation path and no config plugin, and the module is native on both platforms with a podspec and an android/ directory. Nothing in the README describes a managed-workflow integration.
How does wix/react-native-notifications differ from Notifee?
Both are notification libraries, but this one is framed in the README around iOS feature completeness, including PushKit and interactive notifications, and it relies on autolinking plus a podspec rather than a separate cross-platform API layer. The README does not discuss Notifee, so the comparison rests on what each project documents for itself.
How do I enable push notifications in wix/react-native-notifications?
The README does not document the enablement steps itself; it links to the Getting Started and API pages on wix.github.io/react-native-notifications, and the example/ app is the working reference for configuration. On iOS the podspec is installed with CocoaPods.
How do notifications work with FCM in wix/react-native-notifications?
The README does not describe FCM configuration. It states that Android notifications can be received in foreground, background and dead app states, and links to the API documentation for the details.
Community notes