React Native: in-app messages when app is in background

user_915816 0
Viewed 1585

I've been researching different options for implementing messaging, specifically sending a message from the server to the client code, in React Native apps. I have found two main options: push notifications and in-app messages.

Push notifications can be implemented with services, such as Firebase and OneSignal, and work well except there is a claim that they are not very reliable and sometimes messages can get lost. The advantage of push notifications is that they work regardless of whether the app is in the foreground or background.

In-app messages can be implemented with event-bus services, such as SignalR (Azure or standalone), AWS SNS or GraphQL subscriptions. These services are pretty reliable, but this approach only works when the app is in the foreground.

However, there appears to be another option which doesn't seem to be as popular as the first two. This option involves running a native background service/process on the mobile device which participates in in-app message exchange similar to the normal in-app messaging. The background service would subscribe to SignalR or SNS or GraphQL and display a local notification on the device when it receives a message.

What are the problems with the last approach and why not prefer it over the hybrid approach (push notifications when app is in background but in-app messages when app is in foreground) which seems to be more commonly used?

Thanks!

event-bus onesignal firebase react-native push-notification
1 Answers

The main limit is that mobile devices do not allow applications to keep a long-lived connection open in the background. This limit became more strongly enforced in Android 8 (Oreo) (documented here https://developer.android.com/about/versions/oreo/background#services), and this has always been true on iOS. Exceptions are made for certain VoIP applications, but generally, this rule applies to all apps.

One of the key reasons is battery life. Keeping a connection open takes a small amount of energy and if a user had dozens of apps like this, then it would be a noticeable issue. As a result, both Google and Apple have standardized around having a single connection open to the device that all notifications are delivered through.

For what it's worth, iOS notifications are actually very reliable and consistent. Android is more problematic due to modifications made by various OEMs. (documented here: https://dontkillmyapp.com/)

One workaround is that you could distribute an application outside of the Google Play Store that bypassed this limitation by requesting special permissions, however, it would still be affected by the OEM issues just like FCM is and likely worse.

user_834910
Related