React Native Firebase: Setup, Auth, Firestore & FCM (2026)

React Native Firebase — the @react-native-firebase library — is the most-used way to connect a React Native app to Google’s Firebase backend: authentication, Firestore, Cloud Messaging, storage, analytics, and more, with native performance instead of the web SDK’s JS bridge overhead. This guide is the current, end-to-end setup as of 2026, covering the modular v22 API, auth, Firestore, and push notifications, with working code you can paste.

One upfront note, because it saves people time: we build mobile apps in Flutter, not React Native. So when we hit the “React Native vs Flutter for Firebase” question near the end, it’s a genuine call, not a sales line — both work, and the right choice depends on your team. If you’re stack-shopping, read that section.

React Native Firebase setup

Installation has one rule people miss: @react-native-firebase/app is the required core module, and every other module (auth, firestore, messaging) depends on it. Install the app module first, then the features you need.

npm install @react-native-firebase/app
npm install @react-native-firebase/auth @react-native-firebase/firestore @react-native-firebase/messaging
cd ios && pod install && cd ..

You add your Firebase config files — google-services.json (Android, in android/app/) and GoogleService-Info.plist (iOS, added via Xcode) — from the Firebase console. On Android, add the Google Services Gradle plugin; on iOS, the native pods are linked automatically by pod install. If you’re on Expo, you can’t use @react-native-firebase in Expo Go — you need a development build via EAS, which trips up a lot of first-timers.

React Native Firebase authentication

Auth is usually the first thing you wire up. The modular API for email/password and a session listener:

import { getAuth, createUserWithEmailAndPassword, onAuthStateChanged } from '@react-native-firebase/auth';

const auth = getAuth();

await createUserWithEmailAndPassword(auth, email, password);

onAuthStateChanged(auth, (user) => {
  if (user) console.log('signed in', user.uid);
  else console.log('signed out');
});

onAuthStateChanged is the piece that matters for app architecture: it fires on launch and on every sign-in/out, so it’s where you gate your navigation (authenticated stack vs auth stack). For social login, @react-native-firebase/auth supports Google, Apple, and phone-OTP providers; phone auth needs the native reCAPTCHA/APNs setup, which is the fiddliest part — budget an afternoon for phone-OTP specifically. Apple Sign-In is mandatory if you offer any third-party social login on iOS, per App Store review rules.

React Native Firebase Firestore

Firestore is the document database. Reading and writing with the modular API:

import { getFirestore, collection, addDoc, onSnapshot } from '@react-native-firebase/firestore';

const db = getFirestore();

await addDoc(collection(db, 'orders'), { item: 'Pizza', status: 'new' });

onSnapshot(collection(db, 'orders'), (snap) => {
  snap.forEach((doc) => console.log(doc.id, doc.data()));
});

The onSnapshot listener is Firestore’s superpower — it pushes live updates, so a list screen re-renders the instant data changes, and the offline cache means it keeps working without a connection and syncs on reconnect. The catch is the same as everywhere with Firestore: it’s a document store, so relational queries (joins, aggregates) are painful and you denormalize data across documents. And remember reads are billed — a screen that re-reads a whole collection on every focus is how Firebase bills surprise teams. Paginate with limit() and startAfter().

React Native Firebase push notifications (FCM)

Cloud Messaging is the reason many teams reach for Firebase at all. The core flow: request permission, get the device token, register it server-side, and handle messages in foreground and background.

import { getMessaging, requestPermission, getToken, onMessage } from '@react-native-firebase/messaging';

const messaging = getMessaging();
await requestPermission();
const token = await getToken(messaging);   // send this to your backend

onMessage(messaging, async (msg) => {
  console.log('foreground message', msg.notification?.title);
});

Two gotchas bite everyone. First, iOS push requires an APNs key uploaded to Firebase and the Push Notifications capability enabled in Xcode — FCM on iOS is a wrapper over APNs, so without that key, nothing arrives. Second, background and quit-state messages are handled by a separate setBackgroundMessageHandler registered at the app’s entry point, not inside a component — put it in index.js. Test on a real device; the iOS simulator doesn’t receive push.

Securing your Firestore data

A working read/write is not a finished feature — without rules, your database is wide open. Firebase Security Rules are a separate DSL you write in the console (or in firestore.rules), and they’re where most Firebase data leaks come from because teams ship the default test-mode rules (open until a fixed date) and forget. The minimum for an app with user-owned data: deny by default, then allow a user to read and write only documents where the uid field matches request.auth.uid. Test rules with the Firebase emulator before you ship — the emulator runs locally and lets you assert “user A cannot read user B’s orders” as an actual test, not a hope. This is the single most-skipped step in React Native Firebase projects we’re asked to audit, and it’s a 30-minute fix that prevents a headline.

Common React Native Firebase errors (and fixes)

A handful of errors account for most of the time lost. Knowing them upfront saves days.

• “Default FirebaseApp is not initialized.” Almost always a missing or misplaced config file — google-services.json not in android/app/, or the iOS plist not added through Xcode (dragging it into the folder isn’t enough; it must be in the Xcode project). On Android, double-check the Google Services Gradle plugin is applied.
• Pods out of sync on iOS. After adding any new @react-native-firebase module, you must re-run pod install. Skipping it produces linker errors that look scary but mean “the native module isn’t built yet.”
• Push works in foreground but not background. The background handler must be registered at the top level (index.js), not in a component, and iOS needs the APNs key in Firebase plus the Push capability in Xcode. About 80% of “FCM doesn’t work” reports are one of these two.
• Expo Go can’t find the native module. @react-native-firebase uses native code, so it doesn’t run in Expo Go — you need an EAS development build. This catches a large share of Expo beginners.
• Version drift after an upgrade. All @react-native-firebase/* packages must be on the same version. Bumping one and not the others produces type mismatches. Upgrade them together, and expect a native rebuild.

In our experience taking over stalled React Native projects, roughly 3 of every 4 “Firebase is broken” tickets trace back to one of the five above — configuration, not code.

Beyond auth and Firestore: the rest of the suite

Most tutorials stop at auth + Firestore + push, but @react-native-firebase wraps the whole platform, and three more modules earn their place in a real app.

Analytics (@react-native-firebase/analytics) is free and unlimited, logs screen views and custom events, and feeds Firebase’s funnels and the BigQuery export if you need raw data. Wire it on day one — retrofitting event tracking after launch means you lose months of baseline. Crashlytics (@react-native-firebase/crashlytics) is the one we consider non-negotiable: native crash reporting with stack traces, free, and it surfaces the 1–2% of devices producing 90% of your crashes. Without it you’re debugging blind from one-star reviews. Remote Config lets you change values (feature flags, copy, thresholds) without an app-store release — invaluable when Apple review takes 1–3 days and you need to dark-launch or kill a feature fast.

Two more worth knowing: Storage (@react-native-firebase/storage) for user uploads (profile photos, documents) with the same security-rules model as Firestore, and Functions (@react-native-firebase/functions) to call Cloud Functions for server-side logic you don’t want on the client (payment confirmation, sending notifications, anything with a secret key). A typical production app uses six or seven of these modules together, which is exactly why keeping every @react-native-firebase/* package on the same version matters.

React Native Firebase vs Flutter Firebase

Here’s the honest comparison, since both are first-class Firebase clients and teams genuinely ask.

The real decision isn’t about Firebase — both @react-native-firebase and FlutterFire are mature and Google-supported. It’s about your team and your maintenance appetite. If you have a React web team and want to reuse their skills, React Native is the pragmatic call. If you’re starting fresh and want compiled performance with fewer native-dependency headaches, Flutter is ours — and FlutterFire is maintained by Google itself. We cover the Flutter-side equivalents (FlutterFire auth, Firestore, FCM) in our Flutter + Firebase work.

When to bring in a team

A React Native Firebase MVP — auth, a few Firestore collections, push — is a few weeks of work for a competent mobile dev. Where it gets expensive is the native edges: phone-OTP auth, background push on both platforms, offline-sync edge cases, and the inevitable native-dependency upgrade that breaks the build. Those are the parts that turn a “two-week MVP” into a two-month slog.

A useful rule of thumb from the projects we inherit: budget about 60% of your mobile timeline for the app itself and 40% for the platform edges — auth flows, push on both OSes, store submission, and the native upgrades that arrive every few months. Teams that scope only the 60% are the ones whose “almost done” app stays almost done for a quarter. The backend (Firebase or Supabase) is rarely the hard part; the native plumbing is.

We build production mobile apps (in Flutter, on Firebase or Supabase) and take over stalled React Native projects — the broader practice is in our mobile app development services, and the Flutter-specific work in our Flutter development services. If you’re choosing a backend rather than a framework, our supabase vs firebase comparison is the companion read.