🔥 [🐛] [IOS] onMessage callback is not called when push notification was sent via pinpoint

Issue

👋 In our project we are using RNFB v5 and we are migrating to v6 however when we receive push notification on IOS we would expect that onMessage is called. This is not happening when application is in foreground.

It seems that RNFB/messaging does not handle push notifications at all if they were not send via gcm / firebase? I see a lot of weird conditions if ("gcm.message_id")
We are sending push notifications to our devices via pinpoint which does not have gcm.message_id in payload and therefor this condition always fails...

Example of such condition:

react-native-firebase/packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m

Line 132 in 514e6bd

if (userInfo[@"gcm.message_id"]) {

If I remove this condition, then callback is called in our application. This seems like a bug to me as it was kind of working in v5 but it is not working in v6.

Here is also how the "userInfo" for received notification looks like for us:

{
    aps =     {
        alert =         {
            body = "Date with time: 1";
            title = "Title2 with datetime";
        };
        "content-available" = 1;
        "mutable-content" = 0;
        sound = "custom.wav";
    };
    data =     {
        jsonBody =         {
            customerId = 1;
            messageCode = "test_notification";
            notificationId = "c964ebb8-85a9-42b7-9be5-00a90ea4cb6b";
        };
    };
}

---

Project Files

Javascript

Click To Expand

package.json:

"@react-native-firebase/app": "13.0.1",
"@react-native-firebase/messaging": "13.0.1",

firebase.json for react-native-firebase v6:

# N/A

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

info Fetching system and libraries information...
System:
    OS: macOS 12.0.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 243.30 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.15 - /usr/local/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
    Watchman: Not Found
  Managers:
    CocoaPods: 1.11.2 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
    Android SDK:
      API Levels: 23, 26, 27, 28, 29, 30, 31
      Build Tools: 28.0.3, 29.0.0, 29.0.2, 29.0.3, 30.0.2, 30.0.3, 32.0.0
      System Images: android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom, android-29 | Google Play Intel x86 Atom, android-30 | Google APIs Intel x86 Atom, android-31 | Google APIs Intel x86 Atom_64
      Android NDK: Not Found
  IDEs:
    Android Studio: 2020.3 AI-203.7717.56.2031.7583922
    Xcode: 12.4/12D4e - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_275 - /Users/dusan.plavak/.sdkman/candidates/java/current/bin/javac
    Python: 2.7.18 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: 6.1.0 => 6.1.0
    react: 17.0.2 => 17.0.2
    react-native: 0.65.1 => 0.65.1
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  • 13.0.1
• Firebase module(s) you're using that has the issue:
  • messaging
• Are you using TypeScript?
  • Y & 4.4.2

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[mikehardy]

You may want to integrate notifee - in general react-native-firebase is in the business of handling FCM and leaves other notifications alone, yes.
Notifee is working through an extension to process all notifications for an app. Originally notifee was also restricting it self to "noticing" (that is, posting events for) only notifications it posted itself, but I think it posts events for all notifications now?

https://notifee.app/react-native/docs/events#foreground-events

Well that added notifee on already however it is not working for us.

My thinking was -> when we receive onMessage callback when app is in foreground, use notifee to show local notification. That is also in "integration guide" for RNFB library:

I will test the events again.

[mikehardy]

This is the point where I think everything is just guesses. Nothing beats an App.js you can drop in runnable app.
https://stackoverflow.com/help/minimal-reproducible-example

No promises though - I may not have time to look at it for a while, typically the clean App.js results in clean thinking though and the problem + solutions become more obvious

https://github.com/mikehardy/rnfbdemo/blob/master/notifee-demo.sh
https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh

to generate skeletons

[chrisrollins]

We are having a similar issue after upgrading from version 5 to version 6. Data-only PNs on iOS do not trigger the OnMessage callback while app is in the foreground. In the background it doesn't work either but we're not worrying about that.

Visible PNs work and we can see the callback trigger.

On version 5 it was working. We can still see it working in the older build of our app on the same phone. So we don't think it has anything to do with iOS system or APN requirements.

[mikehardy]

Unfortunately from 5 to version 13 (version 6 was quite a while ago) also includes an incredible amount of version difference, across several breaking changes, in the underying firebase-android-sdk and firebase-ios-sdk, and you may have changed other things at the same time as upgrading react-native-firebase so it does not do much for us, from an information perspective. Still could be anything anywhere.

[chrisrollins]

Sorry, the documentation just calls it v6.x

https://rnfirebase.io/migrating-to-v6

But yes I am aware the entire thing might as well be rebuilt from scratch at this point. I looked at the source code of both versions. I noticed that in v5.x the library implemented didRecieveRemoteNotification and now it does not.

I exhaustively went through everything I could find to troubleshoot this but the fact is that the new library doesn't receive data-only PNs on iOS while the old library does. Do data-only PNs actually work for anybody out there?

[mikehardy]

Yes...but ... you have to have the app "well loved" by the power miser algorithm in iOS, and the device needs to have a lot of power to feed as "power budget" to the internal / blackbox power miser algorithm.
If the battery is 100% and you're on power (cable plugged in), and you've used the app recently, and it's not force quit, and power saving isn't on, and background refresh isn't disabled, that's about as solid as a case as you can get for it to work.

It works for me all the time like this, plus in less friendly circumstances when I use my test apps a lot.

If you watch the device logs you may find evidence that it was delivered or not

packages/messaging/ios/RNFBMessaging/RNFBMessaging+NSNotificationCenter.m:      // application:didReceiveRemoteNotification:fetchCompletionHandler: will not get called unless
packages/messaging/ios/RNFBMessaging/RNFBMessaging+UNUserNotificationCenter.m:    // Don't send an event if contentAvailable is true - application:didReceiveRemoteNotification
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:    SEL didReceiveRemoteNotificationWithCompletionSEL =
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:        NSSelectorFromString(@"application:didReceiveRemoteNotification:fetchCompletionHandler:");
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:            respondsToSelector:didReceiveRemoteNotificationWithCompletionSEL]) {
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:      // application:didReceiveRemoteNotification:fetchCompletionHandler:
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:                                                   didReceiveRemoteNotificationWithCompletionSEL);
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:                      didReceiveRemoteNotificationWithCompletionSEL,
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:    didReceiveRemoteNotification:(NSDictionary *)userInfo
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:    DLog(@"didReceiveRemoteNotification Firebase Auth handeled the notification");
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:    DLog(@"didReceiveRemoteNotification gcm.message_id was present %@", userInfo);
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:        DLog(@"didReceiveRemoteNotification sharedInstance.backgroundMessageHandlerSet = %@",
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:          DLog(@"didReceiveRemoteNotification without waiting for backgroundMessageHandlerSet to "
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:                DLog(@"didReceiveRemoteNotification waiting for "
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:                  ELog(@"didReceiveRemoteNotification timed out waiting for "
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:              DLog(@"didReceiveRemoteNotification after waiting for backgroundMessageHandlerSet");
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m:      DLog(@"didReceiveRemoteNotification while app was in foreground");
packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.h:    didReceiveRemoteNotification:(NSDictionary *)userInfo

[mikehardy]

we found that if the device was too hot even, it would just silently fail (well, it would drop a message visible in console.app) a data-only FCM. My take on it: you want reliable delivery? notifications are it

That's a huge source of the effort involved in notifee.app in fact - to hook into the notification delivery pathway on ios so you have reliable delivery (notification block in your FCM JSON) but you have control (your code executes before notification presentation). Check the docs there specifically for the extension helper. It's really no fun unfortunately

[chrisrollins]

So you can confirm that data-only notifications do work for you on iOS? Can you show me some example payloads that work for you?

[mikehardy]

Nothing that fancy I think? Ignore the question-y comments, this code actually runs in production as a pub-sub scheduled firebase function, thus with access to the firebase nod admin SDK, that's the API in use here.

        const recipientFcmTokens: string[] = [];
        Object.keys(recipientTokenMap).forEach((key) => {
          recipientFcmTokens.push(recipientTokenMap[`${key}`]);
        });

        console.log('Sending to recipient tokens:', JSON.stringify(recipientFcmTokens));

        // Build up the data payload - it's restricted to string/string so we map options
        // into an 'optionName': value set of keys, and those are unmapped by clients.
        const data: { [key: string]: string } = {
          jobType: 'DeviceEventCheck',
          // sender: req.body.data.senderKullkiId,
        };
        const payload = {
          data,
        };
        // if (req.body.data.options) {
        //   // console.log(
        //   //   'Message contains options: ' + JSON.stringify(req.body.data.options, null, 2)
        //   // );
        //   Object.keys(req.body.data.options).forEach((optionKey) => {
        //     // console.log('key ' + optionKey + ' has ' + req.body.data.options[optionKey]);
        //     payload.data['option' + optionKey] = req.body.data.options[optionKey];
        //   });
        // }
        console.log('Payload is now: ' + JSON.stringify(payload, null, 2));

        // Set up our options
        const options: MessagingOptions = {
          contentAvailable: true,
          // fcm_options: {
          //   analytics_label: 'FCMData' + fcmType,
          // },
        };

        options.priority = 'high'; // is that correct?

        // If it is a device check, allow collapse etc
        // if (fcmType === 'DeviceEventCheck') {
        //   message.android.collapse_key = 'DeviceEventCheck';
        // }

        const failedTokens: string[] = [];
        for (const recipientFcmToken of recipientFcmTokens) {
          const response = await getMessaging(getAdminApp()).sendToDevice(
            recipientFcmToken,
            payload,
            options
          );
          if (response.failureCount > 0) {
            console.log(
              'Failure with token ' + recipientFcmToken + ' - ' + JSON.stringify(response)
            );
            failedTokens.push(recipientFcmToken);
          }
          if (response.successCount > 0) {
            console.log('Success with token ' + recipientFcmToken);
            success = true;
          }

[chrisrollins]

Did you find that the options field is necessary?

[mikehardy]

Absolutely vital per docs. If you don't say content available, you might as well just send it to /dev/null. If you don't set priority high, I don't think it will work for you. This is all documented? https://rnfirebase.io/messaging/usage#data-only-messages

[chrisrollins]

K I'll try it.

Interestingly it does work on the old version of the library without those. I also tried adding some logs to the library to see if it was stopping somewhere, but it seemed like it didn't show up at all.

I'd want to believe you if you told me iOS system requires those fields but that doesn't explain why it worked before we updated the library.