React Native Firebase（npm上の名前は @react-native-firebase）は、FirebaseのAndroid SDKとiOS SDKをそのまま呼び出すための、React Native向けのモジュール群です。JavaScriptから呼ぶ形はFirebaseのWeb版SDKに寄せてありますが、中身で動いているのはネイティブSDKそのもの。だからWeb版では扱えないCrashlyticsやAnalyticsにも手が届きます。2026年7月末に出たv26では名前空間APIが削除され、ネイティブブリッジを持つ全パッケージがNew Architecture必須になりました。この記事では2026年8月時点の一次情報をもとに、構造、Expo構成とReact Native CLI構成それぞれの導入、ネイティブ設定で落ちる地点、Web版SDKとの使い分けを扱います。
まとめ：v26の新アーキ必須化と名前空間API削除から逆算する
先に結論から。新規に入れるなら26.3系（2026年8月21日に26.3.2が公開）で、コードはモジュラーAPIのみ。firebase.auth() のような名前空間の書き方は15パッケージから消えました。既存プロジェクトを上げるときは、まずNew Architectureが有効かどうかを見ます。有効にできない事情があるならv26へは進まず、v25に留まるのが公式の案内。
次に導入の分岐です。Expo構成なら npx expo install で入れて、app.json の plugins 配列へモジュールを並べ、設定ファイルのパスを2か所書けば終わります。React Native CLI構成なら、Android側はファイルを置くだけで通る反面、iOS側はXcodeへ参照として追加しないとアプリへ同梱されません。
そして採否の判断です。Analytics・Crashlytics・Performance Monitoring・Remote Configのいずれかを使うなら、Web版SDKでは届かないので @react-native-firebase 一択。逆に認証とFirestoreだけで足りるなら、Web版SDKに留めておく判断も現実的でしょう。
React Native FirebaseはネイティブSDKを薄いJS層で包む構造
まず構造を押さえます。このライブラリはFirebaseのAndroid SDK・iOS SDKへのブリッジであり、通信やキャッシュの実体はネイティブ側にあります。JavaScript側にあるのは呼び出しの窓口と型定義だけ。React Nativeとはで扱ったTurboModulesの仕組みに乗る形で、v26からは全パッケージがCodegen経由のTurboModuleとして実装されています。
18のモジュールが各Firebaseサービスに1対1で対応する構造
パッケージは機能ごとに分かれていて、公式READMEの表では18モジュール。土台となる @react-native-firebase/app を必ず入れ、そこへ使うサービスの分だけ足していきます。内訳はai、analytics、app-check、app-distribution、auth、crashlytics、database、firestore、functions、in-app-messaging、installations、messaging、ml、perf、phone-number-verification、remote-config、storage、そしてapp。リポジトリのpackages配下にはvertexaiを含む19ディレクトリが並びます。
入れた分だけネイティブSDKがバイナリへ足されるため、モジュールの数はそのままアプリサイズとビルド時間に響きます。Firebaseの導入手順でコンソール側のプロジェクトを作る段階で、使うサービスを先に絞っておきたいところ。
Web版のfirebase JS SDKでは届かない機能がどこまであるか
Firebaseには純JavaScriptのWeb版SDK（npmの firebase）もあり、React Nativeでもそのまま動きます。ただし動く範囲が違う。Expo公式のドキュメントは、Web版SDKで扱えるのはAuthentication・Firestore・Realtime Database・Storageであり、AnalyticsやCrashlyticsといったサービスはモバイルアプリでは非対応だと明記しています。
この差は計測やクラッシュ収集が端末のOS機能に依存するために生まれます。アプリの起動時間を測る、ネイティブ層で落ちたスタックトレースを拾う、OSの通知チャネルへ登録する。どれもJavaScript層だけでは完結しません。Firebase Crashlyticsとはで扱ったシンボルファイルの送信も、ネイティブSDKとビルドツールの連携が前提になります。
v26で名前空間APIが消えTurboModuleが必須になった
2026年7月29日にnpmへ26.0.0が公開され、8月7日にInvertaseから告知が出ました。ここが版を選ぶうえでの分水嶺です。
26.3系までの版の流れと、v25やv23に留まる条件の見極め
v22の頃から「名前空間APIは非推奨」という警告が出続けていて、v26でついに削除されました。対象は15パッケージ（app・ml・in-app-messaging・installations・messaging・app-distribution・functions・perf・app-check・analytics・remote-config・crashlytics・database・storage・auth）。デフォルトエクスポートと Firebase*Types の型名前空間も同時に無くなっています。
もうひとつの前提がNew Architectureです。ネイティブブリッジを持つパッケージはすべてCodegen TurboModuleとして再実装されたため、旧アーキのままでは動きません。例外は純JavaScript実装のaiとvertexaiだけ。新アーキへ移れない事情があるプロジェクトはv25に留まり、レガシーなCloud Functionsの都合があるならv23という段階が公式に示されています。据え置きを選ぶなら、いつまで据え置くのかも決めておく。
モジュラーAPIへの書き換えで戻り値が同期へ変わる箇所の一覧
移行作業は機械的な置換で大半が済みますが、戻り値の型が変わるAPIだけは目視で拾う必要があります。v26で同期になった主なものは次のとおり。
| モジュール | 同期化されたAPI |
|---|---|
| analytics | logEvent（voidを返す） |
| perf | trace開始・停止とhttpMetric |
| database | goOnlineとgoOffline |
| storage | アップロードの一時停止など |
| firestore | initializeFirestore |
| app-check | initializeAppCheck |
storageのpause・resume・cancelはbooleanを返す形になりました。await を付けたままでも動いてしまうため、コンパイルエラーで気づけないのが厄介なところ。Promise.all でまとめていた箇所は、順序が変わっていないかを実機で確かめておきます。
import { getApp } from '@react-native-firebase/app';
import { getFirestore, runTransaction } from '@react-native-firebase/firestore';
const db = getFirestore(getApp());
await runTransaction(db, myUpdateFn, { maxAttempts: 3 });
firestoreのトランザクションは maxAttempts を受け取るようになり、省略時は5回。1未満を渡すと同期的に例外が飛びます。競合の多いドキュメントを扱う画面では、この回数を明示しておくと挙動が読みやすくなるはずです。
Expo構成の導入はコンフィグプラグインとprebuildで完結する
Expoを使っている場合、ネイティブのプロジェクトファイルを直接触る場面はほぼありません。設定は宣言的に書き、生成はツールへ任せる形。Expo（React Native）とはで扱ったprebuildの考え方が、そのままこのライブラリの導入手順に効いてきます。
app.jsonのpluginsとgoogleServicesFileに書く2か所
導入は npx expo install @react-native-firebase/app から始め、使うモジュールも同じコマンドで追加します。次に app.json または app.config.js の plugins 配列へ、ネイティブ側の設定が要るモジュールを列挙。すべてのモジュールを書く必要はなく、ネイティブのインストール手順を持つものだけが対象です。
設定ファイルの指定はもう1か所。Firebaseコンソールから落とした google-services.json と GoogleService-Info.plist を、それぞれ expo.android.googleServicesFile と expo.ios.googleServicesFile のパスとして書きます。ローカルでビルドするなら npx expo prebuild --clean でネイティブのディレクトリを作り直します。
Expo Goで動かない理由と開発ビルドへ切り替えるときの手順
ここでよく止まるのがExpo Goです。公式ドキュメントは「React Native FirebaseはネイティブコードがExpo Goへコンパイルされていないため、事前ビルド済みのExpo Goアプリでは利用できない」と明言しています。QRコードを読んで即動く体験からは、この時点で外れることになります。
切り替え先は開発ビルド（development build）です。expo-dev-client を入れ、自分のプロジェクトのネイティブモジュールを含んだクライアントを一度ビルドして端末へ入れる。以降のJavaScript側の変更は、これまでと同じくホットリロードで反映されます。手戻りを避けるなら、Firebaseを使うと決まった時点で開発ビルドへ移しておくのが無難でしょう。
React Native CLI構成で詰まるネイティブ設定の3つの地点
Expoを使わないベアワークフローでは、設定ファイルの配置とネイティブプロジェクトの編集を自分で行います。手数自体は多くありませんが、失敗の仕方が独特です。
AndroidはGradleプラグインが読む位置に置くだけで通る
Android側は素直です。google-services.json を android/app/ の直下へ置き、Google Servicesのプラグインを有効にすれば、ビルド時に読み込まれます。パッケージ名（applicationId）とファイル内のpackage_nameが食い違っていればビルド時点でエラーとして落ちるため、間違いに気づけないという事態にはなりにくい構造。
詰まるとすればマルチフレーバー構成のときです。開発・検証・本番でapplicationIdを分けているなら、設定ファイルもフレーバーごとのディレクトリへ置き分けます。この整理を最初にやっておくと、検証環境のデータが本番プロジェクトへ混ざる事故を防げます。
iOSはXcodeへ参照として追加しないとplistが同梱されない
iOS側はここが最大の落とし穴。GoogleService-Info.plist は、Finderでフォルダへコピーしただけでは何も起きません。公式手順が指示しているのは、Xcodeでプロジェクトを開き、プロジェクト名を右クリックして「Add files」でファイルを追加する操作です。Xcodeのプロジェクトファイルに参照が登録され、Copy Bundle Resourcesへ入って初めて、アプリのバンドルへ同梱されます。
症状は「Androidでは動くのにiOSだけ初期化で落ちる」という形で出ます。エラーはFirebaseの構成が見つからない旨の実行時例外で、ビルド自体は通ってしまう。ターゲットの選択も同じく見落としがちな箇所。
AppDelegateの初期化はReact Native 0.77を境に書き方が変わる
iOSではアプリ起動時にFirebaseの初期化を明示的に呼びます。React Native 0.77以降はAppDelegateがSwiftになったため、import Firebase を足して FirebaseApp.configure() を呼ぶ形。0.77より前のObjective-C構成では、Firebaseのヘッダを読み込んだうえで didFinishLaunchingWithOptions の中から構成メソッドを呼びます。
周辺の要件も押さえておきます。Firebase iOS SDK側はXcode 26.2・Swift 6.2.3以上・macOS 15以上を求めており、Swift Package Managerを使う構成はReact Native 0.75以上が前提。SPM対応は26.1で入り、CocoaPodsの退役を見据えた扱いになりました。CIのmacOSランナーの世代が古いままだと、ローカルでは通るのにCIだけ落ちるという分かりにくい失敗になります。
利用できるモジュールの範囲と、別ライブラリへ任せる領域の線引き
モジュールが揃っているとはいえ、すべてをこのライブラリだけで完結させる設計にはなっていません。v26では担当範囲を外へ出す変更も入りました。
通知の許可APIは非推奨で通知ライブラリとの併用が前提になる
messagingモジュールが持っていた通知許可まわりのAPIは非推奨となり、プラットフォーム標準の通知ライブラリへ委ねる方針が示されました。トークンの取得とメッセージの受信はmessagingが担い、許可要求・チャネル設定・前面表示は通知ライブラリが担う、という分担になります。
この分担を知らずに設計すると、許可ダイアログが出ない、あるいは二重に出るといった挙動になりがち。プッシュ通知を含む案件では責務の分担を実装前に決め、権限まわりのコードを1か所へ集めておきます。
iOSのARM64シミュレータで返る2つの拒否コードの扱い方
v26ではARM64のiOSシミュレータ上でUIKitの registerForRemoteNotifications を呼ばなくなりました。メインスレッドが止まる問題への対処です。実機の挙動は変わりません。ただしシミュレータでは、APNsの登録が約10秒で決着しなかった場合に messaging/registration-timeout、登録呼び出しが重なった場合に messaging/registration-superseded という2つの拒否が返るようになりました。
アプリ側はこの2つを握りつぶさず、ログへ残したうえで処理を続ける形にしておきます。シミュレータでの失敗を実機の不具合と取り違えると、原因のない調査に時間を溶かすためです。
Dynamic Linksの終了でモジュールごと消えた機能の代替先
Firebase Dynamic Linksはサービス自体が終了し、それに合わせてモジュールも削除されました。ディープリンクを扱っていたプロジェクトは、OS標準のUniversal LinksとApp Links、あるいは他社のディファードディープリンク基盤へ移すことになります。移行では、インストール前に踏まれたリンクの情報を初回起動へ引き継ぐ部分が最も手間のかかる箇所。
逆に、残っているモジュールは着実に増えています。生成AIを扱う ai パッケージ、Android限定の電話番号確認、TOTPによる多要素認証など、v26の系で追加された機能も。Firebase Remote Configとはで扱った設定配信や、Firebase App Distributionとはのテスター配信も、同じ枠組みのモジュールとして扱えます。
Web版SDKと@react-native-firebaseをどう使い分けるか
ここが実装方針の分かれ目です。両者は排他ではなく併存もできますが、併存させると初期化が二重になり、状態の持ち方がずれます。
Web版SDKと併用するときに初期化と認証の永続化で起きる事故
Web版SDKは firebase パッケージとして入り、Expo公式は12.0.0以上のみをサポートすると案内しています。認証まわりで最初に踏むのが永続化の問題で、initializeAuth に getReactNativePersistence とAsyncStorageを渡さないと、メモリ上の永続化へ退避します。アプリを閉じるとログイン状態が消える、という症状の正体はこれ。
そして両方を入れた場合、Web版はJavaScript側で、@react-native-firebaseはネイティブ側で、それぞれ別の認証状態を持ちます。片方でサインインしても、もう片方から見ればサインアウトのまま。Cloud Firestoreとはのセキュリティルールを認証済みユーザー前提で書いていると、この食い違いが権限エラーとして現れます。原則はどちらか一方へ寄せる形。
受託開発で@react-native-firebaseを主線に据える条件
採用してよいと判断できるのは、次の3つが揃う場合です。第一に、計測・クラッシュ収集・設定配信・A/Bテストのいずれかが要件に入っていること。これらはWeb版SDKでは扱えないため、そもそも選択の余地がありません。第二に、New Architectureを有効にできること。第三に、ネイティブビルドを回すCI環境を用意できること。iOSの署名とmacOSランナーの世代管理まで含めた体制が要ります。
この3条件が揃う案件では、認証からDB、計測、配信までを1つの基盤へ寄せられるため、運用の窓口が減ります。Flutter・React Nativeによるクロスプラットフォームアプリ開発では、こうした構成の設計から、既存アプリの新アーキ移行やv26への追随までを含めて引き受けています。
Web版SDKのままで足りる案件と、切り替えを見送る場面の判断
見送ってよい場面もはっきりしています。要件が認証とFirestoreの読み書きに限られ、計測はWeb解析側で足りていて、社内向けで配布規模も小さい。この条件ならWeb版SDKのままExpo Goで回すほうが、開発の回転は速くなります。ネイティブビルドを持たない分、CIも簡素に済むはず。
もうひとつの見送り条件は、New Architectureへ移せない依存ライブラリが残っている場合です。無理にv26へ上げるより、v25で止めて依存側の対応を待つ判断が現実的でしょう。Web版で作った画面を後からネイティブSDKへ寄せる作業は、認証の永続化とセキュリティルールの再確認が中心。React Native Webとはの構成でWebへも出す予定があるなら、共通コード側はWeb版SDK、アプリ側だけネイティブという分岐も選択肢に入ります。
よくある質問
React Native FirebaseはExpo Goで使えますか？
使えません。Expo Goにはこのライブラリのネイティブコードが含まれていないためです。expo-dev-client を入れて自分のプロジェクト用の開発ビルドを作り、それを端末へインストールして開発を進めます。
v26へ上げると既存のコードはどれくらい書き換えが要りますか？
名前空間APIを使っていた箇所はすべて書き換えになります。firebase.auth() のような呼び方から getAuth(app) 形式へ移す作業で、対象は15パッケージ。加えて、戻り値が同期値へ変わったAPIの await を外します。New Architectureを有効にできないなら、v25に留めるのが公式の案内です。
iOSだけFirebaseの初期化で落ちるのはなぜですか？
GoogleService-Info.plistがアプリへ同梱されていない可能性が高いです。ファイルをフォルダへコピーしただけでは足りず、Xcodeでプロジェクトを右クリックしてAdd filesから参照を追加します。追加後はCopy Bundle Resourcesに入っているかを確認してください。
Firebase Dynamic Linksのモジュールが見つからないのですが？
サービスの提供終了に伴い、モジュール自体が削除されました。代替はOS標準のUniversal Links（iOS）とApp Links（Android）で、インストール前に踏まれたリンクを初回起動へ引き継ぐ機能が必要なら、他社のディファードディープリンク基盤を検討することになります。
Web版SDKと@react-native-firebaseは併用できますか？
技術的には併用できますが、認証状態がJavaScript側とネイティブ側で別々に保持されるため、片方でサインインしても他方はサインアウトのままになります。どちらか一方へ寄せる設計が基本です。
関連記事
- React Nativeとは：本体の構造と新アーキの全体像です。
- Expo（React Native）とは：開発ビルドとprebuildの前提です。
- Firebaseの導入手順：コンソール側の準備と設定ファイル取得です。
- Firebase Crashlyticsとは：クラッシュ収集の設計です。
- Firebase Remote Configとは：値配信と段階公開の実装です。
- Firebase App Distributionとは：テスター配信の仕組みです。
- Cloud Firestoreとは：セキュリティルールの前提です。
- React Native Webとは：Web出力を含む選び方に関わります。
