[📚] New setup guide for iOS Credentials in RN 0.77

[jordankkk]

Starting with RN 0.77 /ios/{projectName}/AppDelegate.mm is removed and changed to AppDelegate.swift

---

[mikehardy]

Hi there - please just hit the edit button top right of the page and propose a change

[jordankkk]

@mikehardy I apologize, as I’m new to React Native and am unsure how to make the change. 😁

[romanakash]

Created a PR here #8251

[tahaipek]

Thank you for your guidance and PR.

Similarly, do you have a guide to enable Multidex on Swift?
https://rnfirebase.io/enabling-multidex#enabling-multidex

Similarly, do you have a guide to configure Cloud Messaging in Swift?
https://rnfirebase.io/messaging/usage#background-application-state

Or was the problem solved from a more fundamental point in RN 0.77? I couldn't find any documentation on this.

I noticed that the documentation of rnfirebase.io is old.

I'm currently trying to update ReactNative 0.72 to 0.77, so I need to adapt many packages back to 0.77.

[mikehardy]

@tahaipek 👋

The documentation on rnfirebase.io is as new as we have it, if there is something out of date there is an edit button top right of every page and the github PR flow in their web UI for text changes is trivial. I imagine since you mention react-native 0.77 you have noticed that react-native now uses AppDelegate.swift vs .mm. Please feel free to post a PR

Multidex was a workaround for old Android devices that are no longer supported, and we may all happily forget about multidex forever. And you never ever needed to think about it for iOS, it was an Android thing. You will never need it with modern Android.

[tahaipek]

Hi,
I think I will reach the solution a little late because I don't have technical knowledge about Native Android (kotlin) and iOS (swift) development. If I reach the solution, I will definitely update the docs and create PR.

• I will skip the Multidex state. Thank you for your technical guidance.
• I wonder if you can give some guidance for the “Background Application State” state?

Thanks in advance for your advice.

[MezillaJohn]

Hi there - please just hit the edit button top right of the page and propose a change

Please can you guys update this and the docs as soon as possible, cause we are stuck here.

[vishalksymentix]

This is the updated Doc of react native 0.77 with firebase. How can you modify appdelegate.swift to integrate the firebase

use this to import firebase

import Firebase

use this to initialize firebase
FirebaseApp.configure()

[AnmolMalik-BWES]

App started crashing after FirebaseApp.configure()

"@react-native-firebase/app": "^21.7.2",
"@react-native-firebase/messaging": "^21.7.2",
"react-native": "^0.77.0",

Do I also need to change Podfile

[vishalksymentix]

App started crashing after FirebaseApp.configure()

"@react-native-firebase/app": "^21.7.2", "@react-native-firebase/messaging": "^21.7.2", "react-native": "^0.77.0",

Do I also need to change Podfile

Please mention your podfile here

[Barot-sam]

@AnmolMalik-BWES, After some digging I achieved it and made a guide on the medium for the react-native 0.77 I hope it helps https://medium.com/@ompbarot9816/firebase-and-google-maps-for-react-native-0-77-full-guide-8fb9646b7ef5

I'm using react-native-firebase version 20.5.0. please let me know if I can help.

[tahaipek]

@vishalksymentix and @Barot-sam, I plan to try out your solutions as soon as possible. I’ll share my experience here, letting you know whether the solution works and if I run into any issues. For now, I’ve implemented it as shown below and will continue with my work.

I was facing unexpected crashes with Swift integration, so I temporarily switched back to Objective-C (.mm files) in RN 0.77. I followed these instructions to resolve the issue. This workaround is running smoothly for now, and I'll update once I get a stable Swift solution.

Below is the code I used:

AppDelegate.mm file:

// Custom: Firebase, Background Application State
#import "RNFBMessagingModule.h"

#import "AppDelegate.h"
#import <React/RCTBundleURLProvider.h>

// highlight-next-line
#import <ReactAppDependencyProvider/RCTAppDependencyProvider.h>

// Custom: Firebase
#import <Firebase.h>


@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  // Custom: Firebase
  [FIRApp configure];
  [application registerForRemoteNotifications];

  self.moduleName = @"DemoApp";
  
  // Custom: https://github.com/facebook/react-native-website/blob/main/website/blog/2025-01-21-version-0.77.md#rctappdependencyprovider
  self.dependencyProvider = [RCTAppDependencyProvider new];  // You can add your custom initial props in the dictionary below.
  
  self.initialProps = [RNFBMessagingModule addCustomPropsToUserProps:nil withLaunchOptions:launchOptions];
  return [super application:application didFinishLaunchingWithOptions:launchOptions];
}

  // Custom: Firebase
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
  [FIRMessaging messaging].APNSToken = deviceToken;
}

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
  return [self bundleURL];
}

- (NSURL *)bundleURL
{
#if DEBUG
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}

@end

AppDelegate.h file:

#import <RCTAppDelegate.h>
#import <UIKit/UIKit.h>

@interface AppDelegate : RCTAppDelegate

@end

[Barot-sam]

@tahaipek, Sorry I was busy with some issues, I'm currently using the swift in my project and it is working smoothly from last 1 week, can you show me the errors that you face? it will help me solve your issue, and also put up more details in my article which will help more developers out there.

[aliceni81]

@tahaipek Hi, may i know if your react native project enabled new architecture for iOS? I have the same settings as yours, but notifications with ios devices in quit state do not work properly. I'm using react native v0.76.7, react-native-firebase/messaging v21.10.1

[tahaipek]

@aliceni81 hi, new architecture is active in my PodFile.

"@react-native-firebase/messaging": "21.7.1"
"react-native": "0.77.0"

Podfile:

..
..
..
ENV['RCT_NEW_ARCH_ENABLED'] = '1'
$FirebaseSDKVersion = '11.7.0'

platform :ios, min_ios_version_supported
prepare_react_native_project!
..
..
..

[mikehardy]

@aliceni81 I was testing iOS quit state messaging via a handler set in setBackgroundMessageHandler just yesterday. iPhone SE2, current iOS, react-native 0.77.1 and react-native-firebase 21.10.1 and it all worked fine for me - that work was committed as the most recent set of commits on https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh and was used in troubleshooting #8347 / developing the patch in #8349 - which was all about iOS background states, it had to work + had to be tested for me to develop that patch, so I'm certain iOS background messaging is working if everything is set up correctly

[aliceni81]

Thanks @tahaipek and @mikehardy for your information.
I'm sure my project set up is correct because it's working well with react native v0.76.7 old architecture.
@mikehardy Indeed, I submitted a bug report facebook/react-native#48551
With your confirmation, it seems that I need to upgrade the react native to 0.77.1. Thanks again.

[mikehardy]

@aliceni81 - if the problem you are having is that the isHeadless prop isn't set correctly in appProperties, I think my comment on that related issue is the actual path forward - I'm not sure exactly how to do it but the pseudo-code I typed out in the comments in there is the outline of the process. Basically you need to execute the appProperties set at a different point in the app bootstrap, which you can hook into by observing for that event. Then you get handle on the react-native objects and stuff the isHeadless in the appProperties then based on foreground or background

the handler itself - setBackgroundMessageHandler - is working though

[aliceni81]

@tahaipek May I know if you use the headlessCheck in your project react native 0.77.0?

// index.js
import { AppRegistry } from 'react-native';
import messaging from '@react-native-firebase/messaging';

// Handle background messages using setBackgroundMessageHandler
messaging().setBackgroundMessageHandler(async remoteMessage => {
  console.log('Message handled in the background!', remoteMessage);
});

// Check if app was launched in the background and conditionally render null if so
function HeadlessCheck({ isHeadless }) {
  if (isHeadless) {
    // App has been launched in the background by iOS, ignore
    return null;
  }

  // Render the app component on foreground launch
  return <App />;
}

// Your main application component defined here
function App() {
  // Your application
}

AppRegistry.registerComponent('app', () => HeadlessCheck);

[tahaipek]

Yes, I use it a little bit. How do you want me to test it? I'm writing a code example for you below.

You can also check this document if it helps: https://notifee.app/react-native/docs/integrations/fcm

App.js

import {AppRegistry, Platform} from 'react-native';

import AppHeadless from './AppHeadless';
import {getMessaging} from '@react-native-firebase/messaging';

//Register background handler
getMessaging().setBackgroundMessageHandler(async remoteMessage => {
  console.log(remoteMessage, 'remoteMessage');
  Promise.resolve(remoteMessage);
});

AppRegistry.registerComponent(appName, () => AppHeadless);

AppHeadless.js

import {useAppState} from '@react-native-community/hooks';
import React, {useEffect, useState} from 'react';
import App from './App';
import PushNotificationForegroundEventHook from './PushNotificationForegroundEventHook';

const AppHeadless = ({isHeadless, isBackground, navigation}) => {
  const appState = useAppState();
  const [beenActive, setBeenActive] = useState(!isBackground);

  const [isPressed, isDismissed] = PushNotificationForegroundEventHook({
    navigation,
  });

  useEffect(() => {
    console.log('🔶 :', isPressed, isDismissed);
  }, [isPressed, isDismissed]);

  useEffect(() => {
    if (appState === 'active') {
      setBeenActive(true);
    }
    console.info('🔵 - appState', appState);
  }, [appState]);

  if (isHeadless) {
    // App has been launched in the background by iOS, ignore
    console.info('🔵 - isHeadless', isHeadless);
    return <></>;
  }

  if (!beenActive) {
    // App has been launched in the background by iOS, ignore
    console.info('🔵 - beenActive:', beenActive);
    return <></>;
  }

  return <App />;
};

export default AppHeadless;

PushNotificationForegroundEventHook.js

import React, { useEffect } from 'react';
import notifee, { EventType } from '@notifee/react-native';

const PushNotificationForegroundEventHook = ({ navigation }) => {
  const [isPressed, setPressed] = React.useState(false);
  const [isDismissed, setDismissed] = React.useState(false);

  useEffect(() => {
    return notifee.onForegroundEvent(({ type, detail }) => {
      switch (type) {
        case EventType.DISMISSED:
          console.log('🔵 - ForegroundEvent dismissed event notification', detail.notification);
          setPressed(false);
          setDismissed(true);
          break;
        case EventType.PRESS:
          console.log( '🔵 - ForegroundEvent pressed event notification', detail.notification);
          setPressed(true);
          setDismissed(false);
          break;
        default:
          console.log( '🔵 - ForegroundEvent default notification', detail.notification );
          setPressed(false);
          setDismissed(false);
          break;
      }
    });
  }, []);

  return [isPressed, isDismissed];
};

export default PushNotificationForegroundEventHook;

[aliceni81]

@tahaipek I need your help to test if your app is in the quit state. When receiving a notification and you open your app, will your app display <></> or <App /> ?

[aliceni81]

By the way, according to Mike, the codes should be
import {getMessaging, setBackgroundMessageHandler} from '@react-native-firebase/messaging';
setBackgroundMessageHandler(getMessaging(), callBack());

[tahaipek]

@tahaipek I need your help to test if your app is in the quit state. When receiving a notification and you open your app, will your app display <></> or <App /> ?

Yes it works exactly as you said. It works as “<></>” when the application is in the background/passive and when the application is active.

I'm also migrating from version 0.72 to 0.77.0/0.77.1. Thanks for fixing such situations that I can miss.

[aliceni81]

@tahaipek I need your help to test if your app is in the quit state. When receiving a notification and you open your app, will your app display <></> or <App /> ?

Yes it works exactly as you said. It works as “<></>” when the application is in the background/passive and when the application is active.

I'm also migrating from version 0.72 to 0.77.0/0.77.1. Thanks for fixing such situations that I can miss.

• When the application is in foreground or background, isHeadless should be true, and return <></>;
• When the application in quit, isHeadless should be true and return <></> also. But when open the app or open the app by the notification, isHeadless should be changed to false and return <App />;

With new architecture enabled, for quit, isHeadless won't be changed to false when opening the app at the first time..

[aliceni81]

@tahaipek Can you confirm that the value of isHeadless is not correct with the new architecture in react native v0.77.1 when opening the app after receiving a notification in quit state?

[huanguolin]

@aliceni81 I'm encountering the problem you describe.
"@react-native-firebase/app": "^21.11.0",
"@react-native-firebase/messaging": "^21.11.0",
"react-native": "0.77.1",

[aliceni81]

@huanguolin Thank you for your confirmation. Mike has provided some ideas to address the issue, but since I'm new to React Native, I'm still struggling.. facebook/react-native#48551 (comment)

[huanguolin]

@huanguolin Thank you for your confirmation. Mike has provided some ideas to address the issue, but since I'm new to React Native, I'm still struggling.. facebook/react-native#48551 (comment)

Thank you for the information! I'll give it a try tomorrow and sync my results here.

[mikehardy]

Hey @aliceni81 and @huanguolin I don't have time for what I consider the most valuable + most difficult part - which is thorough testing to make sure this works, using debug logs in various spots to print out easily-searched-for strings and Console.app to look for them while app is running - but I added lots of implementation notes to the comment you link, with direct links to code examples for every step of the algorithm to implement in that listener facebook/react-native#48551 (comment)

Hopefully it helps as there examples now of getting the RCTRootView, determining foreground/background state, opening a main queue block, injecting something new into the appProperties and setting that

[huanguolin]

@mikehardy I really appreciate the solution you provided. However, since I am not familiar with the obj-c/swift code, I didn't try it (I’m not confident that I can piece these together and make it work 😅 ).
In the end, I came up with a workaround at the JS layer, as follows (@aliceni81 It works well on my side, you can give it a try):

export const App = ({ isHeadless }: { isHeadless: boolean }) => {
    const [shouldRenderUI, setShouldRenderUI] = useState(!isHeadless);

    useOnAppStateChange(
        useCallback(async (appState) => {
            if (Platform.OS === 'ios') {
                const isHeadlessValue = await messaging().getIsHeadless();
                setShouldRenderUI(!isHeadlessValue);
            }
        }, []),
    );

    return shouldRenderUI ? <AppCore /> : <></>;
};

[aliceni81]

@huanguolin Thanks for your work! For the above codes, may I know if I need to remove the firebase settings in AppDelegate.mm?

[huanguolin]

@huanguolin Thanks for your work! For the above codes, may I know if I need to remove the firebase settings in AppDelegate.mm?

😄
no, in fact that part of the code still needs ...

// 'isHeadless' value come from the native
export const App = ({ isHeadless }: { isHeadless: boolean }) => {

[mikehardy]

@huanguolin if that's the case then you may simply be winning a race condition right now. For those that lose it, the problem is that the modified app properties are not set in to the react native context if the javascript interpreter was still loading the bundle, see facebook/react-native#20115 (comment)

This problem is upstream in react-native, you may win the race, you may not. And whether you win it or not may be stable depending your specific app (it may load the bundle faster or slower, depending on bundle size/complexity, and that's stable on a per-app basis). This is not fully reliable though and cannot be recommended as a general solution, since some may lose the race nearly every time.

The only general solution is to set app properties in native code after the bundle loads, every time. That's accomplished with the example algorithm I posted that adds an observer to the native event triggered after the bundle loads, and setting the app property then. Guarantees that you aren't in a race, should work every time and be a general solution

[huanguolin]

@mikehardy

Thank you for your comment and for pointing out the concerns regarding my solution.

Since I am not familiar with the startup process of React Native, I couldn’t fully understand the issue you raised. Please allow me to discuss it further with you here.

First, let me explain my solution:

Premise:

1. As I understand it, when an iOS app receives a remote push notification, it gets woken up and executes for a short period.
2. The value of isHeadless, which is injected into initialProps in AppDelegate.mm, does not change.

The problem:
When the app is in a quit state and receives a push notification ->
The JS layer gets isHeadless as true, so the app doesn’t render the UI ->
Then the user taps on the app, and it opens but shows a white screen (isHeadless does not change to false, and the user expects the UI to display normally).

My solution:

1. The messaging().getIsHeadless() method should always return the correct value.
2. When the app is opened by the user, the AppStateStatus should change, and at this point, we can directly call messaging().getIsHeadless() to retrieve the value.

Code to listen for AppStateStatus changes:

import { useEffect, useRef } from 'react';
import { AppState, AppStateStatus } from 'react-native';

export function useOnAppStateChange(handleAppStateChange: (status: AppStateStatus) => void) {
    const handler = useRef(handleAppStateChange);

    useEffect(() => {
        handler.current = handleAppStateChange;
    }, [handleAppStateChange]);

    useEffect(() => {
        // Initial check
        handler.current(AppState.currentState);

        // Check when appState changes
        const listener = AppState.addEventListener('change', (appState: AppStateStatus) => {
            handler.current(appState);
        });

        return listener.remove;
    }, []);
}

According to my testing and understanding, the execution flow of my solution is as follows:

1. The app is in a quit state and receives a push notification ->
2. The JS layer gets isHeadless as true, and shouldRenderUI is set to false, so the app doesn’t render the UI (and the useOnAppStateChange listener is registered) ->
3. Then, when the user taps on the app ... triggering an AppStateStatus change. At this point, the messaging().getIsHeadless() method is called to retrieve the new value of isHeadless ->
4. The new value of isHeadless is false, and shouldRenderUI is set to true, so the UI displays normally.

This is my proposed solution, and I’d appreciate it if you could point out any stage where there might be an issue or if I’ve misunderstood anything.

Additionally, I’m using React Native 0.77 with the new architecture. Is the bridge still present in this version? 😃
I don’t fully understand this part—I just noticed the word “bridge” in the comment link you shared. Either way, thank you so much for your help!

[aliceni81]

@mikehardy I really appreciate the solution you provided. However, since I am not familiar with the obj-c/swift code, I didn't try it (I’m not confident that I can piece these together and make it work 😅 ). In the end, I came up with a workaround at the JS layer, as follows (@aliceni81 It works well on my side, you can give it a try):

export const App = ({ isHeadless }: { isHeadless: boolean }) => {
const [shouldRenderUI, setShouldRenderUI] = useState(!isHeadless);

useOnAppStateChange(
    useCallback(async (appState) => {
        if (Platform.OS === 'ios') {
            const isHeadlessValue = await messaging().getIsHeadless();
            setShouldRenderUI(!isHeadlessValue);
        }
    }, []),
);

return shouldRenderUI ? <AppCore /> : <></>;

};

Hi @huanguolin I confirm your workaround does work! Thanks.

[huanguolin]

@aliceni81 You're welcome! I'm glad this was helpful to you. 😃

[mikehardy]

@huanguolin I think you may be on to something, I hadn't thought of the isHeadless method being used at the javascript level.

There is a lot of code in the iOS area here involved in keeping the isHeadless state updated, involving a listener to the "on notification launched app" iOS native event and the "application entered foreground" iOS native event

Both should be making it so your basic assumption:

The messaging().getIsHeadless() method should always return the correct value.

...is true. It really should be true. Given that, using it at the javascript level as a gate to whether you render the whole app or not should be an effective solution however you want to do it.

Note that I don't think you need to be as careful about transitioning from "we are foreground" to "we are background". At that point the app is already rendered, and iOS will terminate it shortly in the background anyway (so you'll start fresh again...). Our code essentially ignores that transition since maintaining the already rendered app for slightly longer than necessary really has no cost.

The only one you really need to pay attention to is when you go from headless (no app rendered / blank screen) to foreground. Getting that wrong breaks everything.

I'm going to do some testing to verify this works well and if it does then I think the recommended approach should move to using javascript level check with the existing messaging.isHeadless as you are doing.

[huanguolin]

@mikehardy I’m truly thrilled that my proposal got your approval!

Note that I don't think you need to be as careful about transitioning from "we are foreground" to "we are background". At that point the app is already rendered, and iOS will terminate it shortly in the background anyway (so you'll start fresh again...). Our code essentially ignores that transition since maintaining the already rendered app for slightly longer than necessary really has no cost.

The only one you really need to pay attention to is when you go from headless (no app rendered / blank screen) to foreground. Getting that wrong breaks everything.

Are you suggesting changing it to this? Or perhaps there's a more efficient way...

export const App = ({ isHeadless }: { isHeadless: boolean }) => {
    const [shouldRenderUI, setShouldRenderUI] = useState(!isHeadless);

    useOnAppStateChange(
        useCallback(async (appState) => {
            if (Platform.OS === 'ios' &&  appState === 'active') { // <=== Here
                const isHeadlessValue = await messaging().getIsHeadless();
                setShouldRenderUI(!isHeadlessValue);
            }
        }, []),
    );

    return shouldRenderUI ? <AppCore /> : <></>;
};

Either way, we're excited to see your testing and to work toward an efficient, complete, and universal solution together.
Thanks again for maintaining the plugin and making things easier for everyone! 😃

[aliceni81]

@mikehardy I’m truly thrilled that my proposal got your approval!

Note that I don't think you need to be as careful about transitioning from "we are foreground" to "we are background". At that point the app is already rendered, and iOS will terminate it shortly in the background anyway (so you'll start fresh again...). Our code essentially ignores that transition since maintaining the already rendered app for slightly longer than necessary really has no cost.

The only one you really need to pay attention to is when you go from headless (no app rendered / blank screen) to foreground. Getting that wrong breaks everything.

Are you suggesting changing it to this? Or perhaps there's a more efficient way...

export const App = ({ isHeadless }: { isHeadless: boolean }) => {
const [shouldRenderUI, setShouldRenderUI] = useState(!isHeadless);

useOnAppStateChange(
    useCallback(async (appState) => {
        if (Platform.OS === 'ios' &&  appState === 'active') { // <=== Here
            const isHeadlessValue = await messaging().getIsHeadless();
            setShouldRenderUI(!isHeadlessValue);
        }
    }, []),
);

return shouldRenderUI ? <AppCore /> : <></>;

};
Either way, we're excited to see your testing and to work toward an efficient, complete, and universal solution together. Thanks again for maintaining the plugin and making things easier for everyone! 😃

I think Mike means that we only need to use getIsHeadless() when the device is iOS, isHeadless is true and the app state changes from inactive to active?

[stakez]

This is the updated Doc of react native 0.77 with firebase. How can you modify appdelegate.swift to integrate the firebase

use this to import firebase

import Firebase

use this to initialize firebase FirebaseApp.configure()

My IOS app is crashing is also crashing on this. Anyone know why?

[blueromans]

This is the updated Doc of react native 0.77 with firebase. How can you modify appdelegate.swift to integrate the firebase

use this to import firebase
import Firebase
use this to initialize firebase FirebaseApp.configure()

My IOS app is crashing is also crashing on this. Anyone know why?

import from FirebaseCore and check the .plist file.

[AjayFrancisTechversant]

This is the updated Doc of react native 0.77 with firebase. How can you modify appdelegate.swift to integrate the firebase

use this to import firebase
import Firebase
use this to initialize firebase FirebaseApp.configure()

My IOS app is crashing is also crashing on this. Anyone know why?

import from FirebaseCore and check the .plist file.

what to check on .plist file?

[blueromans]

This is the updated Doc of react native 0.77 with firebase. How can you modify appdelegate.swift to integrate the firebase

use this to import firebase
import Firebase
use this to initialize firebase FirebaseApp.configure()

My IOS app is crashing is also crashing on this. Anyone know why?

import from FirebaseCore and check the .plist file.

what to check on .plist file?

I mean GoogleService-Info.plist file if it doesn't exist it crashes.

[blueromans]

import UIKit
import React_RCTAppDelegate
import ReactAppDependencyProvider
import FirebaseCore
import FirebaseMessaging

@main
class AppDelegate: RCTAppDelegate, MessagingDelegate {
override func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
FirebaseApp.configure();
Messaging.messaging().delegate = self
application.registerForRemoteNotifications()

self.moduleName = "***"
self.dependencyProvider = RCTAppDependencyProvider()

// You can add your custom initial props in the dictionary below.
// They will be passed down to the ViewController used by React Native.
self.initialProps = [:]

return super.application(application, didFinishLaunchingWithOptions: launchOptions)

}

override func sourceURL(for bridge: RCTBridge) -> URL? {
return self.bundleURL()
}

override func bundleURL() -> URL? {
#if DEBUG
return RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
return Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}

override func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
Messaging.messaging().apnsToken = deviceToken
}
}

this is the working one

[wasimirza-et]

https://medium.com/@wasi.mirza/react-native-0-78-firebase-phone-authentication-step-by-step-guide-af85be0a0621
Please check my Medium Article for the 0.78 React Native setup.
This will solve the problem. Hopefully for all.
Thank you.