Decrypt notification payload before displaying using setBackgroundMessageHandler iOS

[mfbx9da4]

I am trying to get setBackgroundMessageHandler to fire on an iOS device. My end goal is to decrypt the message payload and display a custom notification with the decrypted data. Is this possible with setBackgroundMessageHandler or do I need to implement a notification service extension?

I have done the following

• I have read https://rnfirebase.io/messaging/usage
• I have read [🐛] setBackgroundMessageHandler not working on ios #4705 and SetBackgroundHandler not working on ios. #3530
• I have checked I have the right capabilities enabled
• I have ensured device has granted push notification permissions
• The messaging.onMessage handler fires and displays a custom notification when in the foreground
• When in the background the notification displays the encrypted data but the setBackgroundMessageHandler never logs anything and my custom notification never displays
• I have implemented the headless check as specified in the documentation (though not sure how to verify it is correct)
• I have ensured the setBackgroundMessageHandler is the fourth line of the index.js file after the necessary imports
• I have ensured the device has full battery and is not on silent or do not disturb

My situation seems very similar to this comment

Based on the following table and this documentation snippet

When the application is in a background or quit state, the onMessage handler will not be called when receiving messages. Instead, you need to setup a background callback handler via the setBackgroundMessageHandler method.

Based on the above, If I send an FCM message with a notification+data it should trigger the setBackgroundMessageHandler and I should be able to decrypt the message and display a custom notification? (ie something like this messaging().send({ notification: { title: 'foo' }, data: { bar: 'bar' }, token }) I shouldn't need to tweak content-available or remove the notification key or anything else of the sort?

However, I am confused by these comments #4705 (comment) #4705 (comment) from @mikehardy

It's my understanding that as soon you include a notification block in your payload you get nothing until the user interacts with the notifcation, at which point you get onMessage with data payload included, because at that point you are not in background, you've been brought to foreground.

you will not get a background message handler called ever if you send a notification block. You'll get either a notification open, or an onmessage with data in there, but it's never background if a user tapped on your notification so that hook does not apply

Also this comment #3530 (comment) suggests that the payload must be data-only, with contentAvailable: true and 'apns-push-type': 'background'. I've tried this too, but in this case neither logs are produced nor a notification displayed. From some other comments I've gleamed that data-only payloads are pretty unreliable so not sure data-only even works for my use case.

So is the current documentation just wrong?

Data-only payloads in apple's terminology are background notifications, is the setBackgroundMessageHandler really just a handler for data-only messages?

Either way I've never managed to get the background message handler to fire.

So to re-iterate my question, will it be possible to intercept the message when in background or quit, decrypt the message and display a custom notification using setBackgroundMessageHandler or will I have to do this using a notification service extension?

[mikehardy]

I think you are going to want Notification Extension yes, you might like https://notifee.app and the docs there

Without a notification extension:
if you do mixed payload, what you get is an SDK-provided notification and then when user clicks data is available
If you do data-only payload, your delivery will not be guaranteed and it will lead to disappointment I think
If you do notification-only, you get a SDK-provided notification

With a notification extension:
you don't have to do data-only, so delivery is better
so you may include a notification payload now, but you get to run code to modify the notification before it's presented

[mfbx9da4]

Thanks for your prompt response!

So

• Without a notification extension there is no way to modify the notification before it is displayed (if you are in background or quit mode)
• setBackgroundMessageHandler is purely for data-only messages on iOS?

Are those two statements correct?

[mikehardy]

I'm quite confident the first statement is correct, like 99%, just allowing 1% for something changing or something really surprising I'm unaware of

I'm about 98% sure on the second statement - which is just allowing for a little more surprise with the combination of iOS and handlers and app states

It seems like this stuff should be easy and then it just seems to always change behavior with new versions of the mobile operating systems, that's the only reason I'm giving you those tiny hedges.

My best advice is to actually keep some test code in place that lets you verify yourself directly (now, and in the future). I have a bash script I can past a device token into, and it sends notification, mixed, and data-only FCMs to the token, and in my client I have all available handlers set up (for react-native-firebase and for notifee), that log debug messages on debug builds. And I can just inspect behavior when needed / as things evolve. Bash script to post to FCM REST API is pretty easy since the JSON is simple, and the handlers are pretty simple, so it's worthwhile in my opinion.