Significant Delay in IOS setBackgroundMessageHandler

[JoeToeniskoetter]

I am experiencing an 8+ second delay from the time the notification is received on the device to when the background message handler is fired.

I've tried removing bits of code one by one to see where my problem lies but I still haven't resolved this.

Here is my index.js

import {AppRegistry} from 'react-native';
//import App from './App';
import messaging from '@react-native-firebase/messaging';
import React from 'react';
import {Text} from 'react-native';

function HeadlessCheck({isHeadless}) {
  if (isHeadless) {
    return null;
  }

  return <Text>Test</Text>;
}

messaging().setBackgroundMessageHandler(async (remoteMessage) => {
  console.log('Message handled in background', remoteMessage);
});
AppRegistry.registerComponent('My App', () => HeadlessCheck);

Even with this heavily reduced file, I am still experiencing an 8 or so second delay.
Any pointers on debugging this issue?

[mikehardy]

Open it in Xcode, do a release mode build on a real device, then watch it using Xcode profiling tools to see where you are spending time in native code boot. Without seeing in package.json what other items are present it's impossible to know what native code is being loaded + run despite seeing the javascript here

[mikehardy]

Mmm - that is a pretty spare project, nothing jumps out. Network timeouts are suspicious though, what is being fetched on startup? Why isn't it working? No idea but the answer is probably in there...

[JoeToeniskoetter]

Mmm - that is a pretty spare project, nothing jumps out. Network timeouts are suspicious though, what is being fetched on startup? Why isn't it working? No idea but the answer is probably in there...

Yeah this is getting pretty frustrating. The network timeouts do not happen each time a notification comes through. I am not making any network requests on startup so who knows what's going on there. If the application is in quit state instead of just in the background, a notification comes through, and you attempt to open the application right away, the application crashes.

[mikehardy]

Are you certain you are using firebase-ios-sdk 6.34.0 ? check Podfile for override and make sure it's that version. There is a related problem #4299 that may mean you want to use a specific forked version of that version even, with one patch for ios notifications until #4471 lands (should be today) - but in general all I can think of is something underlying with firebase-ios-sdk or your device+network

[JoeToeniskoetter]

@mikehardy I updated to the most recent package but this did not resolve my issue. I saw a thread about the react-native-splash-screen package potentially interfering with the onNotificationOpenedApp function. Could this package be causing my issues?

[mikehardy]

One of my strongest recommendations: Never use react-native-splash-screen. Convert to react-native-boot-splash.
Bonus points, react-native-boot-splash even has a command line utility to do the initial integration. Super easy.

That said, I doubt it will affect your problem. It will just stop you from having other problems.

[Salakar]

Drive by comment but the 8 second delay comes from this; https://github.com/invertase/react-native-firebase/blob/master/packages/messaging/ios/RNFBMessaging/RNFBMessaging%2BAppDelegate.m#L135

This was added in #4144 due to #4104 - added in favor of working all the time but with a delay vs not working 'some of the time'.

A better solution does need implementing along the lines of what I mentioned in #4104 (comment) - JS needs to tell native that it's ready for the events (it does actually already do this currently so something else there is not working as intended).

[JoeToeniskoetter]

Ah, I see. So with the current implementation there really isn't anything I can do to fix this.

[mikehardy]

That's correct - I had forgotten about that one, good on @Salakar to remember it and post that up.
It has not been a priority to find the underlying cause, and no one has seemed to mind the 8 second delay enough to post about it until now, so it has seemed "sufficient" vs other priorities. Acknowledging that's not perfect we'd love a PR that fixed it for real (there are good pointers in the comment on 4104) but it will likely need to come from a motivated person in the community. If that was you I will promise to work hard to shepherd it to merge and release though