FirebaseMessaging.onBackgroundMessage() not working for ios

[m2sahin]

Discussed in #9380

^{Originally posted by m2sahin August 19, 2022}
HI,
I want to use FirebaseMessaging for notifications in my Flutter project. I have completed the installation for both Android and IOS. Everything works perfectly except one thing.

I want to do; I want to evaluate the incoming notification according to the data it contains and decide whether to show the notification or not. I also want to display notifications using flutter_local_notifications package.

I can do all this for android. For iOS, it works fine when the application is running and covered, but the FirebaseMessaging.onBackgroundMessage function is not triggered when the application is terminated.

I've been grappling with this issue for days, there's no advice I haven't tried. Please help me, at least tell me if this is possible. As a result of my research, I realized that there are many people struggling with the same problem and none of them have found a solution. The strange thing is that this issue is never mentioned in firebase and flutter.

This is very frustrating, please I need help.

[darshankawar]

@m2sahin
This seems to be same / similar to #6290 which has been fixed as part of this PR : #9292, wherein, the plugin example has been updated with instructions on how to test / verify the onBackgroundMessage handler.

I have done that already and based on my tests I shared here for your reference:

#9300 (comment)
#9300 (comment)

I have asked the team on when will the PR fix will be available in new version of the plugin, but mean time, can you use this PR branch:#9292, and follow these instructions:https://github.com/firebase/flutterfire/pull/9292/files#diff-9b3d71b5695d165617b4e5d3abe958a2991aa582c065aa3ff463e47a436a1d4dR21-R29 and see at your end, whether your use case works using it ?

[darshankawar]

Update: I got to know from the team that the fix made as part of #9292 is an update to plugin's example app, so there's nothing to release on pub.dev for it.

You can checkout the plugin example: https://github.com/firebase/flutterfire/tree/master/packages/firebase_messaging/firebase_messaging/example and try it out on iOS and confirm at your end. As mentioned earlier above, I have done the same and it worked properly.

[Kiruel]

I got the same behaviour of @m2sahin. On firebase_messaging: ^12.0.3 he never pass to the onBackgroundMessage on iOS, it's just the default push notification from iOS. So we can't create a custom notification via flutter_local_notifications.

It works fine on android.

On flutter 3.3.0-0.4.pre.

And I was following the current example.

[m2sahin]

I have searched a lot, there is no solution for this. Unfortunately, I was disappointed. 🙁 @Kiruel

[darshankawar]

Keeping this issue open and labeling for further insights from the team based on #9381 (comment)

/cc @russellwheatley

[Kiruel]

After investigating a lot, I find something interesting.

To be able to received a notification the payload should contains gcm.message_id. So if you use a different payload (third party like sendbird in my case). You can't pass this line so the onBackgroundMessage is never call.

And I try to fork and change this line. I never received the notification. It's because to handle it properly, the payload need to add mutable-content:1 in the JSON payload. More info in the Apple Documentation.

Then you need to add a custom service to handle the notification and change the contain if needed (modifying_content_in_newly_delivered_notifications).

Of course if firebase_messaging could handle this for us (via onBackgroundMessage) and be able to change the contain of the notification directly in Dart/Flutter via flutter_local_notification or other package it could be good.

I'm still programming this part on my application, but if I find something else to share I will not hesitate.

[iosephmagno]

@darshankawar the #9300 already explains the issue and how to solve it.
#9300 (comment)

Documentation from Apple is clear:
https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications

On iOS, we must use “notification” + mutable-content:1 + service app extention to modify content before displaying head up. We cannot use “silent notifications” because on iOS they are not triggered IF (app is terminated && app is not the last one opened). Also, on many occassions, silent notifications can be delivered with delay or not delivered at all.

Until this fix is done, firebase messaging is not usable on iOS if notifications must be modified before displaying head up. So it would be much appreciated if you guys could assign this a p1 and provide us a deadline.

[Kiruel]

@m2sahin Maybe you can check how I fix it for release mode, it's related to flavor files, check this issue https://github.com/sendbird/sendbird-sdk-flutter/issues/48, but still like @iosephmagno said we can not use background messaging on iOS to change the notification. Unless you have the control of the payload.

[meet7-sagar23]

Facing the same issue.

[elenaconache]

Having the same problem. Is there any update? Will this be implemented? Right now we must use the notification text from back-end, which is a problem as we can't adjust to each user's preferred language. We also need to perform some operations on the data, like storing some missing info or at least knowing some data has to be re-fetched from back-end.
Please prioritize this feature, it would be very appreciated, I'm sure there are many apps which need to show custom notifications/ handle payload when app is terminated on iOS.

[hatemragab]

Same problem!!

[delfme]

As mentioned by @iosephmagno and @Kiruel 's comments, FirebaseMessaging plugin still doesn't fully cover iOS.

If remote notification's content must be modified before displaying head-up, "mutable-content:1" and iOS service app extension are required. https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/generating_a_remote_notification

Remote notifications are the only type of notifications which guarantee to be always delivered by Apple APN and get always triggered on device, whatever the app's state. On iOS, data-only notifications cannot be used for the reasons explained in above comments: (1) they might not be sent by Apple APN under certain traffic, and (2) they are not displayed under certain device usage condition or when a different app is moved to foreground after user terminates our app.

[hatemragab]

i have good news it works in the native side there are bug with firebase_messageing package
#9563

[russellwheatley]

Hello everyone, we’ve reviewed the issues opened for iOS background messages and we want to make our position clear.

Android and iOS handle background messaging differently. The decision made by the iOS operating system whether messages reaches the relevant iOS event handler (and subsequently received by the Dart background messaging handler) is based on a number of criteria, such as: CPU usage, priority level (data-only messages are considered “low priority” by iOS, android does not), battery level, amount of messages being received by the app, background/terminated application state, etc. This is a fundamental difference between the platforms, and you need to be aware of them when designing your application.

One solution suggested for iOS data-only messages unreliability has been to add a NotificationExtension. But this will still not create parity with Android as you will still have to include a notification with your message (therefore not data-only). It will still render the original notification if you do not update/mutate the notification that comes through the system in a timely manner. We are not currently considering this as a solution due to these limitations.

We also will not support non-FCM messages from third party packages. We specifically only support messages received from the Firebase APIs since we cannot guarantee that messages received from third party packages will not have any unintended side-effects on other Firebase products such as messaging delivery reporting and Analytics data.

To help us triage and locate genuine issues that need to be addressed we have created a specific issue template for iOS background messages. If you believe you still have an issue that needs to be addressed, please create a new issue following this template.

I will be closing this issue in favor of raising a new issue with the new template above. This template will help you provide us with all the information we need to investigate a potential issue with background messaging on iOS.