How are you planning on long-term maintenance? && Expo support

[XChikuX]

Hi Marco,

First of all, appreciate this repo!!

I tried maintaining my own for fork and found it very cumbersome and truly appreciate that you have taken this upon yourself. I am hoping to stop development of that fork..

However, I have some concerns. I didn't really want to be officially recommended due to them

As I see it, you are a solo developer who has recently started contributing to opensource from what I can see in your github.

1. Will this repository be maintained in the years to come?

   • Android and iOS are going to keep changing rules around notifications, will you be able to keep up?

2. Expo support - CNG (continuous native generation)

   • Some features such as Notification Service Extension can be automated with expo config plugins

If you can cover these two aspects, I can officially archive my fork. Otherwise I will have to maintain my fork alongside your changes.

Again, thank you so much for your hard work!

[marcocrupi]

Hi @XChikuX,

thanks for the kind words and for raising these concerns, they're the right questions to ask, and you deserve concrete answers rather than vague reassurances.

On long-term maintenance

You're right: I'm a solo developer and my OSS footprint is relatively recent. I won't pretend otherwise. But the context matters.

I maintain this fork because I actually use it. It's a dependency in [GymBroTools], a React Native fitness app I run in production, ~1,000 Android and 300+ iOS users, plus an active community of around 100 people on Telegram reporting bugs directly to me. If notifee breaks, my app breaks. That's a much stronger maintenance guarantee than good intentions: it's self-interest structurally aligned with the community's interest.

I can't promise this repo will still be here in 10 years, nobody honest can promise that about any OSS project, including the original notifee. What I can promise is that as long as I'm shipping GymBroTools, this fork will be maintained, and if I ever need to step away I'll announce it publicly and try to hand it off cleanly rather than let it rot silently.

Why not just migrate to expo-notifications?

Short version: I did the research before committing to this fork, and expo-notifications is not a drop-in replacement for apps that need Android notification depth. The gaps that matter for a fitness app:

• No foreground service API (notifee's asForegroundService), blocking for persistent workout timers
• No rich notification styles (BigPicture/BigText/Inbox/Messaging), only flat title/body
• No progress bars, no full-screen intents, no notification grouping, no native chronometer
• No built-in iOS Notification Service Extension helper

To be fair: expo-notifications has a legitimately better setup DX thanks to its config plugin, and that's exactly where I think this fork should invest next.

On Expo support (CNG / config plugins)

You're right that this is important, and it's the area where the fork can add real value. Features like NSE setup, App Groups, and foreground service manifest entries should be handled once in the library, not by every consumer.

I haven't prioritized it yet because GymBroTools uses a bare workflow so I haven't felt the pain personally, but I recognize most of the RN ecosystem is on Expo CNG now. A proper config plugin is going on the roadmap. I won't commit to a date because I'd rather ship something correct than rushed.

What's next

My immediate priority is closing out the backlog of bugs and open issues inherited from the original notifee, there's real work to do there before adding anything new, and I'd rather have a rock-solid baseline than a wider feature set on a shaky foundation. Once that's in a good place, I'll start pushing on new functionality, and the Expo config plugin is high on that list.

Your input is welcome at any point in that process, issues, PRs, design discussions, or just "hey, this is what broke for me". You've been on the maintainer side of this yourself, so you know how much that kind of feedback is worth.

And honestly, beyond the fact that GymBroTools depends on it: I'm enjoying this project. Maintaining notifee has turned into something I genuinely care about, not just a dependency I'm babysitting, and I'll keep carving out time for it regardless of where my own app goes. That's probably the most honest long-term commitment I can offer.

[XChikuX]

Appreciate the honesty.. Good luck with GymBroTools :)

[marcocrupi]

Hi @XChikuX,

quick follow-up now that react-native-notify-kit 10.4.0 is out.

This release adds official Expo CNG / prebuild support for development builds.

The main pieces included are:

• iOS FCM Mode Notification Service Extension automation through the config plugin
• generated and wired NotifyKitNSE target
• EAS app extension configuration
• Android foreground service manifest configuration through the config plugin
• Android Expo FCM smoke validation using RNFirebase data-only messages + notifee.handleFcmMessage
• Android foreground/background/tap validation
• Android foreground service shortService runtime validation

I also expanded the Expo smoke fixture so the integration is backed by real validation work, including prebuilds, device testing, FCM delivery, iOS NSE behavior, and Android foreground service runtime checks.

So Expo CNG support is now part of the library, not just a roadmap item.

If you get a chance to test the package in one of your apps, I’d be genuinely grateful: https://www.npmjs.com/package/react-native-notify-kit