Everyone figured Notifee would chug along forever — it was the go-to for React Native notifications, especially those finicky Android foreground services that keep apps humming in the background. But nope. Archived in 2026, leaving a gaping hole for apps like workout trackers or anything needing persistent timers when the screen’s off.
react-native-notify-kit changes that. One dev hit the wall personally, forked it, ported to New Architecture, and now Invertase themselves link it as the community fix. No more cobbling together half-solutions.
Here’s the thing.
It’s a true drop-in. Swap the import, done. Your code compiles unchanged because the default export is still ‘notifee’. But don’t sleep on the changelog — some runtime tweaks, like mandatory foregroundServiceType on Android 14+, will slap you with clear errors if ignored.
Why Did Notifee Get Shelved Anyway?
Invertase called it quits after years of accumulated bugs. Fair enough; maintaining native bridges is a grind, especially as React Native marches toward ditching the legacy Bridge entirely in 0.84. Expo-notifications was their push, but it skips the deep Android stuff — no foreground services, no full-screen intents. Fine for basic push, worthless for power users.
This fork? Kotlin TurboModule on Android, JSI on iOS. Targets 0.73+, eyes 0.84. No legacy support. If you’re still on old RN, tough luck — upgrade or bust.
And the fixes. God, the fixes.
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.
That’s straight from the original post. Spot on. Event delivery flakiness across platforms? Gone. Foreground service crashes on Android 12+? Stabilized. Doze mode screwing triggers? Handled. Even plays nice with Firebase Messaging now, fixing that iOS headache Notifee users cursed for years.
I’ve seen this movie before — react-native-push-notification archived in 2025, leaving devs high and dry. Back then, everyone scrambled to Firebase or Expo. But for apps needing local control, it sucked. This fork? It’s the community glue holding the ecosystem together, much like those Firebase SDK forks in 2018 when Google waffled on RN support. Bold prediction: it’ll become the unspoken standard, with Invertase quietly cheering from the sidelines.
Short para for emphasis: Production-ready today.
But let’s not hype it blindly. It’s not for everyone. If you’re on Expo and happy with vanilla notifications, stick there — simpler, actively maintained. This is for the masochists who need BigPicture styles, progress bars, or alarms that punch through Doze.
Is react-native-notify-kit Production-Proof for Your App?
Yes, if Notifee was your jam. The author shipped it in their workout app already — counters ticking, rests timing, screen off. No workarounds needed.
Runtime diffs? Minor. Android 12+ shows foreground notifs immediately (safer, actually). iOS DELIVERED events behave consistently now. Press actions default sanely. Check changelog for your edge cases — it’s exhaustive, not some vague “improved stability” BS.
Interops clean too. Firebase? Fixed. No more delegate wars on iOS.
One nit: New Arch only. If you’re dragging feet on migration, this forces your hand. Good — RN’s future is TurboModules. Legacy’s a zombie anyway.
Skeptical vet take: Companies like Invertase archive when maintenance costs spike, but open source thrives on forks like this. Who’s making money? You, the dev, saving weeks of rewrites. Invertase? Free PR bump by linking it.
Why Does react-native-notify-kit Matter More Than You Think?
Notifications aren’t sexy. But they’re the backbone for fitness apps, delivery trackers, VoIP calls — anything background-heavy. Expo covers 80% of use cases, sure. The 20%? That’s where revenue lives, where user retention hinges on that “hey, your timer’s up” ping.
Without this, you’d hack foreground services manually — native modules, battery drain nightmares, App Store rejections. Fork preserves Notifee’s battle-tested core, just modernizes it. No abstraction cruft.
Historical parallel: Remember when Fabric crashed Twitter’s Android? Community bridged the gap till official fixed it. Same vibe. RN notifications were fracturing; this welds ‘em back.
Critique the spin: Original post downplays it as “not a takedown.” Please. It’s a resurrection, admitting upstream failed real apps. Invertase pointing here? Smart damage control.
Wander a sec: I’ve covered a dozen lib deaths. Most fade. This one’s sticky because API parity + New Arch lock-in equals zero migration friction.
Dense para time. Pair it with react-native-firebase/messaging for hybrid push/local — now smoothly, events routing predictably, no lost deliveries under iOS lifecycle quirks or Android OEM quirks like Huawei’s aggressive killing. Trigger notifs fire under Doze (exact alarms, partial wakelocks tuned right). Progress styles update fluidly, even in foreground service mode. Full-screen intents for calls/alarms? Crisp, permission-compliant. All while sipping less battery than old Notifee hacks.
Punchy: Devs, migrate now.
Alternatives? react-native-push-notification’s a ghost repo. Others niche or unmaintained. This is it.
🧬 Related Insights
- Read more: 800G DR4 vs 2xDR4 OSFP: Data Center Showdown No One Asked For
- Read more: 10,000 Hyperparameter Combos Later: Bayesian Optimization’s Quiet Domination
Frequently Asked Questions
What is react-native-notify-kit?
A community-maintained fork of Notifee for React Native New Architecture, fixing bugs and adding modern Android/iOS support as a drop-in replacement.
Does react-native-notify-kit work with Expo?
No, it’s bare RN only, targeting advanced features Expo-notifications skips like foreground services.
How do I migrate from Notifee to react-native-notify-kit?
yarn remove @notifee/react-native; yarn add react-native-notify-kit. Swap import to ‘react-native-notify-kit’. Check changelog for breaking changes.
