[🐛] setBackgroundMessageHandler does not work on IOS > 17 and react native 72.2

[alexstock1]

Hi all,
after the update to react 0.72.2 and react native firebase 18.5.0,
(I have made everything that was written in the instructions and checked everything a couple of times, and i use use_frameworks! :linkage => :static) setBackgroundMessageHandler does not work on IOS > 17 at all when the app is minimized (Background mode), on Android everything works as expected

below you can find the requested body

{
  "to": "",
  "content_available": true,
  "priority": "high",
  "notification": {
    "body": "Test body",
    "title": "Test title",
    "sound": "default"
  },
  "data": {
    "type": "chat_message",
    "sound": "default"
  }
}

[aliyilmazdev]

Hi, could you solve the problem? @alexstock1

[mikehardy]

If you include a notification block and a data block it is considered a "mixed" content message

the message will not trigger a background handler ever as it will instead (at the deeper firebase-ios-sdk layer) trigger a user-visible notification (but not start your app! no handlers called!).

If the user interacts with the message it will open your app and trigger onNotificationOpened with message contents that include the data block

I believe our documentation here may not be accurate and it conflicts slightly with upstream 🤔 - it would require some testing to see. The difficulty with testing is that there are a lot of conditions to meet in order for the test to be accurate

• setBackgroundHandler needs to be passed an async function that does no UI updates and returns a Promise
• the JSON needs to be perfect with priorities etc
• the device needs to have background refresh enabled and otherwise deliver the message - verified by watching device logs while plugged into developer machine via Xcode console on running app or Console.log

Upstream docs state this, which makes me think the behavior you observe is by design:

https://firebase.google.com/docs/cloud-messaging/concept-options#notification-messages-with-optional-data-payload

When in the background, apps receive the notification payload in the notification tray, and only handle the data payload when the user taps on the notification.

[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.

[dhaivatkhanpara]

I am also facing this issue.

[rawatnaresh]

setBackgroundMessageHandler does work if the payload you sent is correct. I was facing the same issue but got it working with following payload

Generating Remote notification Apple Docs

{
  "message": {
    "topic": "my-tpoic", // or token
    // Shouldn't contain notification block, as it is data only message
    "data": {
      "title": "Background notification 1",
      "body": "Background Notification 1",
    },
    "android": {
      "priority": "high"
    },
    "apns": {
      "headers": {
       // apns-priority should be 5 when apns-push-type is background
        "apns-priority": "5", 
        "apns-push-type": "background"
      },


      "payload": {
        // To send a background notification, create a remote notification with an aps dictionary that includes only the content-available key
        "aps": {
          // The background notification flag
          "content-available":1
        }
      }
    }
  }
}

You can test this using Rest API or Google OAuth Playground

If you would like to test this using OAuth Playground then

• Authorize https://www.googleapis.com/auth/firebase.messaging API
• Exchange auth code for token
• Select method POST and set request URL to https://fcm.googleapis.com/v1/projects/{PROJECT_NAME}/messages:send
• And paste this as request body

{
  "message": {
    "topic": "topic-name-or-token",
    "data": {
      "title": "Background notification 1",
      "body": "Background Notification 1",
    },
    "android": {
      "priority": "high"
    },
    "apns": {
      "headers": {
        "apns-priority": "5",
        "apns-push-type": "background"
      },
      "payload": {
        "aps": {
          "content-available":1
        }
      }
    }
  }
}

As this is a background message and won't show any notification alert. If you would like to show an alert you can use notifee

messaging().setBackgroundMessageHandler(async remoteMessage => {
  // Update local storage
  // And Display notification if necessary
  return notifee.displayNotification({
    title: remoteMessage.data.title,
    body: remoteMessage.data.body,
    data: remoteMessage.data,
    android: {
      channelId: 'channel_id',
      smallIcon: 'ic_notification',
      color: '#000060',
    },
  });
});

Hello @mikehardy, Do you think this is the correct way to show notification alert for background notifications?

In my app I have a requirement to show notification count and notification alert. Adding a notification block in FCM displays an alert but I cannot update local storage and sending data-only message updates the local storage but no notification alert unless I display an alert using notifee.

Also, I don't think its reliable to depend on setBackgroundMessageHandler to trigger alert as we cannot predict its execution. Eg. Sometimes it delays the execution until the app is open.

I was thinking of sending two different notification to solve this issue.

• Notification with data only block to trigger local update
• and another notification with notification block to show alert.

But sending two different notification for a single thing doesn't sound good either. Please let me know your thoughts.

[mikehardy]

@rawatnaresh I think this is a fine way to go about it for android only, on iOS the delivery of data-only messages is unreliable and you must not count on it for your features. I would use this for your android device tokens or topics android is subscribed too

For iOS you want to send a notification block as it is the only way to guarantee delivery. You will need to use a notification extension helper if you want side-effects besides just showing the notification and you'll need to be very careful to have rapid execution so you fit in the small execution timeslice iOS will give you on the way to posting the user-visible notification

[rawatnaresh]

Thanks for the suggestion. I'll look into Notification Extension helper

[DeepakSharma04]

Hi, Can anyone help me to solve this issue #7715

[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.

[dukizwe]

Hey @alexstock1 did you manage to fix this ? My payload is look like yours but setBackgroundMessageHandler is still not fired. When i send the notification from the server while the app is in background, the notification is arrived but i can't see it until i open the app. Any help @mikehardy ?

[Gagan-Deogan]

@alexstock1 @mikehardy , Iam facing the same issue please look into this

[dedm-github]

Why my notification only play in foreground but play default notification sound in background ?

if (isGmsProvider(provider)) {
module.messaging().setBackgroundMessageHandler(async (remoteMessage) => {
await AsyncStorage.setItem('lastRemoteMessage', JSON.stringify(remoteMessage));

  promptPushNotification({
    title: remoteMessage.notification.title,
    body: remoteMessage.notification.body,
    data: remoteMessage.data,
  });
  await module.messaging().getInitialNotification();
});
module.messaging().onMessage(async (remoteMessage) => {
  promptPushNotification({
    title: remoteMessage.notification.title,
    body: remoteMessage.notification.body,
    data: remoteMessage.data,
  });
  // CLear the initial notification
  await module.messaging().getInitialNotification();
});

}

[otech47]

If you include a notification block and a data block it is considered a "mixed" content message

the message will not trigger a background handler ever as it will instead (at the deeper firebase-ios-sdk layer) trigger a user-visible notification (but not start your app! no handlers called!).

If the user interacts with the message it will open your app and trigger onNotificationOpened with message contents that include the data block

I believe our documentation here may not be accurate and it conflicts slightly with upstream 🤔 - it would require some testing to see. The difficulty with testing is that there are a lot of conditions to meet in order for the test to be accurate

• setBackgroundHandler needs to be passed an async function that does no UI updates and returns a Promise
• the JSON needs to be perfect with priorities etc
• the device needs to have background refresh enabled and otherwise deliver the message - verified by watching device logs while plugged into developer machine via Xcode console on running app or Console.log

Upstream docs state this, which makes me think the behavior you observe is by design:

https://firebase.google.com/docs/cloud-messaging/concept-options#notification-messages-with-optional-data-payload

When in the background, apps receive the notification payload in the notification tray, and only handle the data payload when the user taps on the notification.

@mikehardy do you know why this would be happening?

#7988 (comment)

thanks for your time