React Native Firebase: a native-SDK layer over the Firebase Web SDK

The gap React Native Firebase fills between the Web SDK and native Firebase

The Firebase Web SDK is JavaScript. It runs in a JavaScript engine, and on mobile that means it runs without direct access to the platform SDKs that handle device-level concerns. Push notification delivery, crash reporting, and analytics collection on iOS and Android are handled by the native Firebase SDKs, not by the JavaScript implementation. React Native Firebase exists to sit on top of those native SDKs and expose them through an API that matches the Web SDK, so code written against the Web SDK shape can run in a React Native app.

The project is a monorepo. The README describes it as "a collection of official React Native modules connecting you to Firebase services", with each module acting as "a light-weight JavaScript layer connecting you to the native Firebase SDKs for both iOS and Android". The package you interface with first is App, published as @react-native-firebase/app. Everything else is opt-in per service: analytics, auth, firestore, messaging, storage, crashlytics, functions, remote config, app check, app distribution, in-app messaging, installations, and others listed in the README's module table.

That per-service split is the central design decision. It means your dependency list grows with the number of Firebase products you use, and it means you can ship a build that includes only the native code for the services you actually call. The README frames the four principles as well tested (modules tested to >95% coverage, per the project's own claim), well typed (first class TypeScript support), well documented, and mirroring the Firebase Web SDK as a drop-in replacement that maximizes cross-platform code reuse.

How the JavaScript layer, native SDKs and monorepo fit together

There are three layers. At the top is the JavaScript API you import in your app, shaped to match the Firebase Web SDK. In the middle is the per-package JavaScript module, which is the light wrapper the README describes. At the bottom are the native Firebase SDKs for iOS and Android, which the module connects to.

The repository layout reflects that split. The packages/ directory holds one directory per service, each with its own android/ and ios/ subtrees. The root package.json is marked "private": true and is not the thing you publish or install; it is the workspace root, with scripts that fan out across packages through Lerna and Nx. There are codegen scripts (codegen:all, codegen:verify) that generate native-side files and then check that the generated output matches what is committed, and the lint pipeline runs JavaScript, dependency, Android and iOS checks separately.

For an adopter, the practical consequence is that the JavaScript API is only half the story. The native side has to be configured, built and linked, which is why the installation instructions live per package and per platform rather than in a single npm install line. The repository also carries test-rn-bare/, test-expo/ and tests-macos/ directories, which indicates the project maintains test applications for bare React Native, Expo and macOS targets rather than assuming a single environment.

Installing React Native Firebase and wiring up your first module

The README points to the documentation site at rnfirebase.io for full reference and installation documentation, and states that the main package you interface with is App, published as @react-native-firebase/app. The install flow starts there: the App package is the foundation, and service packages are added on top of it.

Install the App package with your package manager of choice. The README does not pin a version in the install example, so take the current published version from npm rather than copying a number from an article.

yarn add @react-native-firebase/app

Then add the service package you need. For example, the messaging module is published as @react-native-firebase/messaging, and the README's module table lists it alongside analytics, auth, firestore and the rest.

yarn add @react-native-firebase/messaging

Adding the package is not the end of the setup. Because each module wraps the native SDK, the iOS and Android projects need the corresponding native configuration, and the documentation site is where those per-platform steps are written down. The README itself does not reproduce them. Treat the npm add as step one of a two-part install, and follow the platform guide for your service before expecting anything to run on a device.

Once configured, the API shape is the point. The README states the project "functions as a drop-in replacement for the Firebase Web SDK in React Native", so imports and call patterns follow the Web SDK rather than a bespoke React Native API.

Where React Native Firebase is the wrong choice

The clearest boundary is managed Expo. The repository contains a test-expo/ directory, which shows Expo is a supported target in the project's own testing, but the README does not document the Expo setup steps, and the native-SDK dependency means Expo Go cannot carry the native modules. Getting React Native Firebase into an Expo app involves the native build path, not just a JavaScript install. If your team's reason for choosing Expo is to avoid touching native projects, this library works against that reason.

The second boundary is scope. Each Firebase service is a separate package with its own native configuration. If you only need Firestore reads and writes and nothing device-level, the Web SDK may be sufficient and simpler, because it does not require native configuration at all. The trade-off React Native Firebase buys you is native behaviour; if you do not need native behaviour, you are paying the configuration cost for nothing.

The third boundary is maintenance surface. The monorepo carries Lerna, Nx, codegen verification, dependency-cruiser rules and separate Android and iOS lint pipelines. That is a lot of machinery, and it exists because the project tracks two native SDKs across many services. When a native SDK changes, the wrapper has to follow. The last push to the repository was on 2026-09-21, and the most recent releases listed are v24.1.1, v24.1.0 and v24.0.0, all dated 2026-06-10. The gap between the latest release and the latest push is worth noting if you depend on a fix that landed after the June release, because it will not be in a published version yet.

React Native Firebase compared with the Firebase Web SDK and Supabase

Against the Firebase Web SDK, the difference is architectural rather than cosmetic. The Web SDK is pure JavaScript and needs no native project changes. React Native Firebase wraps the native SDKs, so it needs them, and in return it can reach services that depend on platform code, such as messaging and Crashlytics. The README describes the JavaScript API as mirroring the Web SDK, which is what makes the two comparable at the call site even though they differ underneath. If your app is web plus React Native and you want shared code, that mirroring is the reason the project exists.

Against Supabase, the difference is the backend model, not the client. Supabase is a hosted Postgres-based platform; Firebase is Google's service suite. Choosing between them is a backend decision you make before you pick a client library, and React Native Firebase only enters the picture after you have chosen Firebase. It is not a drop-in substitute for a Supabase client, because the services underneath are different products with different data models and different authentication systems.

A more useful comparison is React Native Firebase against the Firebase JavaScript SDK installed directly in a React Native project. Both give you JavaScript imports. Only one gives you the native SDKs. If your feature list includes push notifications delivered through the native Firebase SDK, crash reports from native crashes, or analytics collected natively, the JavaScript-only path will not cover it, and that is the specific gap this project fills.

Licence status and what upgrading costs you

The repository's licence field reports NOASSERTION rather than a recognized SPDX identifier, even though the README badge links to a LICENSE file at the repository root and the npm package carries a license badge. NOASSERTION means the tooling could not map the licence text to a standard identifier. Read the LICENSE file itself and, if the terms matter to your organisation, have someone qualified review them. Nothing here is legal advice, and the licence field alone is not enough to decide.

Upgrade cost follows from the per-package design. Because each service is its own npm package with its own native code, a major version bump is not a single dependency change. The recent releases are all on the 24.x line, with v24.0.0 as the major and v24.1.0 and v24.1.1 as follow-ups on the same day. The repository has a CHANGELOG.md at the root and a scripts/version.js wired into the version script, so the changelog is the place to check what a major bump changes before you move.

The native side is where upgrades get expensive. If a release changes generated native files, the codegen:verify script in the root package.json exists precisely to catch drift between generated and committed output, which tells you the project treats native code generation as something that must stay in sync. In your own app, that translates to re-running the platform configuration steps after a major upgrade rather than only bumping a version number.

Editorial conclusion

Adopt React Native Firebase if your app is bare React Native and you want native Firebase services (messaging, Crashlytics, Analytics, Firestore) behind an API that matches the Firebase Web SDK. Do not adopt it if you want one dependency for everything, or if you are on a managed Expo workflow and are unwilling to deal with the native configuration it requires. Before committing, verify the licence terms for your own use, since the repository reports NOASSERTION rather than a named SPDX identifier, and check the per-package install instructions for the specific module you plan to ship.

Frequently asked questions

Official sources

1. invertase/react-native-firebase on GitHub
2. Issues
3. Project website
4. README
5. Releases