Replace all default FCM notifications with notifee

[christophemenager]

After hours of research and tries, I am faced to this question : is it possible to rely ONLY on notifee to display all notifications received from firebase cloud messaging,

Let me explain :

1. Initially, I bought a notifee licence in order to display notifications while app is in foreground state, in order to "patch" a missing feature of default fcm
2. Then I realized notifee was much more than just a foreground notification library and that I could display very nice and customized notifications to users
3. As a consequence, I tried to use notifee also when the application state was "killed" or "background", in order not to rely on the default fcm notification and to manage all notifications with notifee
4. To do so, I had to remove the notification key in the payload object sent by our server, (switch to "data-only" messages) because it's the only way to prevent fcm from displaying its default notification and avoid a duplicate notifications
5. I discovered that data-only messages have a low deliverability, especially on iOS when app is killed or in background
6. I also discovered that the best practice is NOT to use data-only messages to display notifications, at least if you care that the notification is actually displayed one day to the user

From my point of view, this implies that notifee is not usable for "background" or "killed" state, so I feel like I am back to the point 1 in my story.

Did any of those points in my investigation above is wrong ?

If all of them are true, do you confirm notifee is just made for foreground notifications ? But in that case, why do bother adding so much features (especially ones linked to messages like quick reply on android) for such a limited use case ?

Thanks a lot for your help !

[mikehardy]

I believe what you want on iOS is the notification extension helper, which allows you to intermediate the notifications that firebase-ios-sdk would generate, when you send FCM with a notification block

On android data-only deliverability is not bad, so it's iOS as the platform to focus on

https://notifee.app/react-native/docs/ios/remote-notification-support

@helenaford is my thinking here correct + current? That notifee may control all notification presentation in an FCM context, even with notification blocks in FCM used to overcome data-only delivery issues?

[marcel-happyfloat]

I'm having the exact same questions and with my current project I try to make it work also for background/push notifications.

In my last project I only used notifee to set the badgeCount and everything else was done by FCM notification object...

Currently I'm going the way @mikehardy describes, so for iOS I still use the notification object, but it will be extended locally with the extension helper. For Android I do data-only with high priority. I have yet to verify that this really works in all cases reliable.

[christophemenager]

Thanks a lot @mikehardy I actually missed this part from the documentation, I am sorry :/

Thanks @happyfloat, I will try to do exactly the same as you did, I will tell you here if it works ok :)

I think it could be great to add a documentation section to answer this issue, it will help people increase their usage of this nice library and avoid them from wasting time like I did !

[mikehardy]

@helenaford this is a reasonable documentation request, it's probably the hottest area of activity (ios notification extension helper) and area of largest friction (by volume of issues) in this repo - "how to take full control of notifications and enjoy reliable delivery", right?

[helenaford]

Thanks all. This is a helpful insight. We've been planning on making it easier to use notifee events with any notification, whether it's local or remote. I will have more information by the end of this week on when these changes will be released. And, along with that will be a revamp of the docs to make the onboarding as painless as possible 🙏

[christophemenager]

Really good news @helenaford ! Looking forward to it 😃

[arunim2405]

@helenaford any updates on this? I am in a similar situation, I can use notifee_options key but I have no way to differenciate between ios and android devices when I am generating the message object, how can I include notification key only for ios?

[000xuandu]

@christophemenager

i haven't tried with ios helper,
With android os, i have tried with the case of just using data key with high priority in fcm object.
this did not duplicate the notification when in background/quit.

[helenaford]

Quick update, there's an alpha release (4.0.0-0) that handles Press, Dismiss and Action_Press events for remote notifications. More info here.

The next part that should be ready soon is the incoming events when a remote notification is received which can be tracked here.

[mikehardy]

We're not competing with those other libraries because they're not really competing. They're struggling to exist, e.g.:

https://github.com/zo0r/react-native-push-notification/

State of the repository

This repository is not actively maintained. The main reason is time. The second one is probably the complexity of notifications on both iOS and Android. Since this project probably need a huge refactor to fix some issue or to implement new features. I think you should probably consider these alternatives: Notifee free since september or react-native-notifications.

If you are interested in being a maintainer of this project, feel free to ask in issues.

https://github.com/wix/react-native-notifications/graphs/commit-activity

Remote notifications, you want https://rnfirebase.io/messaging/usage
Local notifications: here you are!

They work together, pretty seemlessly already unless you have some special needs, like "I want to include images in my iOS remote notifications" or "I want to send remote notifications to iOS devices with button handlers that bind to Notifee actions"

In other words, if you're just sending remote notifications to devices via FCM, and you want Notifee to handle the taps, it's already working.

So, comparisons are out really, and when it comes to working products, RNFB/messaging + Notifee handles tons of cases, though not all.

Which is to say, if you want to make product progress: what is your exact use case. Like, the real JSON you're sending as a remote message, and the detailed user experience you want?

[mikehardy]

That was to @icecapp by the way, who appears to have removed his comment. The comment is valid standalone though, despite perhaps being confusing as it's clearly an answer to a non-existent question now.

[icecapp]

@mikehardy my bad! Posted a bit hastily and further reading invalidated a bunch of points, so figured I wouldn't waste maintainers' time further but ... guess that didn't quite go as planned 😄

[mtt87]

👋 Hi, landing here after trying to work out how RN Firebase + Notifee work together.

From what I can see, in this specific situation, notifee.onForegroundEvent() and notifee.onBackgroundEvent() never work because the only way to handle messages is through RN Firebase methods messaging().onMessage() (foreground) and messaging().setBackgroundMessageHandler().

BUT if I follow the guide https://notifee.app/react-native/docs/ios/remote-notification-support and I add the remote notification support, it doesn't seem to do anything at all so not sure how all these pieces can work together.

Our use case is a sort of authenticator where you have 2 actions to approve or deny:

• app in foreground: take the user to a screen that shows a UI with 2 buttons for approve/deny
• app in background: show 2 action buttons in the push notification (approve / deny) and when pressed send an API request in the background
• • app killed: show 2 action buttons in the push notification (approve / deny) and when pressed send an API request in the background

We initially tried to build this only with RN Firebase but somehow were not able to create the 2 action buttons and we needed to use Notifee but then we end up in this situation where it's not clear what is handled by Notifee and what is handled by RN Firebase.

[arunim2405]

@mikehardy @helenaford I am in a similar situation now as @mtt87 where I integrated https://notifee.app/react-native/docs/ios/remote-notification-support but I cannot seem to figure out how to handle interactions notifee.onForegroundEvent() and notifee.onBackgroundEvent() are never called for remote notifications although when I create local notifications I am able to use notifee.onForegroundEvent()

[izakfilmalter]

I started playing around with this after coming to the same conclusions as many in this thread had.

My server code was using admin.messaging().sendToDevice( ... ). I wasn't able to pass anything to NotifeeExtensionHelper no matter what combination of things I did.

I then switched over to admin.messaging().sendMulticast( ... ) which has similar functionality, I have an array of notification tokens that I want to send the same notification to. This allowed me to follow https://notifee.app/react-native/docs/ios/remote-notification-support#edit-the-payload, resulting in NotifeeExtensionHelper picking up my notifee_options.

I am still struggling with getting on press events for the notification working. Will update when I get that cleared up.

Update 1:
One thing I noticed was that data wasn't working with this model anymore. I ended up passing the data I needed directly into notifee_options.ios, and this made it to the device successfully.

Update 2:
Seems like notifee.onForegroundEvent( ... ) is working for me when the app is open and I receive a notification.

Update 3:
When I was doing data only notifications, I was doing an isHeadless check outlined here: https://rnfirebase.io/messaging/usage#background-application-state. It seems like I don't need to do that anymore. When I press on a notification now, and the app opens after being fully quit, isHeadless is true causing issues.

Update 4:
I was really struggling to get opening notifications while the app is closed to interact with react-navigation, and go to the correct route. Before I was doing the following:

• notifee.getInitialNotification( ... ) within getInitialURL: https://reactnavigation.org/docs/navigation-container/#linkinggetinitialurl. This was getting triggered when the app was fully closed.
• notifee.onForegroundEvent( .. ) within subscribe: https://reactnavigation.org/docs/navigation-container/#linkingsubscribe. This was getting tiggered when the app was in the background, but still running.

With the NotifeeExtensionHelper I was finding that both events were getting called when you tapped a notification while the app was fully closed.

This caused the following error:

The navigation state parsed from the URL contains routes not present in the root navigator. This usually means that the linking configuration doesn't match the navigation structure. See https://reactnavigation.org/docs/configuring-links for more details on how to specify a linking configuration.

I tracked this down to notifee.onForegroundEvent. I tried removing it, but I couldn't for the life of me get getInitialUrl working. It's probably some miss configuration on my end with my usage of react-navigation.

The other strange thing that started happening was my splash screen was no longer showing when I pressed on a notification while the app was killed.

I then figured I have a dev race condition with my error, the navigator isn't fully alive yet on dev when I try and pass the route. I tested a release build with these changes and it worked.

I still am debugging why my getInitialUrl isn't working, but for now NotifeeExtensionHelper seems to be working.

One other problem I am still trying to figure out is not displaying the notification when a user is viewing the screen for the notification. This worked before for my data only notifications, but I fear that I have lost this functionality. But this solves other bigger problems around reliability and notification speed that are more important to me.

Update 5:
I ended up removing isHeadless from my app. It seemed like my app wasn't booting into that mode anymore after logging it a bunch. In short, I still saw { isHeadless: true } when you press a notification from a killed app state, but the app was opened by the user, and it's not headless.

[johnbonds]

I stumbled on this thread after coming to the same exact conclusion as @christophemenager. After reading through the thread (thanks all for participating in the discussion), I decided to vet this for myself since IOS basically swallowing data-only push notifications in any scenario seems like unreasonable behavior.

I'm using @react-native-firebase/messaging to handle incoming data-only push notifications. To be clear, data-only push notifications means on IOS, content_available = 1 and on Android priority = HIGH with no notification section in either case. I'm using notifee to display all notifications after the messaging().setBackgroundMessageHandler callback provided by firebase.

I'm not seeing the behavior where IOS is swallowing data-only push notifications. Notifee is displaying the banner notification whether or not the app is in the foreground, background or killed/quit state. I'm curious to hear from others if IOS changed this behavior or if there is some other scenario that I'm not testing where IOS would swallow data-only push notifications.

[mikehardy]

I find that most of mine come through as well, however: 1) my phone is typically my dev phone at 100%, not overheating, plugged in to my laptop (oodles of power, thinks the power miser) and 2) I have background refresh turned on / not in low power mode 3) I use my test app all the time (oh, this person loves this app we'll give it generous power budget). So if that sounds at all like you, I think deliver rates may be deceptively high, and specifically for the case of us developers, so it lures you in.

All of the delivery difficulty is real though, if any of those items above is not your user's case, delivery can quickly go to zero. That's my experience as I troubleshoot with people on the issue over the last few years

[johnbonds]

@mikehardy Understood but do you see that behavior with all push notifications or just data-only?

[mikehardy]

Data-only (which you defined accurately and precisely IMHO). Include a notification block and iOS grants power budget in almost all cases, so delivery rate is reliable

[johnbonds]

@mikehardy I've been racking my brain trying to think of a way to get the best of both worlds here... I want to reliability of push notifications that include the 'notification' section but I want to intercept it before it's displayed and then run my code to pull data from my API, update my local database (realm) and THEN display the notification to the user. I can see on the IOS side there's this concept of implementing the NotifeeExtensionHelper (https://notifee.app/react-native/docs/ios/remote-notification-support) but this seems to simply hook in to notifee directly and doesn't exactly intercept the push notification so that I can run my own code. Is this an accurate understanding of this feature? Any other ideas?

[jesualdo13]

Hey guys. I tried this too and the result is the same 😢
I will see if I can hide fcm notifications in normal notifications

[quicksilverr]

@jesualdo13 Were you able to find any solutions, @mikehardy can't we have a notifeeextensionhelper for android as well?

[quicksilverr]

@mikehardy I've been racking my brain trying to think of a way to get the best of both worlds here... I want to reliability of push notifications that include the 'notification' section but I want to intercept it before it's displayed and then run my code to pull data from my API, update my local database (realm) and THEN display the notification to the user. I can see on the IOS side there's this concept of implementing the NotifeeExtensionHelper (https://notifee.app/react-native/docs/ios/remote-notification-support) but this seems to simply hook in to notifee directly and doesn't exactly intercept the push notification so that I can run my own code. Is this an accurate understanding of this feature? Any other ideas?

@johnbonds I completely agree with you, If we have some kind of an ability to run certain operations, before we can send it to the background message handler, that would be a great way...

[mikehardy]

We can have anything! We merge + release all reasonable PRs

[quicksilverr]

We can have anything! We merge + release all reasonable PRs

Sure :) , but please could you give me some guidance, where I can start from, for this approach.
If we have some kind of an ability to run certain operations, before we can send it to the background message handler, that would be a great way.

[quicksilverr]

Hey, after changing to data only notifications in android, the on press event on notifications is not working.

Is there something, I might be missing to add in the display notification object?

[helenaford]

@quicksilverr would you be able to make this a separate ticket regarding data-only notifications on Android? Finding this thread hard to follow at the moment so the simpler and more specific we can make each ticket, the better.

[helenaford]

From the author's original post, it seems what you could do, without any additional library changes, is the following:

• data-only on Android so you can use quick actions e.t.c. There's no other way around this. I've personally tried to start a discussion with the Google team over on the Firebase Android SDK repo about the limited API around firebase messaging and firebase-admin.
• on iOS, don't need anything special, we handle response events even if the notification was displayed automatically via APNs. You only need the notification extension if you want to use images or conversation-style messaging. For quick actions, just need to set the category in the remote notification payload.

var payload = {
  android: {
    priority: 'high',
  },
  data: {
    'title': 'Notification Title for Android via data-only notification'
  },
  apns: {
    payload: {
      aps: {
        alert: {
          title: 'Notification Title for iOS',
          body,
          subtitle,
        },
        sound: 'default',
        category: 'quick-action-category',
        mutableContent: 1,
        contentAvailable: 1,
      },
    },
  },
}

If this is helpful, I will add it to the docs. Also I've pinned this issue until it's closed

[quicksilverr]

@quicksilverr would you be able to make this a separate ticket regarding data-only notifications on Android? Finding this thread hard to follow at the moment so the simpler and more specific we can make each ticket, the better.

Hey Helena, sure will do.

Here's the link to the created issue

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[helenaford]

I've put together a short guide about how to setup notifee and RNFB here.

[Commaando]

@helenaford so what should i do if i want to make an ongoing notification in android . As per my understanding , from your guide , i need to add a RNFB setBackgroundMessageHandler listner and use Notifee.displayNotification method in the listner for that . is that correct ?

[Commaando]

{
"to" :"",
"android": {
"priority": "high"
},
"data": {
"title": "Notification Title for Android via data-only notification"
},
}

I sent this payload from backend.
in index.js i handled it as:

messaging().setBackgroundMessageHandler(async remoteMessage => {
console.log('Message handled in the background!', remoteMessage);
await Notifee.displayNotification({
title: remoteMessage.data.title
})
})

I can see the consoles but cannot see the notification on the devices.

[Commaando]

any suggestions what i am doing wrong here.

[Darren120]

• getInitialNotification

where u able to get deeplinking working? i also cant get initital url

[bensaine]

on iOS, don't need anything special, we handle response events even if the notification was displayed automatically via APNs. You only need the notification extension if you want to use images or conversation-style messaging. For quick actions, just need to set the category in the remote notification payload.

@helenaford

Does this mean that interruptionLevel: "timeSensitive" can be achieved without the notification extension? (which is how I am currently doing things).

Thanks

[fukemy]

Initially, I bought a notifee licence in order to display notifications while app is in foreground state, in order to "patch" a missing feature of default fcm

wait! Where notifee license? Does it's require cost to unlock all feature?

[mikehardy]

@fukemy no - it used to require a license a long long time ago, to fund initial development since the Notification API surface area on both platforms is so large and it was a lot of development. It was then open-sourced completely a year or two back.

No license is required now

[abdulragib]

{ "to" :"", "android": { "priority": "high" }, "data": { "title": "Notification Title for Android via data-only notification" }, }

I sent this payload from backend. in index.js i handled it as:

messaging().setBackgroundMessageHandler(async remoteMessage => { console.log('Message handled in the background!', remoteMessage); await Notifee.displayNotification({ title: remoteMessage.data.title }) })

I can see the consoles but cannot see the notification on the devices.

same issue