location-based notification and iOS data-only reliability

[Gesma94]

Hi all.

Let me first start from what I need based on the application we are building; when some events happen, we are sending two different types of notifications:

• A "normal" one, where we send to user Pippo the notification and its device should always display it
• A "roaming" one, where we send to user Pluto the notification, but the device should display it only if the user current location is withing a certain range from the event.

Based on the requirements, we are using data-only notification because sometimes, even if we send something to the device, it does not mean we are going to display it. Therefore, if I would send a notification message, I have no idea how to perform the roaming ones.

Speaking about what we are using, we have:

• firebase-admin/messaging on the backend
• a non-EXPO React Native app which uses notifee

Now, let's (partially) see what we have from a code point of view. On the backend, we have this:

const batchCallResult = await messaging.sendEachForMulticast({
          tokens,
          data: map(String, data),
          android: {
            priority: "high",
          },
          apns: {
            headers: {
              "apns-push-type": "background",
              "apns-priority": "5",
              "apns-topic": "***", // omitted, but we have the actual one here
            },
            payload: {
              aps: {
                contentAvailable: true,
                badge: 0,
              },
            },
          },
        });

As you can see, we are sending data-only, and the reasons why the apns and android are set are so is defined here: https://rnfirebase.io/messaging/usage#data-only-messages

From what concern the RN side, we have these part of code in the app:

// in index.js file
setupBackgroundMessageHandler();

// in another file
export const setupBackgroundMessageHandler = () => {
	messagingInstance.setBackgroundMessageHandler(notificationBuilder);
};

// in a custom hook
const useCloudMessaging = () => {
	useEffect(() => messagingInstance.onMessage(notificationBuilderForeground), []);
        ...
}

Then, in both notificationBuilder and notificaitonBuilderForeground we have the logic where we check:

• If the notification is a normal one, we display it (in custom ways, like different icons, colors, .. based on other properties)
• If the notification is a roaming one, we make the needed checks and then in case it's needed, we display it

Now, the real question is: how reliable this implementation is?

I'm using data-only notification, and I've read on this repo itself that they're not that reliable:

• 8f42976#commitcomment-134432236
• iOS Data Only FCM messages not reaching device #7770 (comment)

We have made so that users know they must:

• Not being in power save mode
• Have the background app refresh enabled on iOS
• Have the notification enabled

One last thing to add is what problem we were facing: from time to time, notifications were NOT delivered, unless user opened the app: at that point, he got all the notification he didn't get from the last app opening.

Finally, we just changed the backend to use apns-push-type: background and apns-priority: 5 based on Firebase documentation, but from Apple documentation itself it appears we should use what we had before (apns-push-type: alert and priority: 5).

alert
The push type for notifications that trigger a user interaction—for example, an alert, badge, or sound. If you set this push type, the apns-topic header field must use your app’s bundle ID as the topic. For more information, refer to Generating a remote notification.

If the notification requires immediate action from the user, set notification priority to 10; otherwise use 5.

You’re required to use the alert push type on watchOS 6 and later. It’s recommended on macOS, iOS, tvOS, and iPadOS.

background
The push type for notifications that deliver content in the background, and don’t trigger any user interactions. If you set this push type, the apns-topic header field must use your app’s bundle ID as the topic. Always use priority 5. Using priority 10 is an error. For more information, refer to Pushing background updates to your App.

You’re required to use the background push type on watchOS 6 and later. It’s recommended on macOS, iOS, tvOS, and iPadOS.

As said, what we had before was having the issue I described, while it seems that right now, with latest change, the problem is gone. But, I'd like to know how much reliable this is, because notification in-time are the main part of the app we are developing (we can accept a 10/15sec delay for throttling, but not more)

[mikehardy]

data-only notifications are designed to be unreliable - we refer to them as "data only notifications" but note that in apple docs they are co-mingled with the idea of "content refresh". That is "hey, there is maybe some content for the app that you could refresh in the background - like some new news headlines - and the user experience will be slightly better if you pre-fetch vs if you have to fetch when you open the app"

That's the level of reliability intended for background / no-visible-notification push notifications on iOS. It is how they designed it.

In that context, does it make sense to design a system where "notification in-time are the main part of the app" using a transmission mechanism where the delivery contract is "we may deliver this or not, with no guarantees, and a design philosophy where non-delivery is inherent in the design" ?

I would not

You may want to look in to notification service extensions so that you can display things differently while still using the delivery contracts you want, which are only available with visible (not data-only) notifications on iOS

This is an iOS design philosophy issue, not a react-native-firebase or notifee thing, unfortunately. We can only work with what the platform provides

[Gesma94]

Thank you very much.
You're indeed right that using data-only mechanism is not the one we should use, but thanks for have clarified this: between RN, Firebase, Notifee and iOS docs things are getting complicated, to be honest. From firebase doc itself, I didn't quite get that data-only messages were that unreliable.

Anyways, at this point I'm gonna test how to make things work using notification property, but this raises a couple of more questions related to differences between iOS/Android and Foreground/Background.

About iOS:

1. As far as I understood, notification messages are handled only when app is in background, not foreground. But, from this part of RN Firebase documentation, it seems that the onMessage callback is called. Would this be 100% reliable?

2. In this part of React Native Firebase documentation, it's mentioned setBackgroundMessageHandler. Right in that paragraph it's written that:

   If the RemoteMessage payload contains a notification property when sent to the setBackgroundMessageHandler handler, the device will have displayed a notification to the user.

   I suppose than that setBackgroundMessageHandler is used to perform side effect only, like calling an endpoint to save into database that a notification has been delivered, while the notification itself should be handled by the device itself, and customize its behavior using the notification service extensions you mentioned.
   I found something about the notification service extension you mentioned even in Notifee documentation, but that's related to iOS only

About Android:

1. Suppose I add notification property on my backend, I guess Android will start to show the notification when the app is in background, but also in this case I'd like to have the chance to edit the behavior like I would do on iOS with the notification service extension.

Eventually, in order to rely no notification delivery and being showed, I'm thinking that I could:

• Send the message from backend with notification only

  • on iOS:

    • using messaging().onMessage(async remoteMessage => ...) to display via Notifee a notification when app is in foreground, and calling my backend endpoint to say "user X has received the notification"
    • rely on the notification service extension to display a notification when app is in background/killed
    • using setBackgroundMessageHandler when app is in background to call my backend and say "user X has received the notification"

  • on Android:

    • using messaging().onMessage(async remoteMessage => ...) to display via Notifee a notification when app is in foreground, and calling my backend endpoint to say "user X has received the notification" (based on the table here, neither Android will display the notification when the app is in Foreground)
    • using setBackgroundMessageHandler when app is in background to call my backend and say "user X has received the notification"

What's missing here is exactly how to display with custom behavior a notification on Android when the app is in Background/killed. I could do that in setBackgroundMessageHandler via Notifee, but being the message with notification, it would probably means display two notifications.

By the way, what I just wrote might be completely garbage, apologize if that's the case 😭