Notifee is Archived. Here’s a Maintained, New-Architecture Drop-in Replacement

#reactnative #refactoring #opensource #npm

In December 2024, Notifee stopped receiving updates. In April 2026, Invertase officially archived the repository. If you shipped a React Native app that depended on Notifee’s advanced Android features such as foreground services, rich styles, progress indicators and full-screen intents, this left a real gap with no clean migration path.

I ran into that gap directly. My workout tracking app relies on local notifications and foreground-service timers to keep set counters and rest timers running when the screen is off. The official alternative, expo-notifications, doesn’t support foreground services. For this class of apps, there wasn’t a viable replacement.

So I forked Notifee, migrated it to React Native’s New Architecture (TurboModules), and started fixing long-standing issues that had accumulated in the upstream tracker. The result is react-native-notify-kit, which Invertase now links from their archived README as a community-maintained drop-in replacement.

This post isn’t a catalogue of every fix, and it’s not a takedown of the original library. The CHANGELOG has the full, detailed list. What follows is a clear picture of what the fork is, what problems it solves, and when you should (or shouldn’t) use it.

What this fork actually gives you

A few things matter immediately when evaluating whether this is relevant to your app.

It’s a true drop-in replacement. The public API is fully compatible with @notifee/react-native. Migration is literally a find-and-replace on the import path:

yarn remove @notifee/react-native
yarn add react-native-notify-kit

- import notifee from '@notifee/react-native';
+ import notifee from 'react-native-notify-kit';

The default export is intentionally still called notifee, so your existing code keeps compiling unchanged. That said, runtime behavior is not identical in all cases. Some changes are explicitly marked as BREAKING in the CHANGELOG. For example, apps using asForegroundService: true on Android 14+ must declare a foregroundServiceType in their AndroidManifest, or the library will fail fast with a clear error. Other changes include immediate foreground service notifications on Android 12+, different DELIVERED event behavior on iOS, and default pressAction values on Android. Read the CHANGELOG if your app depends on specific runtime behavior.

It’s built for modern React Native. The library targets the New Architecture only. The Android bridge has been rewritten in Kotlin as a TurboModule, while the iOS bridge now conforms to TurboModules using JSI. There is no support for the legacy Bridge. Minimum supported React Native version is 0.73, with a development target of 0.84. This wasn't just a refactor. Upstream Notifee was built against the legacy Bridge/NativeModules API, and although React Native's Interop Layer still lets old-style modules run under Bridgeless mode, upstream Notifee hasn't been tested or validated against any React Native version newer than 0.73 (its last release was December 2024, well before 0.84 shipped in February 2026). Relying on the interop layer indefinitely for a library that's no longer receiving updates isn't a position you want to be in for a production app, which is why this fork was rewritten natively against the TurboModule APIs on both platforms.

It fixes real production issues, not just edge cases.

Without turning this into a changelog, here are the main categories of problems that have been addressed so far:

• Inconsistent or broken event delivery between iOS and Android
• Foreground service instability and delayed notifications on Android 12+
• Trigger notifications failing under modern Android constraints such as Doze mode, permission changes and OEM behavior
• Interoperability issues with @react-native-firebase/messaging
• iOS delegate and lifecycle edge cases causing lost events or incorrect behavior

If you’ve used Notifee in production, these are the kinds of problems you end up working around manually.

Where this fits vs `expo-notifications`

When Invertase archived Notifee, they pointed developers to two options: expo-notifications and this fork. They solve different problems.

Use expo-notifications if you are on Expo, if you only need standard local or push notifications, or if your use case doesn’t require deep Android control. It is actively maintained, simpler to integrate, and the right choice for most apps.

Use react-native-notify-kit if your app depends on advanced Android capabilities. This includes foreground services for long-running tasks, advanced notification styles such as BigPicture or Messaging, progress notifications, persistent notifications, or full-screen intents like alarm or call screens.

In practice, if you were already using Notifee for non-trivial reasons, you likely still need those features. This fork exists so you don’t have to give them up.

Other libraries cover different parts of the stack. @react-native-firebase/messaging handles push delivery but does not provide full control over local notifications. react-native-push-notification was archived in January 2025 (read-only repository). This fork integrates cleanly with Firebase Messaging and resolves a long-standing iOS compatibility issue between the two.

Why this exists (and what it’s not)

This is not a rewrite and not a new abstraction layer. The core notification logic from Notifee is preserved. The work here focuses on keeping that core usable on modern React Native, fixing issues that block real-world apps, and making behavior more predictable across platforms.

There’s no claim that this replaces every other solution. The goal is more pragmatic. If your app depended on Notifee’s advanced feature set, you should be able to keep building without rewriting your notification system.

Long term, the direction is incremental. Improve reliability, close gaps where it makes sense, and reduce the number of hard limitations developers run into.

If you want to try it

If your app currently uses @notifee/react-native, the migration is straightforward. The real value is seeing whether your existing issues disappear or at least become easier to reason about.

If you try it, useful contributions include reporting successful migrations, reporting issues with clear reproduction steps, and sharing bugs you previously worked around.

That feedback loop is what turns a fork into a maintained project.