react-native-firebase Documentation

Your data is stored in a Google Cloud Storage bucket, an exabyte scale object storage solution with high availability and
global redundancy. Storage lets you securely upload these files directly from mobile devices, handling spotty networks with ease.

Usage

Your files are stored in a Google Cloud Storage bucket. The files in this bucket are presented in a hierarchical structure,
just like a file system. By creating a reference to a file, your app gains access to it. These references can then be
used to upload or download data, get or update metadata or delete the file. A reference can either point to a specific
file or to a higher level node in the hierarchy.

The Storage module also provides support for multiple buckets.

You can view your buckets on the Firebase Console.

Creating a reference Copy Chapter

A reference is a local pointer to some file on your bucket. This can either be a file which already exists, or one
which does not exist yet. To create a reference, use the ref method:

import { getStorage, ref } from '@react-native-firebase/storage';

const reference = ref(getStorage(), 'black-t-shirt-sm.png');

You can also specify a file located in a deeply nested directory:

const reference = ref(getStorage(), '/images/t-shirts/black-t-shirt-sm.png');

Upload a file Copy Chapter

To upload a file directly from the users device, the putFile method on a reference accepts a string path to the file
on the users device. For example, you may be creating an app which uploads users photos. The React Native Firebase
library provides utilities such as FilePath to help identify device directories:

import React, { useEffect } from 'react';
import { View, Button } from 'react-native';

import { FilePath } from '@react-native-firebase/app';
import { getStorage, ref, putFile } from '@react-native-firebase/storage';

function App() {
  const storage = getStorage();
  const reference = ref(storage, 'black-t-shirt-sm.png');

  return (
    <View>
      <Button
        onPress={async () => {
          const pathToFile = `${FilePath.PICTURES_DIRECTORY}/black-t-shirt-sm.png`;
          await putFile(reference, pathToFile);
        }}
      />
    </View>
  );
}

Tasks Copy Section

The putFile method returns a Task, which if required, allows you to hook into information
such as the current upload progress:

const task = putFile(reference, pathToFile);

task.on('state_changed', taskSnapshot => {
  console.log(`${taskSnapshot.bytesTransferred} transferred out of ${taskSnapshot.totalBytes}`);
});

task.then(() => {
  console.log('Image uploaded to the bucket!');
});

A task also provides the ability to pause & resume on-going operations:

const task = putFile(reference, pathToFile);

task.pause();

// Sometime later...
task.resume();

Download URLs Copy Chapter

A common use-case for Cloud Storage is to use it as a global Content Delivery Network (CDN) for your images. When uploading
files to a bucket, they are not automatically available for consumption via a HTTP URL. To generate a new Download URL, you
need to call the getDownloadURL method on a reference:

import { getStorage, ref, getDownloadURL } from '@react-native-firebase/storage';

const url = await getDownloadURL(ref(getStorage(), 'images/profile-1.png'));

Images uploaded manually via the Firebase Console automatically generate a download URL.

Listing files & directories Copy Chapter

If you wish to view a full list of the current files & directories within a particular bucket reference, you can use
the list method. The results are however paginated, and if more results are available you can pass a page token into the request:

import { getStorage, ref } from '@react-native-firebase/storage';

function listFilesAndDirectories(reference, pageToken) {
  return reference.list({ pageToken }).then(result => {
    // Loop over each item
    result.items.forEach(ref => {
      console.log(ref.fullPath);
    });

    if (result.nextPageToken) {
      return listFilesAndDirectories(reference, result.nextPageToken);
    }

    return Promise.resolve();
  });
}

const reference = ref(getStorage(), 'images');

listFilesAndDirectories(reference).then(() => {
  console.log('Finished listing');
});

Security Copy Chapter

By default your bucket will come with rules which allows only authenticated users on your project to access it. You can
however fully customize the security rules to your own applications requirements.

To learn more, view the Storage Security documentation
on the Firebase website.

Multiple Buckets Copy Chapter

A single Firebase project can have multiple storage buckets. The module will use the default bucket if no bucket argument
is passed to the storage instance. To switch buckets, provide the module with the gs:// bucket URL found on the
Firebase Console, under Storage > Files.

import { getStorage } from '@react-native-firebase/storage';
import { getApp } from '@react-native-firebase/app';

const defaultStorageBucket = getStorage();
const secondaryStorageBucket = getStorage(getApp(), 'gs://my-secondary-bucket.appspot.com');

Vertexai Usage Index (`docs/vertexai/usage/index.mdx`) Copy Section

title: VertexAI next: /migrating-to-v6 previous: /phone-number-verification/usage Copy Chapter

Vertex AI has been deprecated by Google in favor of the Firebase AI Logic SDK.

Using the Firebase AI Logic SDK with the Vertex AI Gemini API is still generally available (GA).

To start using the new SDK, import the @react-native-firebase/ai package and use the modular method getAI() to initialize. See details in the migration guide.

// BEFORE - using firebase/vertexai
import { initializeApp } from 'firebase/app';
import { getVertexAI, getGenerativeModel } from 'firebase/vertexai'; // Remove this

// AFTER - using firebase/ai
import { initializeApp } from 'firebase/app';
import { getAI, getGenerativeModel } from 'firebase/ai'; // Add this

Platform support

Deprecated: Prefer @react-native-firebase/ai — see the Firebase migration guide.

About (`docs/about.mdx`) Copy Section

title: About noindex: true Copy Chapter

About React Native Firebase

The React Native Firebase project started life in late 2016 as a personal project Mike Diarmid
and Elliot Hesp were working on. The project gained instant popularity, allowing React Native developers
to hook into the native services Firebase provides.

During the first few months of its development, the repository was moved into the organization of Invertase on GitHub.
The organization was a collection of the personal and combined Open Source efforts Mike and Elliot had been
working over the past number of years. With a constant flow of feature requests, issues and contributions,
the library rapidly grew in popularity, achieving over 100k NPM downloads in its first 12 months of development.

In mid-2017, we were approached by Google, who offered to help ensure the projects continued support by providing direct contact with the
Firebase team and by providing funding to ensure the project had dedicated time assigned to its upkeep.

In the 2018 Firebase Summit in Prague during the opening keynote, Google openly announced their
working relationship with Invertase - check it out below:

https://twitter.com/rnfirebase/status/1056839638961348608/video/1

Future of the library Copy Chapter

The React Native Firebase library has been a huge driving force for our knowledge and experience. Even with years of
experience in Open Source, JavaScript, Android and iOS, we're constantly learning and improving the library -
whilst focusing on the needs of the community and many users of the library. Maintaining a popular Open Source
library is hard, yet rewarding work.

With the support from the community and Google, we're pleased to announce that starting in 2019, our very own
Mike Diarmid will be working full time on the library. With the lessons we've learnt, we'll be focusing on taking the
library to a new level. Read about it here.

The success and upkeep of the library would not be possible without the support and contributions from the community.
To date, we've had contributions from 114 members of the Open Source community on the repository to who we're very
grateful to, the project wouldn't be where it is without you. Special thanks to Chris Bianca
at CS Frequency Limited for their work in helping to get this project off the ground.

We'd also like to extend our thanks to our backers on Open Collective, whose contributions have made it possible to
sustain the vast amount of time required in the upkeep of such a project.

The future of Invertase and React Native Firebase is exciting.

Enabling Multidex (`docs/enabling-multidex.mdx`) Copy Section

title: Enabling Multidex Copy Chapter

As more native dependencies are added to your project, it may bump you over the
64k method limit on the Android build system. Once this limit has been reached, you will start to see the following error
whilst attempting to build your Android application:

Execution failed for task ':app:mergeDexDebug'.

To learn more about multidex, view the official Android documentation.

Enabling Multidex Copy Chapter

There are 3 steps involved in enabling multidex.

Steps 1 and 2 tell Gradle to turn on multidex with a directive, and add new dependency.

Open the /android/app/build.gradle file. Under dependencies we need to add the module, and then enable it
within the defaultConfig:

android {
    defaultConfig {
        // ...
        multiDexEnabled true // <-- ADD THIS in the defaultConfig section
    }
    // ...
}

dependencies {
  implementation 'androidx.multidex:multidex:2.0.1'  // <-- ADD THIS DEPENDENCY
}

The 3rd step is to alter your android/app/src/main/java/.../MainApplication.java file to extend MultiDexApplication like so:

// ... all your other imports here
import androidx.multidex.MultiDexApplication; // <-- ADD THIS IMPORT


// Your class definition needs `extends MultiDexApplication` like below
public class MainApplication extends MultiDexApplication implements ReactApplication {

Once added, rebuild your application: npx react-native run-android.

Faqs And Tips (`docs/faqs-and-tips.mdx`) Copy Section

title: FAQs and Tips next: /ai/usage previous: /ios-spm Copy Chapter

Over the years, there’s been a lot of discussions on our GitHub and Discord. Many of them have been about common problems developers face when using our package, and some of them resulted in very good advice being given.

In order to save others time and frustration, this page has been created to document some of these common problems and good pieces of advice.
If you come across a discussion that results in great advice that can benefit many developers, or a discussion that resolves a problem that many developers encounter, please do add it here! Someone will definitely be grateful.

FAQs

Why `react-native-firebase` over `firebase-js-sdk`? Copy Section

This package wraps firebase-android-sdk and firebase-ios-sdk into a Javascript API for React Native projects, so the main benefits come with the access to native code.

• There are more modules in the native SDKs than the web SDK because some things only make sense in a mobile / native context ( App Distribution, Crashlytics), so you can actually do more, and some of it is important for example, monitoring quality with Crashlytics

• Some of the modules that are both in the web SDK and native SDK have a great deal more functionality when they can harness native APIs, like messaging (with background delivery that can start your app if not running), like App Check where you can tie the attestation to device-level providers, Storage where you can do background downloads, Performance where you can start measurements from boot, etc.

Does it work with New Architecture / Fabric / TurboModules ? Copy Section

As far as we know, yes. We test with new architecture enabled now, and many of our users are using react-native 0.76+ with new architecture enabled.

We are not aware of any problems with the react-native-firebase modules themselves. Please let us know if you see anything.

However, we are still running in the TurboModule interoperability mode as we have not directly ported to Fabric internally yet. Migration is planned in the future but may still be a while.

I need help with [anything regarding v5 or earlier of React Native Firebase]. Where could I get help with that? Copy Section

React Native Firebase v5 is now deprecated and unsupported. There's been over a year's grace period provided to migrate to v6, so moving forward maintainers probably won't pay much attention to issues regarding v5. Understandably, upgrading to v6 can take some effort, but staying on v5 probably isn't a great choice for the long-term health of your project.
Lots of the breaking changes that were introduced were either due to upstream deprecations in the official SDKs, or to simply make the package more stable and more representative of how the actual SDKs work.
The longer you stay on v5, the more your project will be out of sync with the official SDKs, unfortunately. Couple that with the fact that it's no longer actively supported, and that's trouble looming over the horizon for your project.

We highly recommend taking the necessary pains to update to v6.

My CI build hangs at the "Running script '[CP-User] [RNFB] Core Configuration'" step Copy Section

This may be fixed by creating a firebase.json file at the root of your project if it's not there already. If you don't want to change any of the default React Native Firebase configurations, you can leave it empty in the following way:

{
  "react-native": {
  }
}

I have a custom Analytics parameter called 'items' and it's not showing up on the Firebase console. How come? Copy Section

This happens to be a known problem with the upstream Analytics SDKs. The Firebase team doesn't have any plans to fix it soon. More information about this can be found here.

I'm receiving `InternalFirebaseAuth.FIREBASE_AUTH_API is not available on this device`. How do I fix this? Copy Section

To use some Firebase services (like auth) in an emulator, you need an Android virtual device with Google Play services installed. Check this Stack Overflow post for instructions on creating a new Android virtual device with the necessary APIs installed.

I'm getting an SIGABRT error in Xcode when faking a crash on iOS. How do I fix this? Copy Section

When you get an error on this line when faking a crash on iOS:

RCT_EXPORT_METHOD(crash) {
  if ([RNFBCrashlyticsInitProvider isCrashlyticsCollectionEnabled]) {
    assert(NO);
  }
}

Just disable your debugger in Xcode. 'Project name' -> 'Edit Scheme...' -> 'Run' -> deselect "Debug executable"

I have the latest SDK installed, but I can't send a test in app message from the console. How do I fix this? Copy Section

Sometimes when building an in-app-message in the console, sending a test to a device is not possible, as the "Test on device" button is grayed out. This can be very annoying, but have found a "work around" that enables the button:

1. Make sure to fill out all fields in the first step of the form. If that doesn't enable the button:
2. Make sure to click inside every field, even if the field does not need to be updated (specially the "Text color" ones). If that doesn't enable the button:
3. Change between the "Message layout" options (Card, Modal, Image only and Top banner).

Sometimes, after step 3, you have to click inside a "Text color" field, but this should enable the "Test on device" option. After that you add the device Install ID, make sure to quit the app before the actual test, and then I wait for the confirmation toast to open the app up again. As long as the ID is 100% correct, the test should work as intended.

On iOS, when the app is in quit state, the setBackgroundMessageHandler is never invoked even when I receive the notification. How can I fix this? Copy Section

Note: If you use @notifee/react-native, since v7.0.0, onNotificationOpenedApp and getInitialNotification will no longer trigger as notifee will handle the event.

When the app is closed/quit, this can happen even when you are getting notifications and even when you are able to invoke the app in a headless state.

To fix this:

1. You first need to send the payload with "content-available: 1" in the apns section of the message payload so the app gets invoked in a headless state.
2. On the index.js page, if the app is invoked in headless mode, instead of returning null, return a simple component that does nothing and renders nothing. Otherwise, return the actual App component.

To view the complete detail for this solution, please refer to this page: #5656

Tips

• Whenever you face a strange issue (or an issue that causes build errors), there are two things you should always consider.
  • Build processes are costly and complex, so caching is used a lot. As a result, certain changes that you make in your app can cause cache conflicts in subsequent builds. Deal with this via npx react-native-clean-project. This does solve a lot of problems.
  • Try and isolate the problem with a template React Native Firebase app. This bash script is particularly helpful in making an empty template app.
• Advice on supporting multiple environments (for example, dev, prod, maybe also staging, qa) for your React Native Firebase App: #3504
• Using Fastlane for iOS deployment together with RN Firebase Crashlytics within CI has been observed to cause builds that hang indefinitely. Using setup_ci(force: true) before building the application may solve the issue.: #3706
• Be careful if you are using a VPN, Google blocks many VPN IPs causing "unavailable" errors for various firebase API calls, and on an Android emulator it might completely mess up the network adapter causing network calls to never return, not only on firebase but on the entire emulated phone.

Install Android (`docs/install-android.mdx`) Copy Section

title: Android Installation Copy Chapter

Android Manual Installation

The following steps are only required if you are using React Native 0.59 or earlier and need to manually integrate the library.

1. Update Gradle Settings Copy Chapter

Add the following to your projects /android/settings.gradle file:

include ':@react-native-firebase_app'
project(':@react-native-firebase_app').projectDir = new File(rootProject.projectDir, './../node_modules/@react-native-firebase/app/android')

2. Update Gradle Dependencies Copy Chapter

Add the React Native Firebase module dependency to your /android/app/build.gradle file:

dependencies {
  // ...
  implementation project(path: ":@react-native-firebase_app")
}

3. Add package to the Android Application Copy Chapter

Import and apply the React Native Firebase module package to your /android/app/src/main/java/**/MainApplication.java file:

Import the package:

import io.invertase.firebase.app.ReactNativeFirebaseAppPackage;

Add the package to the registry:

protected List<ReactPackage> getPackages() {
  return Arrays.asList(
    new MainReactPackage(),
    new ReactNativeFirebaseAppPackage(),

4. Rebuild the project Copy Chapter

Once the above steps have been completed, rebuild your Android project:

npx react-native run-android

Install Ios (`docs/install-ios.mdx`) Copy Section

title: iOS Installation Copy Chapter

iOS Manual Installation

The following steps are only required if you are using React Native 0.59 or earlier, and need to manually integrate the library.

1. Add the Pod Copy Chapter

Add the RNFBApp Pod to your projects /ios/Podfile:

target 'app' do
  #  ...
  pod 'RNFBApp', :path => '../node_modules/@react-native-firebase/app'
end

2. Update Pods & rebuild the project Copy Chapter

You may need to update your local Pods in order for the RNFBApp Pod to be installed in your project:

$ cd ios/
$ pod install --repo-update

Once the Pods have installed locally, rebuild your iOS project:

npx react-native run-ios

Ios Spm (`docs/ios-spm.mdx`) Copy Section

title: iOS SPM Support next: /faqs-and-tips previous: /platforms Copy Chapter

iOS SPM Support

React Native Firebase resolves its Firebase Apple SDK dependencies with
Swift Package Manager (SPM).
This changes only how the native Firebase SDK is installed; your JavaScript and
native application code do not change.

Firebase Apple SDK 13.0.0 and later are no longer distributed through
CocoaPods. The last CocoaPods release is 12.19.0. See Google's
CocoaPods deprecation guide.

Requirements and defaults Copy Chapter

• React Native 0.75 or newer is required (spm_dependency).
• SPM is the only supported Firebase install path for this major.
• $RNFirebaseDisableSPM = true and Expo ios.disableSPM: true fail
  pod install / prebuild — they do not install CocoaPods Firebase 13 pods.
• SPM requires CocoaPods 1.10 or newer for the React Native pod integration.
  React Native 0.75+ templates already satisfy this requirement.
• SPM pins the Firebase iOS SDK to the exact version in
  sdkVersions.ios.firebase in @react-native-firebase/app (currently 13.0.0).

SPM requires dynamic framework linkage:

use_frameworks! :linkage => :dynamic

Do not use RNFB's SPM mode with use_frameworks! :linkage => :static.
A Podfile with no use_frameworks! line (or use_frameworks! false) is static
linkage too — that is the stock React Native / bare Expo default.
firebase-ios-sdk SPM products are automatic libraries (plain .library(...),
not type: .dynamic), so each pod that depends on them embeds its own copy.
With static pod linkage those copies collide at link time as duplicate-symbol
errors. pod install fails fast for that combination instead of surfacing the
linker failure later. Dynamic linkage is required for SPM mode to build and
run; see Sharing FirebaseCore with other native pods
for what dynamic linkage does and does not give you.

Google Sign-In caveat Copy Chapter

Firebase Apple SDK 13 depends on App Check 12. GoogleSignIn and
Firebase 13 in the same app can fail App Check resolution until GoogleSignIn
(and any React Native wrapper that pins it) allow App Check 12. The SPM and
CocoaPods paths are separate:

• SPM: Tagged GoogleSignIn 10.0.0 still declares App Check
  from: "11.0.0" (11.x). google/GoogleSignIn-iOS #626
  (merged on main) widens the SPM App Check range to
  11.0.0 ..< 13.0.0. That change is not in a tagged release yet. An
  SPM resolve can succeed only after a GoogleSignIn tag that includes #626
  (or an equivalent App Check 12-capable SPM range).
• CocoaPods: The GoogleSignIn podspec on main and in 10.0.0 still
  declares AppCheckCore ~> 11.0. #626 did not change the CocoaPods
  dependency. CocoaPods graphs that pull GoogleSignIn alongside Firebase 13
  stay blocked until a podspec bump allows App Check 12 and
  @react-native-google-signin/google-signin (or your Podfile pin) picks up
  that release.

Track GoogleSignIn-iOS releases and the React Native Google Sign-In package
for both paths. SPM progress alone does not unblock CocoaPods consumers.

Expo projects Copy Chapter

Expo projects must select dynamic linkage with
expo-build-properties:

{
  "expo": {
    "plugins": [
      [
        "expo-build-properties",
        {
          "ios": {
            "useFrameworks": "dynamic"
          }
        }
      ]
    ]
  }
}

Do not pass disableSPM: true to the @react-native-firebase/app config
plugin — Firebase 13+ is SPM-only and that option fails prebuild.

The sections below describe editing ios/Podfile directly for React Native
CLI projects. Do not follow Podfile edits in an Expo project -- Expo
regenerates ios/Podfile from your config plugins on every prebuild. Use
expo-build-properties instead, as shown above.

Use SPM (React Native CLI) Copy Chapter

For React Native 0.75 or newer, SPM is selected automatically. Configure dynamic
linkage in your ios/Podfile, then install pods normally:

use_frameworks! :linkage => :dynamic

cd ios
pod install

The install output identifies the selected mode:

[react-native-firebase] RNFBApp: Using SPM for Firebase dependency resolution (products: FirebaseCore, FirebaseInstallations)

RNFB also adds an [RNFB] Embed Firebase SPM Frameworks build phase to the app
target. This phase embeds Firebase frameworks built by SPM that React Native's
pod-level SPM integration does not otherwise copy into the app bundle.

Release build and module-resolution settings Copy Section

RNFB automatically applies two build settings needed for SPM + dynamic
linkage, on every pod install/pod update:

• -ObjC in the app target's linker flags and on RNFB pod targets, so
  Release's dead-code stripping does not drop Firebase's
  FIRLibrary/FIRComponent registration or Measurement Objective-C
  categories statically absorbed into RNFBAnalytics.
• SWIFT_ENABLE_EXPLICIT_MODULES = 'NO' and CLANG_ENABLE_EXPLICIT_MODULES = 'NO' on both the app project and the Pods project, so Xcode 26's explicit
  Swift and Clang modules don't fail to resolve Firebase's internal-only SPM
  targets (FirebaseCoreInternal, FirebaseSharedSwift) or @imports of
  Firebase modules in your own Objective-C/Objective-C++ files. This does not
  disable SPM -- it makes Swift and Clang use implicit module discovery
  across the app, CocoaPods, and SPM build boundary.

You do not need to configure either of these yourself. If pod install warns
that they could not be applied automatically, or if Xcode still reports that a
Firebase module cannot be resolved, add the fallback in your existing
post_install block, after react_native_post_install:

post_install do |installer|
  react_native_post_install(
    installer,
    config[:reactNativePath],
    # your existing options
  )

  rnfirebase_apply_spm_build_settings(installer)
end

Framework-embedding fallback Copy Section

RNFB normally installs its SPM framework-embedding phase automatically after
CocoaPods has integrated [CP] Embed Pods Frameworks into the app target
(post_integrate). If pod install warns that automatic embedding could not
be configured, call the documented fallback from post_integrate:

post_integrate do |installer|
  rnfirebase_add_spm_embed_phase(installer)
end

Do not add the fallback unless the warning appears or the generated app target
does not contain [RNFB] Embed Firebase SPM Frameworks.

Sharing FirebaseCore with other native pods Copy Chapter

React Native attaches SPM products to each pod target via spm_dependency.
Because firebase-ios-sdk products are automatic libraries, each dynamic pod
framework that depends on Firebase embeds its own copy of FirebaseCore.
FirebaseApp.configure() in the app configures only the copy that target
links. Another pod's copy is never configured, so FirebaseApp.app() can
return nil there (and Auth can silently look signed-out even when RNFB JS
Auth has a user).

CocoaPods Firebase is no longer available for Firebase 13+. If a third-party
native module must share one configured FirebaseApp with RNFB, that module
must also resolve Firebase via SPM (same exact SDK version), not CocoaPods
trunk. Do not mix RNFB SPM with a third-party pod that still pulls Firebase
via CocoaPods — that is dual resolution and does not produce one shared
runtime.

Static pod linkage is not a sharing workaround under SPM: it fails at link
time with duplicate symbols (and pod install rejects the combination).

Troubleshooting Copy Chapter

• pod install fails with "Firebase Apple SDK is no longer distributed through CocoaPods":
  Remove $RNFirebaseDisableSPM = true and Expo ios.disableSPM. Use
  use_frameworks! :linkage => :dynamic and React Native 0.75+.
• pod install fails with "SPM + static linkage is not supported": Use
  dynamic linkage (use_frameworks! :linkage => :dynamic). A Podfile with no
  use_frameworks! line (or use_frameworks! false), the stock React Native /
  Expo default, is static linkage too.
  • With the stock template Podfile, USE_FRAMEWORKS=dynamic pod install also
    works, but it must be set for every pod install (including CI); the
    Podfile line is the durable fix.
  • Expo: set ios.useFrameworks to "dynamic" in the expo-build-properties
    plugin (see Expo projects), then re-run
    npx expo prebuild. Only if you maintain ios/ by hand (no prebuild), set
    "ios.useFrameworks": "dynamic" in ios/Podfile.properties.json instead.
• FirebaseApp.app() is nil / Auth looks signed-out inside another native
  pod, or runtime logs duplicate FIRApp classes: SPM mode cannot share one
  FirebaseCore across dynamic pod frameworks. See
  Sharing FirebaseCore with other native pods.
• Google Sign-In / App Check SPM resolve failures: See
  Google Sign-In caveat.
• FirebaseCoreInternal/FirebaseSharedSwift cannot be resolved, or a
  Release/Archive build crashes at launch with a missing Firebase symbol:
  RNFB applies -ObjC, SWIFT_ENABLE_EXPLICIT_MODULES = 'NO', and
  CLANG_ENABLE_EXPLICIT_MODULES = 'NO' automatically; call
  rnfirebase_apply_spm_build_settings(installer) as a fallback only if
  pod install warns it could not do so.
• A Firebase framework is missing at app launch: Re-run pod install, check
  for its automatic-embedding warning, and confirm the app target contains
  [RNFB] Embed Firebase SPM Frameworks. Use the fallback only when needed.
• spm_dependency is unavailable: Upgrade to React Native 0.75 or newer.
• SPM and CocoaPods both produce the same Firebase framework: Remove manually
  declared Firebase pods/packages so RNFB owns Firebase dependency resolution.
• Release archive fails with an xcframework-ios.signature "couldn't be
  copied ... because an item with the same name already exists" error: a
  long-standing Xcode Archive bug with SPM binary xcframeworks, not an RNFB
  regression. RNFB works around it automatically; if the warning says it could
  not do so, add a Run Script build phase to your app target that removes the
  colliding .signature file named in the error.

Migrating To V22 (`docs/migrating-to-v22.mdx`) Copy Section

title: Migrating to v22 previous: / next: /migrating-to-v23 Copy Chapter

Switching off warning logs

You may notice a lot of console warning logs as we deprecate the existing namespaced API. If you would like to switch these logs off, you may set the following global property to true anywhere before you initialize Firebase.

globalThis.RNFB_SILENCE_MODULAR_DEPRECATION_WARNINGS = true;

Enabling deprecation strict modes

You may enable a feature for the API migration which will throw a javascript error immediately when any namespaced API usage is detected.

This is useful to help you quickly locate any remaining usage of the deprecated namespace API via examination of the line numbers in the stack trace.

Note that there may be modular API implementation errors within the react-native-firebase modules, this may still be useful as a troubleshooting aid when collaborating with the maintainers to correct these errors.

globalThis.RNFB_MODULAR_DEPRECATION_STRICT_MODE = true;

Migrating to React Native modular API

If you are familiar with the Firebase JS SDK, the upgrade will be a familiar process, following similar steps to the migration guide for firebase-js-sdk.

React Native Firebase uses the same API as the official Firebase JS SDK modular API documentation so the same migration steps apply here, except there is no need for special "compat" imports as an intermediate step.

The process will always follow the same steps for every API you use:

• determine the new modular API function for the old namespaced API you are using
• import that new modular API function
• change the call from using the firebase module to access the API and passing parameters, to the new style of using the modular API function, passing in the firebase module object(s) required for it to work and then the parameters.

In the end, it should be a very mechanical process and can be done incrementally, one API call at a time.

There are concrete examples below to show the process

Firestore Deprecation Example Copy Chapter

Namespaced (deprecated) Query Copy Section

You ought to move away from the following way of making Firestore queries. The React Native Firebase namespaced API is being completely removed in React Native Firebase v22:

import firestore from '@react-native-firebase/firestore';

const db = firestore();

const querySnapshot = await db.collection('cities').where('capital', '==', true).get();

querySnapshot.forEach(doc => {
  console.log(doc.id, ' => ', doc.data());
});

Modular Query Copy Section

This is how the same query would look using the new, React Native Firebase modular API:

import { collection, query, where, getDocs, getFirestore } from '@react-native-firebase/firestore';

const db = getFirestore();

const q = query(collection(db, 'cities'), where('capital', '==', true));

const querySnapshot = await getDocs(q);

querySnapshot.forEach(doc => {
  console.log(doc.id, ' => ', doc.data());
});

For more examples of requesting Firestore data, see the official Firebase documentation for Get data with Cloud Firestore.

Migration Help Copy Section

You will find code snippets for "Web namespaced API" and "Web modular API" throughout the official Firebase documentation. Update your code to use "Web modular API". Here are some links to help you get started:

• Firestore
• Auth
• RTDB
• Storage
• Remote Config
• Messaging
• Functions
• App Check
• Analytics
• Perf
• Crashlytics (Crashlytics doesn't exist on Firebase web, this is a link to the type declarations which contains all methods available).

Migrating To V23 (`docs/migrating-to-v23.mdx`) Copy Section

title: Migrating to v23 previous: /migrating-to-v22 next: /migrating-to-v24 Copy Chapter

Firebase Crashlytics

Modular API method isCrashlyticsCollectionEnabled(crashlytics) has been removed, please use the property on Crashlytics instance
getCrashlytics().isCrashlyticsCollectionEnabled instead.

Firebase Auth

MultiFactorUser.enrolledFactor has been removed, please use MultiFactorUser.enrolledFactors. See example:

const credential = await signInWithEmailAndPassword(getAuth(), '[email protected]', 'password');
const multiFactorUser = credential.user.multiFactor;
// Use below - remove any instances of `multiFactorUser.enrolledFactor`
console.log(multiFactorUser.enrolledFactors);

Firebase App

• gaMeasurementId property from FirebaseOptions has been replaced with measurementId to match Firebase web JS SDK.

Firebase Dynamic Links

⚠️ REMOVED ⚠️

Firebase Dynamic Links has been Removed

This package has been deprecated and removed from the React Native Firebase repository.

Why was it deprecated? Copy Chapter

Firebase Dynamic Links has been deprecated by Google and will be shut down on August 25th, 2025. For more information about the deprecation and migration options, please visit:

Firebase Dynamic Links Deprecation FAQ

Migration Options Copy Chapter

The deprecation FAQ provides detailed guidance on how to migrate from Firebase Dynamic Links, including:

• Full feature parity: Use alternative deep-linking service providers
• Simple deep-linking: Migrate to App Links and Universal Links. See Firebase documentation.
• No replacement needed: Remove the package entirely

Timeline Copy Chapter

• August 25th, 2025: Firebase Dynamic Links service will be completely shut down
• All existing links will stop working
• All APIs will return error responses

Please refer to the official deprecation FAQ for complete migration guidance and support.

Android Platform

• Android minSdk has been bumped from 21 to 23 (except Auth which already had a minSdk of 23).
• Auth play services has been bumped from 21.3.0 to 21.4.0.
• Crashlytics gradle plugin has been bumped from 3.0.4 to 3.0.5.
• Performance gradle plugin has been bumped from 1.4.2 to 2.0.0.
• App distribution gradle plugin has been bumped from 5.1.0 to 5.1.1.

iOS platform

• Minimum iOS deployment target has now been bumped to 15 from 13.
• Minimum Xcode version required for iOS development is now Xcode 16.2, previous was Xcode 15.2.
• gaMeasurementId property from FirebaseOptions (now measurementId in React Native Firebase) has been removed from firebase-ios-sdk as it wasn't used.

Web platform

• Firebase JS SDK has been bumped to 12.0.0 which now requires a minimum of Node.js 20 and a minimum of ES2020.
  See release notes.

Migrating To V24 (`docs/migrating-to-v24.mdx`) Copy Section

title: Migrating to v24 previous: /migrating-to-v23 next: /migrating-to-v25 Copy Chapter

Version 24 includes breaking changes for Firestore TypeScript types and Cloud Functions native integration. Review the sections below for the modules you use.

Firestore

Version 24 introduces withConverter functionality from Firebase JS SDK. Due to the differences in types between references and queries in namespace vs modular API, and the namespaced APIs deprecation cycle being effectively complete with the API set for removal, we have adopted the modular API typing in general for firestore APIs.

Reference and query types have been updated to support input of two generic types (AppModelType, DbModelType).

Additionally, to match the JS SDK, they are now exported separately at the root, instead of through FirebaseFirestoreTypes.

Most commonly these types will be affected: CollectionReference, DocumentReference, DocumentSnapshot, QueryDocumentSnapshot, QuerySnapshot, Query.

// Previously
import { doc, getFirestore, onSnapshot, FirebaseFirestoreTypes } from '@react-native-firebase/firestore';

onSnapshot(doc(getFirestore(), 'foo', 'foo'), {
  next: (snapshot: FirebaseFirestoreTypes.DocumentSnapshot) => {
    console.log(snapshot.get('foo'));
  },
});

// Now
import { doc, getFirestore, onSnapshot, DocumentSnapshot } from '@react-native-firebase/firestore';

onSnapshot(doc(getFirestore(), 'foo', 'foo'), {
  next: (snapshot: DocumentSnapshot) => {
    console.log(snapshot.get('foo'));
  },
});

Cloud Functions

PR: #8603 / v24.0.0 (#8799 streaming callables)

From v24 onward, @react-native-firebase/functions is implemented as a TurboModule and requires React Native's New Architecture. The legacy bridge module was removed.

Who is affected Copy Chapter

Enable New Architecture Copy Chapter

React Native CLI (Android) — set in android/gradle.properties:

newArchEnabled=true

React Native CLI (iOS) — New Architecture is enabled when RCT_NEW_ARCH_ENABLED=1 during pod install (React Native sets this from newArchEnabled on recent templates). Follow the React Native New Architecture guide for your RN version.

Expo — enable in your app config (Expo SDK 52+):

{
  "expo": {
    "newArchEnabled": true
  }
}

Rebuild native projects after changing this (pod install, clean Android build).

If New Architecture is disabled Copy Chapter

• Android: the Functions Gradle script fails the build with New Architecture support is required for @react-native-firebase/functions.
• iOS: pod install fails with RNFBFunctions requires New Architecture. Enable New Architecture to use this module.

API notes Copy Chapter

The JavaScript API (functions(), httpsCallable, modular helpers) is unchanged. v24 also adds httpsCallable().stream() support, which relies on the TurboModule implementation.

Other React Native Firebase modules still run on legacy architecture in v24, but old architecture support is deprecated project-wide and will be required for additional modules in future releases.

Migrating To V25 (`docs/migrating-to-v25.mdx`) Copy Section

title: Migrating to v25 previous: /migrating-to-v24 next: /migrating-to-v26 Copy Chapter

Version 25 completes the TypeScript alignment started in v24. Modular types across multiple packages now match the firebase-js-sdk modular API as closely as possible. Runtime behavior is largely unchanged; TypeScript consumers and apps using the modular API are most affected.

If you upgraded to v24 for Firestore only, see Migrating to v24 first — Firestore breaking changes remain in v24.

Table of contents Copy Chapter

• Why we made these changes
• Agent-assisted migration
• Who is affected
• General pattern
• Tooling & native SDKs
• Cloud Storage
• Realtime Database
• Remote Config
• Performance Monitoring
• Installations
• App Check
• Firebase Auth
• Cloud Messaging
• Automated migration checklist

Why we made these changes Copy Chapter

React Native Firebase aims to be a drop-in replacement for the firebase-js-sdk — with native extensions and performance where the platform allows. At the JavaScript level we have always tracked the modular API closely, but our TypeScript declarations had diverged: namespaces specific to React Native Firebase, instance-style typings, and helper names that did not match the SDK.

v25 finishes aligning those types module by module. For you as a developer that means:

• Shared mental model — code, examples, and AI assistance written for firebase-js-sdk modular APIs map directly to React Native Firebase.
• Safer refactors — TypeScript catches incorrect imports and call shapes at compile time instead of at runtime.
• Easier cross-platform work — the same typed modular surface works across web, React Native, and shared business logic.
• A clear path forward — namespaced APIs remain for compatibility but modular root exports are the supported, typed source of truth.

Most apps behave the same after updating package versions; the work is primarily import and type adjustments where TypeScript reports errors.

Agent-assisted migration Copy Chapter

This guide is written to be complete enough for an automated first pass. We recommend feeding this document to your coding agent, then asking it to analyze your codebase against each relevant section below and produce a concrete change list (or PR) for the packages you use. The Automated migration checklist at the end is structured for that workflow.

Who is affected Copy Chapter

General pattern Copy Chapter

Across v25 package migrations:

1. Import modular types and functions from the package root, not from Firebase*Types namespaces.
2. Prefer free functions (getToken(appCheck), trace(perf, name)) over instance methods on service objects.
3. Firebase*Types namespaces remain for namespaced compatibility but are deprecated for new code.
4. Namespaced APIs (firebase.auth(), storage()) still work; modular is the typed source of truth.

Tooling & native SDKs

Commit: c8c1fc105 (SDK bump)

Cloud Storage

PR: #8824

Modular Storage types now match firebase-js-sdk. The namespaced API (firebase.storage(), FirebaseStorageTypes) is preserved separately and deprecated for new code.

Type & export changes Copy Chapter

Example: modular references and uploads Copy Chapter

// Previously
import { getStorage, refFromURL, child } from '@react-native-firebase/storage';

const storage = getStorage();
const fileRef = child(refFromURL(storage, 'gs://bucket/path/file.jpg'), 'thumb.jpg');
await fileRef.putFile(localPath);

// Now
import { getStorage, ref, putFile } from '@react-native-firebase/storage';

const storage = getStorage();
const fileRef = ref(ref(storage, 'gs://bucket/path/file.jpg'), 'thumb.jpg');
await putFile(fileRef, localPath);

Example: types and task constants Copy Chapter

// Previously
import { getStorage, FirebaseStorageTypes } from '@react-native-firebase/storage';

function onState(snapshot: FirebaseStorageTypes.TaskSnapshot) {
  if (snapshot.state === getStorage().app.storage().constructor.TaskState.RUNNING) { /* … */ }
}

// Now
import { getStorage, ref, uploadBytesResumable, TaskState, type TaskSnapshot } from '@react-native-firebase/storage';

function onState(snapshot: TaskSnapshot) {
  if (snapshot.state === TaskState.RUNNING) { /* … */ }
}

RN-only helpers (putFile, writeToFile) remain exported from the package root for native file paths.

Realtime Database

PR: #8977

Modular RTDB types (DatabaseReference, Query, DataSnapshot, OnDisconnect, QueryConstraint) no longer expose namespaced instance-style methods in public typings. Use function-based modular helpers.

Breaking changes Copy Chapter

Example: server timestamps Copy Chapter

// Previously
import { getDatabase, ref, set, ServerValue } from '@react-native-firebase/database';

await set(ref(getDatabase(), 'posts/1'), { createdAt: ServerValue.TIMESTAMP });

// Now
import { getDatabase, ref, set, serverTimestamp } from '@react-native-firebase/database';

await set(ref(getDatabase(), 'posts/1'), { createdAt: serverTimestamp() });

Example: modular query helpers Copy Chapter

// Previously — instance methods typed on modular references
import {
  getDatabase,
  ref,
  query,
  orderByChild,
  equalTo,
  onValue,
} from '@react-native-firebase/database';

const db = getDatabase();
const scoresRef = ref(db, 'scores');
const q = query(scoresRef, orderByChild('score'), equalTo(100));
onValue(q, snapshot => {
  /* … */
});

Function-based helpers (query, orderByChild, onValue, etc.) are unchanged at runtime; TypeScript may now require you to stop calling deprecated instance methods (.orderByChild(), .on()) on modular-typed references and use the modular functions instead.

Namespaced firebase.database.ServerValue remains available.

Remote Config

PR: #8972

Modular Remote Config now uses firebase-js-sdk type names and instance properties.

Removed / renamed modular API Copy Chapter

Settings field rename: modular RemoteConfigSettings uses fetchTimeoutMillis (firebase-js-sdk), not the older React Native Firebase style fetchTimeMillis on the modular surface.

Example: fetch and read values Copy Chapter

// Previously
import {
  getRemoteConfig,
  fetch,
  activate,
  getValue,
  FirebaseRemoteConfigTypes,
} from '@react-native-firebase/remote-config';

const rc = getRemoteConfig();
await fetch(rc, 3600);
await activate(rc);
const flag = getValue(rc, 'feature_enabled');
console.log(flag.value, flag.source);

// Now
import {
  getRemoteConfig,
  fetchConfig,
  activate,
  getValue,
  type Value,
} from '@react-native-firebase/remote-config';

const rc = getRemoteConfig();
rc.settings = {
  minimumFetchIntervalMillis: 3600000,
  fetchTimeoutMillis: 60000,
};
await fetchConfig(rc);
await activate(rc);
const flag: Value = getValue(rc, 'feature_enabled');
console.log(flag.asString(), flag.getSource());

Performance Monitoring

PR: 4aedfe883 (TypeScript migration)

Breaking changes Copy Chapter

RN-only exports retained: httpMetric, newScreenTrace, startScreenTrace, HttpMethod, HttpMetric, ScreenTrace.

Example Copy Chapter

// Previously
import { getPerformance } from '@react-native-firebase/perf';

const perf = getPerformance();
const t = perf.newTrace('load_screen');
await t.start();

// Now
import { getPerformance, trace } from '@react-native-firebase/perf';

const perf = getPerformance();
const t = trace(perf, 'load_screen');
await t.start();

Installations

PR: 739a4ca36 (TypeScript migration)

Modular getInstallations() returns a firebase-js-sdk-shaped Installations object exposing only app. Use modular helper functions instead of instance methods.

Breaking changes Copy Chapter

Example Copy Chapter

// Previously
import { getInstallations } from '@react-native-firebase/installations';

const installations = getInstallations();
const id = await installations.getId();

// Now
import { getInstallations, getId } from '@react-native-firebase/installations';

const installations = getInstallations();
const id = await getId(installations);

Namespaced firebase.installations() / FirebaseInstallationsTypes remain available (deprecated).

App Check

PR: #8889

Version 25 aligns App Check's modular exports more closely with the Firebase JS SDK. If your app uses the modular API, import App Check types and helpers directly from @react-native-firebase/app-check instead of routing modular code through FirebaseAppCheckTypes.

The most common updates are:

• Import modular helpers such as initializeAppCheck, getToken, getLimitedUseToken, setTokenAutoRefreshEnabled, and onTokenChanged from the package root.
• Import modular types such as AppCheck and AppCheckTokenResult from the package root.
• FirebaseApp is no longer exported from @react-native-firebase/app-check; import it from @react-native-firebase/app.
• FirebaseAppCheckTypes is type-only — use import type { FirebaseAppCheckTypes }.
• Modular AppCheck has no instance methods (matching firebase-js-sdk); use free functions.
• onTokenChanged callback receives AppCheckTokenResult, not AppCheckListenerResult.
• Keep using ReactNativeFirebaseAppCheckProvider on React Native when you need native provider selection for Android / Apple / web.

// Previously
import appCheck, { FirebaseAppCheckTypes } from '@react-native-firebase/app-check';

const instance = appCheck();

instance.getToken().then((result: FirebaseAppCheckTypes.AppCheckTokenResult) => {
  console.log(result.token);
});

// Now
import { getApp } from '@react-native-firebase/app';
import {
  AppCheckTokenResult,
  ReactNativeFirebaseAppCheckProvider,
  initializeAppCheck,
  getToken,
} from '@react-native-firebase/app-check';

const provider = new ReactNativeFirebaseAppCheckProvider();

provider.configure({
  android: {
    provider: __DEV__ ? 'debug' : 'playIntegrity',
  },
  apple: {
    provider: __DEV__ ? 'debug' : 'appAttestWithDeviceCheckFallback',
  },
  web: {
    provider: 'reCaptchaV3',
    siteKey: 'your-recaptcha-site-key',
  },
});

const appCheck = await initializeAppCheck(getApp(), {
  provider,
  isTokenAutoRefreshEnabled: true,
});

const result: AppCheckTokenResult = await getToken(appCheck);
console.log(result.token);

If you do not need to reuse a provider instance, you can now also pass the React Native provider configuration inline through providerOptions:

import { getApp } from '@react-native-firebase/app';
import { initializeAppCheck } from '@react-native-firebase/app-check';

await initializeAppCheck(getApp(), {
  provider: {
    providerOptions: {
      android: {
        provider: __DEV__ ? 'debug' : 'playIntegrity',
      },
      apple: {
        provider: __DEV__ ? 'debug' : 'appAttestWithDeviceCheckFallback',
      },
      web: {
        provider: 'reCaptchaV3',
        siteKey: 'your-recaptcha-site-key',
      },
    },
  },
  isTokenAutoRefreshEnabled: true,
});

Firebase Auth

PR: #8991

Version 25 aligns @react-native-firebase/auth TypeScript types with the firebase-js-sdk modular API. Runtime behavior is largely unchanged, but TypeScript consumers should review the following breaking changes.

For maintainers and coding agents: the living triage matrix is okf-bundle/packages/auth/compare-types-triage.md. Run yarn compare:types auth after public API edits and update .github/scripts/compare-types/configs/auth.ts when differences are intentional.

Platform matrix (read before changing Auth) Copy Chapter

When a symbol is documented as iOS/Android only, do not assume it throws or is missing on Other without checking the web bridge. When compare:types signatures match but runtime differs, document in triage / this guide (not necessarily in differentShape).

Modular types Copy Chapter

Import modular types directly from @react-native-firebase/auth instead of FirebaseAuthTypes where possible. The namespaced FirebaseAuthTypes namespace remains available but is deprecated.

For auth errors, use NativeFirebaseAuthError (or the modular AuthError interface) instead of expecting a firebase-js-sdk AuthError class export — React Native Firebase does not re-export the firebase-js-sdk error class.

Removed modular export Copy Chapter

• initializeRecaptchaConfig is not exported. React Native Firebase uses native SDK Phone Auth verification rather than the browser reCAPTCHA bootstrap flow.

Deprecated provider helpers Copy Chapter

The following RN Firebase-specific provider classes are deprecated in v25. Use OAuthProvider instead (matching firebase-js-sdk):

// Previously (deprecated)
import { AppleAuthProvider } from '@react-native-firebase/auth';
const credential = AppleAuthProvider.credential(idToken, rawNonce);

// Now
import { OAuthProvider } from '@react-native-firebase/auth';
const provider = new OAuthProvider('apple.com');
const credential = provider.credential({ idToken, rawNonce });

// Previously (deprecated)
import { OIDCAuthProvider } from '@react-native-firebase/auth';
const credential = OIDCAuthProvider.credential('sample-provider', idToken, accessToken);

// Now
import { OAuthProvider } from '@react-native-firebase/auth';
const provider = new OAuthProvider('oidc.sample-provider');
const credential = provider.credential({ idToken, accessToken });

AppleAuthProvider and OIDCAuthProvider remain exported for compatibility but will be removed in a future major release.

Action code URL parsing Copy Chapter

ActionCodeURL.parseLink and parseActionCodeURL are implemented as synchronous pure URL parsers (matching firebase-js-sdk). They work on all platforms without calling the native bridge.

Signature changes Copy Chapter

• isSignInWithEmailLink(auth, emailLink) — returns Promise on iOS/Android (native bridge). The firebase-js-sdk returns a synchronous boolean. Port web code with await isSignInWithEmailLink(auth, link) (or .then(...)).
• sendSignInLinkToEmail(auth, email, actionCodeSettings) — actionCodeSettings is required in the modular API (matching firebase-js-sdk).
• Namespaced email link (react-native-firebase convenience): firebase.auth().sendSignInLinkToEmail(email, settings?) still accepts omitted settings. Internally _resolveActionCodeSettings() defaults url from app.options.authDomain and handleCodeInApp: true. This is not platform-specific — only namespaced vs modular. Do not “fix” modular to match namespaced defaults.
• signInWithEmailLink(auth, email, emailLink?) — the third argument is optional, matching firebase-js-sdk.
• signInWithRedirect / linkWithRedirect — return Promise on native because provider flows resolve immediately with credentials instead of following the browser redirect contract.
• reauthenticateWithRedirect — returns Promise<void> on native while still updating currentUser after the native provider flow completes.
• connectAuthEmulator(auth, url, options?) — when options is provided, disableWarnings is required (matching firebase-js-sdk).

Web APIs with matching types but different native runtime (iOS/Android) Copy Chapter

These modular helpers are exported for firebase-js-sdk API parity. On iOS/Android they throw synchronously (or are not applicable) because native SDKs do not implement the browser persistence, redirect, or reCAPTCHA phone-link flows. Types match the firebase-js-sdk; behavior does not — see API reference @remarks on each symbol.

initializeAuth(app, deps?) accepts the firebase-js-sdk Dependencies type for API parity but ignores persistence, popup redirect resolver, and error-map dependencies on iOS/Android (see below).

Phone Auth (iOS/Android) Copy Chapter

• verifyPhoneNumber(auth, phoneNumber, ...) — iOS/Android only native listener flow (force-resend, auto-verification callbacks). On Other platforms use signInWithPhoneNumber / firebase-js-sdk PhoneAuthProvider instead.
• signInWithPhoneNumber(auth, phoneNumber, appVerifier?) — modular API no longer accepts the former forceResend fourth argument from React Native Firebase; use verifyPhoneNumber when you need the native listener / force-resend behavior.

Sign in with Apple Copy Chapter

• revokeToken(auth, authorizationCode) — React Native Firebase-specific modular helper for Apple's account-deletion requirement. Supported on iOS (native revokeTokenWithAuthorizationCode). Android and Web bridges resolve without performing revocation.
• Do not confuse with revokeAccessToken — that is firebase-js-sdk web-only OAuth token revocation and always throws on iOS/Android.
• The namespaced firebase.auth().revokeToken(authorizationCode) API remains available but is deprecated.

Auth instance surface Copy Chapter

• auth.tenantId = 'tenant-id' is now supported (delegates to setTenantId).
• auth.authStateReady(), auth.beforeAuthStateChanged(...), auth.emulatorConfig, and auth.updateCurrentUser(user) are implemented on the Auth instance.
• auth.config runtime split (types unified): Declarations match firebase-js-sdk Config, but runtime differs by platform:
  • iOS/Android: always {} — native SDKs do not expose the web config object.
  • Other (Hermes/Web): firebase-js-sdk can populate auth.config, but React Native Firebase does not delegate this yet. Do not read auth.config on native expecting apiKey / authDomain; use getCustomAuthDomain(auth) on iOS/Android or app options on Other until delegation lands.

Credential providers Copy Chapter

Provider credential factories return firebase-js-sdk-shaped credential classes (OAuthCredential, not internal type aliases) with toJSON() and static fromJSON() where applicable.

• OAuthCredential.rawNonce — used for Sign in with Apple and Facebook limited-login flows (matches firebase-js-sdk credential options). OAuth 1.0 token secrets (e.g. Twitter) use the inherited AuthCredential.secret bridge field instead of rawNonce.

• RN Firebase credentials retain internal token / secret bridge fields required by the native modules (implementation detail; omitted from generated API reference).

• OAuthProvider.credentialFromResult / credentialFromError and sibling provider helpers (GoogleAuthProvider, GithubAuthProvider, TwitterAuthProvider, FacebookAuthProvider, PhoneAuthProvider) always return null at runtime today. Declared types match firebase-js-sdk.

  • iOS/Android: no native extraction planned — credentials are not recoverable from native provider results.
  • Other/Hermes: not delegated (firebase-js-sdk credential recovery is tied to popup/redirect flows).
  • Other/Web: future implementation should delegate to firebase-js-sdk in the auth web bridge — do not invest in native iOS/Android bridge work for this.

• GoogleAuthProvider.credential() throws when both idToken and accessToken are absent (matching firebase-js-sdk).

• FacebookAuthProvider.credential(token) matches firebase-js-sdk. React Native Firebase also exports credential(token, secret) for Facebook limited-login nonce behavior — an intentional extension documented in compare:types.

Multi-factor Copy Chapter

• Modular multiFactor(user) now uses the user's auth instance instead of always calling getAuth(), fixing secondary Firebase app usage.
• Namespaced firebase.auth().multiFactor(user) now correctly validates that user is the currentUser.
• TotpSecret.generateQrCodeUrl() returns Promise<string> on iOS/Android (native bridge). firebase-js-sdk returns a synchronous string.
• TotpSecret.openInOtpApp(qrCodeUrl) — RN-only helper that deep-links into a One-Time Password authenticator app; not part of firebase-js-sdk.
• Other platforms: MFA and TOTP flows are exercised in tests/local-tests via the firebase-js-sdk bridge — not a gap to “port” from native overloads.

Normalized modular return values Copy Chapter

Modular helpers normalize several return shapes toward firebase-js-sdk:

• UserCredential includes top-level providerId and operationType.
• When the native bridge returns federated metadata, additionalUserInfo is attached as an enumerable property on modular UserCredential objects. Core fields match firebase-js-sdk (isNewUser, profile, providerId, username); extra native keys are copied onto the object for backwards compatibility.
• Use getAdditionalUserInfo(userCredential) for the canonical read (returns AdditionalUserInfo | null, same shape as firebase-js-sdk). For TypeScript when you need provider-specific native extras, cast to AdditionalUserInfoNative (AdditionalUserInfo & Record<string, unknown>).
• checkActionCode normalizes fromEmail to previousEmail and coerces multi-factor info shapes.
• signInWithPhoneNumber wraps confirmation results and validates verificationId presence.

`initializeAuth` Copy Chapter

initializeAuth(app, deps?) accepts the firebase-js-sdk Dependencies type for API parity, but persistence, popup redirect resolver, and error-map dependencies are ignored because native SDKs manage auth state.

Namespaced type adjustments Copy Chapter

• FirebaseAuthTypes.UserInfo profile fields can be null.
• firebase.auth().config is typed as Record<string, never> on the namespaced API (stricter than modular auth.config).

Cloud Messaging

PR: #9053

Notification permission APIs in @react-native-firebase/messaging are deprecated in v25. They are not Firebase-specific; dedicated libraries handle permissions more completely.

These APIs still work at runtime but are marked @deprecated in TypeScript and documented for removal in a future major release. See #6283.

Automated migration checklist

Use this section when running scripted or agent-assisted upgrades from v24 → v25.

1. Upgrade dependencies Copy Chapter

# Bump all @react-native-firebase/* packages to v25 together (monorepo versions are aligned)
yarn add @react-native-firebase/app@^25.0.0 …
cd ios && pod install

Ensure Xcode 26.2+ for iOS builds.

2. Fix TypeScript by package Copy Chapter

For each @react-native-firebase/ in your imports:

3. Validate Copy Chapter

yarn compile          # root TypeScript compile
yarn compare:types    # maintainers: per-package drift vs firebase-js-sdk
yarn tests:jest packages/<pkg>/__tests__   # targeted tests for touched packages

4. Namespaced API users Copy Chapter

If you only use firebase.storage(), firebase.auth(), etc. and do not import modular types:

• You may see deprecation warnings in IDE / @deprecated JSDoc.
• Plan a gradual move to modular imports; namespaced removal is planned for a future major release.
• Runtime behavior should remain compatible for most flows.

Related PRs (v25 breaking changes since v24.0.0) Copy Chapter

Packages migrated to TypeScript without public API breaks in v25: @react-native-firebase/app-distribution (#8967), @react-native-firebase/ml (#9005).

Migrating To V26 (`docs/migrating-to-v26.mdx`) Copy Section

title: Migrating to v26 previous: /migrating-to-v25 next: /migrating-to-v27 Copy Chapter

Version 26 removes the deprecated namespaced JavaScript API from selected packages. Each migrated package is modular-only: use getX(app?) and root-level helper functions from the package entry point. Namespaced default exports, firebase.<module>(), and Firebase*Types namespaces are removed from those packages.

If you are upgrading from v24 or earlier, complete Migrating to v25 first — v25 TypeScript alignment changes still apply.

Table of contents Copy Chapter

• New Architecture requirement
• Platform behavior differences
• firebase-js-sdk API parity improvements
• General pattern
• App
• Machine Learning (ML)
• In-App Messaging
• Installations
• Cloud Messaging
  • iOS APNs registration (ARM64 Simulator + new Promise rejections)
• App Distribution
• Cloud Functions
• Performance Monitoring
• App Check
• Analytics
• Remote Config
• Crashlytics
• Realtime Database
• Cloud Storage
• Authentication
• Cloud Firestore
• Automated migration checklist

New Architecture requirement Copy Chapter

From v26 onward, every React Native Firebase package with a native bridge is implemented as a Codegen TurboModule and requires React Native's New Architecture. The legacy bridge modules were removed in the coordinated v26 break.

If you cannot enable New Architecture yet, stay on v25 (or v23 if you still depend on legacy-architecture Cloud Functions — see below).

Exceptions (no New Architecture requirement) Copy Section

Cloud Functions (already required since v24) Copy Section

@react-native-firebase/functions has required New Architecture since v24 (Migrating to v24 — Cloud Functions). v26 extends the same requirement to all remaining native modules.

Enable New Architecture Copy Section

React Native CLI (Android) — set in android/gradle.properties:

newArchEnabled=true

React Native CLI (iOS) — New Architecture is enabled when RCT_NEW_ARCH_ENABLED=1 during pod install (React Native sets this from newArchEnabled on recent templates). Follow the React Native New Architecture guide for your RN version.

Expo — enable in your app config (Expo SDK 52+):

{
  "expo": {
    "newArchEnabled": true
  }
}

Rebuild native projects after changing this (pod install, clean Android build).

If New Architecture is disabled Copy Section

Native builds fail early with explicit guards:

• Android: Gradle scripts print New Architecture support is required for @react-native-firebase/ and fail the build.
• iOS: pod install fails with requires New Architecture. Enable New Architecture to use this module.

Platform behavior differences Copy Section

When migrating from firebase-js-sdk web examples, watch for these high-impact runtime divergences:

{/* prettier-ignore */}

Per-package notes also appear in each module's usage page under Platform support.

firebase-js-sdk API parity improvements Copy Chapter

v26 aligns React Native Firebase modular types and several runtime signatures with firebase-js-sdk where TurboModules removed bridge-forced Promise wrappers. Use this section when porting web SDK examples or when scripted upgrades hit TypeScript or runtime errors.

Migration rule: If a method below is sync, remove await and any .then() / .catch() chain on its return value — sync APIs return void or a value directly; calling .then() on void throws at runtime.

Synchronous APIs enabled by TurboModules Copy Section

{/* prettier-ignore */}