.NET MAUI（.NET 8）Firebase 初期化エラー「Default FirebaseApp is not initialized」解決ガイド（Android/iOS・Crashlytics）

.NET MAUI（.NET 8）で Firebase（Crashlytics など）を導入したのに、起動直後に「Default FirebaseApp is not initialized」で落ちる――設定ファイルも依存関係も揃えているのに解消しないケースがあります。Android/iOS 両方での原因の見立てと、現場で効く切り分け手順をまとめます。

症状：Android / iOS で「Default FirebaseApp is not initialized」でクラッシュする

現象はシンプルで、Firebase を利用する処理（Crashlytics の初期化、ログ送信、イベント送信など）が走った瞬間に、「既定（Default）の Firebase アプリが初期化されていない」という例外でアプリが停止します。

プラットフォーム	代表的なエラーメッセージ例	よく起きるタイミング
Android	`Java.Lang.IllegalStateException: Default FirebaseApp is not initialized ... Make sure to call FirebaseApp.initializeApp(Context) first.`	起動直後、最初の画面表示前後、DI で Firebase 関連サービスが生成された瞬間
iOS	`Default Firebase app has not been configured.`（同種の「未初期化」エラー）	`Firebase.Core.App.Configure()` 相当が呼ばれる前に Firebase API を触ったとき

「google-services.json と GoogleService-Info.plist は置いた」「ビルドアクションも設定した」「依存関係（NuGet）も入れた」――それでも直らない場合、次の章の考え方が役立ちます。

なぜ起きるのか：Firebase は “使う前に初期化” が必須

この例外は、原因をひとことで言うと「Firebase を使うより前に、初期化処理が終わっていない」ことを意味します。Firebase の SDK は、起動時に設定ファイル（Android の json、iOS の plist）を読み取り、既定の FirebaseApp（Default Firebase app）を構築します。ここが作られていない状態で Crashlytics などの API を呼ぶと、今回の例外になります。

そして .NET MAUI では、アプリの起動経路が共有コード（MauiProgram/App）と、プラットフォーム側（MainApplication/AppDelegate）に分かれるため、初期化の置き場所やタイミングを少し誤るだけで再現します。

最優先の結論：Plugin.Firebase はサードパーティ。まずは公式リポジトリの既知Issueを確認する

質問で挙がりやすい Plugin.Firebase は、Microsoft が提供する公式コンポーネントではなく、サードパーティ製プラグインです。そのため Microsoft Learn の Q&A などでは、「プラグインの不具合の可能性があるので、プラグインの GitHub（公式リポジトリ）で既知Issueを確認し、必要なら報告する」という案内が正攻法になります。

実務的にも、同じ “未初期化” エラーでも、原因が次のどちらかで対応が変わります。

アプリ側の実装ミス：初期化の呼び出し位置が遅い／呼ばれていない／設定ファイルがビルドに入っていない
プラグイン側の追従不足：.NET 8 / MAUI の変更で初期化フックが効かない、または特定バージョンの組み合わせで動かない

まずは GitHub で「Default FirebaseApp is not initialized」「not been configured」などのキーワードで検索し、同じ環境（.NET 8、対象 OS、プラグインのバージョン）での既知解決策がないか確認してください。見つかった手順に沿うのが最短です。

切り分けの全体像：原因を最短で絞るためのチェック表

ここからは、プラグインの手順に沿っても解消しないときに、現場で「どこが詰まっているか」を素早く特定するためのチェックです。上から順に潰すと、無駄に時間を溶かしにくくなります。

チェック	見るポイント	NG のときに起きがちなこと	最初にやる対処
初期化が最初期に走っているか	Android: `OnCreate`、iOS: `FinishedLaunching` の時点で初期化されている	起動直後にクラッシュ／DI 生成時にクラッシュ	初期化位置をプラットフォーム起点へ移す
設定ファイルが要件通りか	配置場所、ファイル名、ビルドアクション、ビルドに含まれているか	`InitializeApp` が null を返す／iOS で Configure が効かない	csproj で Item を明示し、ビルド出力を診断ログで確認
Firebase コンソール登録と一致するか	Android の applicationId、iOS の Bundle Identifier	設定はあるのに初期化されない／環境（Debug/Release）で挙動が違う	該当 ID で設定ファイルを再ダウンロード
端末・キャッシュが汚れていないか	古いアプリが残っていない、bin/obj が新しい	「直したはずなのに変わらない」	アンインストール→クリーン→再インストール

チェック1：初期化が「Firebase を使うより前」に実行されているか

このエラーの大半は、初期化のタイミングで説明できます。特に MAUI では、共有コード側（MauiProgram や App、最初のページのコンストラクタ）に Firebase 利用が紛れ込みやすいのが落とし穴です。

Android：`FirebaseApp.InitializeApp(Context)` 相当を “最初期” に置く

Android は、アプリ起動時（Application の OnCreate）の段階で初期化できているのが安全です。プラグインの手順が別途ある場合はそれを優先しつつ、「Firebase を触る前」を守ってください。

// Platforms/Android/MainApplication.cs（例）
using Android.App;
using Android.Runtime;

namespace YourApp;

[Application]
public class MainApplication : MauiApplication
{
    public MainApplication(IntPtr handle, JniHandleOwnership ownership)
        : base(handle, ownership) { }

    protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();

    public override void OnCreate()
    {
        base.OnCreate();

        // 例：Firebase の既定アプリを初期化（プラグインの要件に合わせて調整）
        // InitializeApp が null の場合は、設定ファイル/登録情報の不一致を疑います。
        var app = Firebase.FirebaseApp.InitializeApp(this);
    }
}

重要なのは「呼んだかどうか」だけでなく、呼ぶより先に Crashlytics 等が動いていないかです。例えば次のパターンは、初期化が間に合わず再現しやすくなります。

やりがちな実装	なぜ危険か	改善の方向性
DI 登録時に Firebase サービスを即時生成する	App 起動直後にコンテナが構築され、初期化前に Firebase API が呼ばれる	遅延生成（Lazy）にする、初回利用時に初期化完了を待つ
`App` / 最初のページのコンストラクタで Crashlytics を触る	プラットフォーム側のライフサイクルより先に共有コードが動くことがある	画面表示後（OnAppearing 等）へ移す、またはプラットフォーム初期化を先に
静的コンストラクタやグローバル初期化で呼び出す	いつ実行されるか制御できず、起動順で事故りやすい	明示的な初期化メソッドに寄せる

iOS：`Firebase.Core.App.Configure()` 相当を起動時に呼ぶ

iOS は、アプリ起動時（AppDelegate の FinishedLaunching）で Configure()（またはそれに相当するプラグインの初期化）を呼ぶのが基本です。

// Platforms/iOS/AppDelegate.cs（例）
using Foundation;
using UIKit;

namespace YourApp;

[Register("AppDelegate")]
public class AppDelegate : MauiUIApplicationDelegate
{
    protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();

    public override bool FinishedLaunching(UIApplication app, NSDictionary options)
    {
        // 例：Firebase 初期化（プラグインの要件に合わせて調整）
        // GoogleService-Info.plist がバンドルに含まれていないと失敗します。
        Firebase.Core.App.Configure();

        return base.FinishedLaunching(app, options);
    }
}

iOS も同様に、Configure の前に Crashlytics 等の API を呼ぶと落ちます。共有コードの「早すぎる初期化」に要注意です。

共有コードに寄せたい場合：LifecycleEvents で “早い” タイミングに寄せる

「プラットフォーム側のファイルに Firebase のコードを増やしたくない」という場合は、MAUI のライフサイクルイベントから呼ぶ方法もあります（ただし、呼び出し先は結局プラットフォーム依存になります）。

// MauiProgram.cs（例）
public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>();

        builder.ConfigureLifecycleEvents(events =>
        {
#if ANDROID
            events.AddAndroid(android => android.OnCreate((activity, bundle) =>
            {
                // Android 初期化例
                Firebase.FirebaseApp.InitializeApp(Android.App.Application.Context);
            }));
#endif
#if IOS
            events.AddiOS(ios => ios.FinishedLaunching((app, options) =>
            {
                // iOS 初期化例
                Firebase.Core.App.Configure();
                return true;
            }));
#endif
        });

        return builder.Build();
    }
}

どの方法でも共通して重要なのは、「Firebase を使う前に必ず初期化」という順序です。

チェック2：設定ファイルの配置・ビルドアクションが “プラグイン要件どおり” か

設定ファイルを置いていても、ビルドに正しく取り込まれていないと初期化に失敗します。特に MAUI はマルチターゲットのため、Android / iOS それぞれの取り込み方が違います。

ファイル	配置例	ビルドアクション（一般的な例）	チェックのコツ
`google-services.json`	`Platforms/Android/`	`GoogleServicesJson`	ビルド出力（診断）で json が処理されているログを探す
`GoogleService-Info.plist`	`Platforms/iOS/`	`BundleResource`	ビルド後の .app に plist が入っているか確認する

Visual Studio のプロパティ画面で設定しても不安な場合は、csproj で明示するとトラブルが減ります。

<!-- YourApp.csproj（例） -->
<ItemGroup Condition="'$(TargetFramework)' == 'net8.0-android'">
  <GoogleServicesJson Include="Platforms/Android/google-services.json" />
</ItemGroup>

<ItemGroup Condition="'$(TargetFramework)' == 'net8.0-ios'">
  <BundleResource Include="Platforms/iOS/GoogleService-Info.plist" />
</ItemGroup>

プラグインによっては、ビルドアクション名や配置場所が異なる場合があります。「一般論として正しそう」よりも「プラグインのドキュメントに書かれている要件」を優先してください。

Debug/Release で設定を分けている場合の注意

実務では、Debug と Release、あるいは開発/検証/本番で Firebase プロジェクトを分けることがあります。このとき MAUI 側のアプリ ID が変わっていると、設定ファイルは入っているのに初期化できないという状態になりがちです。

Debug だけ applicationId（パッケージ名）にサフィックスを付けている
iOS の Bundle Identifier を構成ごとに変えている
Firebase 側で登録しているのは本番 ID だけ

このパターンでは、構成ごとに正しい設定ファイルを用意するのが基本です。例えば GoogleService-Info.Debug.plist のように分ける場合は、ビルド時にどのファイルをバンドルするかも csproj で制御します。

チェック3：Firebase コンソール側の登録情報（applicationId / Bundle Identifier）と一致しているか

設定ファイルは「Firebase コンソールで登録したアプリ情報」を前提に作られています。したがって、次が一致していないと初期化がうまくいきません。

プラットフォーム	一致させるべき値	.NET MAUI 側で確認する場所（例）	ありがちなズレ
Android	applicationId（パッケージ名）	csproj の `<ApplicationId>`、または AndroidManifest の package	アプリ名変更で package を変えた／Debug だけ別 ID
iOS	Bundle Identifier（`CFBundleIdentifier`）	Platforms/iOS/Info.plist、またはプロジェクト設定	署名設定や構成別の ID 変更、ターゲットの取り違え

心当たりがある場合は、Firebase コンソールで該当の ID でアプリを追加登録し、最新の google-services.json / GoogleService-Info.plist を再ダウンロードして入れ替えるのが確実です。

チェック4：端末側に古い設定やキャッシュが残っていないか

「設定を直したのに変わらない」ケースでは、端末に古いアプリが残っていたり、ローカルのビルド成果物（bin/obj）が汚れていたりします。次の手順は地味ですが、効果が高いです。

端末（またはシミュレータ）からアプリをアンインストール
プロジェクトの bin / obj を削除（または dotnet clean 相当）
クリーンビルド
再インストールして再現確認

特に iOS はビルドキャッシュの影響を受けやすいことがあるため、「一度まっさらにしてから」確認すると、切り分けが前に進みます。

それでも直らないとき：プラグイン起因を疑うための“証拠”を揃える

上のチェックを全部クリアしても解消しない場合、プラグイン側の不具合（または特定バージョンの組み合わせ問題）の可能性が高まります。GitHub Issue を上げる（または既存 Issue に情報を追加する）ときは、次を揃えると解決が早くなります。

用意する情報	例	なぜ重要か
環境情報	.NET 8 のバージョン、MAUI のバージョン、Plugin.Firebase のバージョン、Xcode/Android SDK	互換性問題（特定の組み合わせ）が見つけやすい
再現手順	新規 MAUI テンプレから追加した手順、実行までの流れ	メンテナが手元で再現しやすい
ログ/例外	Android の Logcat、iOS のデバイスログ、スタックトレース全文	初期化前に何が呼ばれているかが分かる
設定の前提	applicationId / Bundle Identifier、設定ファイル配置、ビルドアクション	「設定が効いていない」パターンを除外できる

Issue の本文は、次のテンプレを使うと整理しやすいです（値は自分の環境に置き換えてください）。

## Summary
.NET MAUI (.NET 8) + Plugin.Firebase で Firebase 初期化に失敗し、
"Default FirebaseApp is not initialized" でクラッシュします。

## Environment
- .NET SDK: 8.x.x
- .NET MAUI: x.x.x
- Plugin.Firebase: x.x.x
- Target: net8.0-android / net8.0-ios
- Device/OS: Pixel x (Android xx), iPhone x (iOS xx)
- IDE: Visual Studio xxxx / Rider xxxx

## Steps to reproduce
1. 新規 MAUI アプリ作成
2. Plugin.Firebase を追加
3. google-services.json / GoogleService-Info.plist を配置（ビルドアクション設定）
4. 起動するとクラッシュ

## Expected
Firebase が初期化され、Crashlytics を利用できる

## Actual
Default FirebaseApp is not initialized でクラッシュ（ログ添付）

## Notes
- Android: MainApplication.OnCreate で InitializeApp を呼んでいます
- iOS: AppDelegate.FinishedLaunching で Configure を呼んでいます
- applicationId / Bundle Identifier は Firebase コンソールと一致しています

実務での暫定回避：Firebase を “必須” にせず、未初期化なら機能を無効化する

Crashlytics は「クラッシュレポート」なので、最悪の場合でもアプリ本体が落ちるのは避けたい、という要件がよくあります。根本解決までの間、Firebase 初期化に失敗したら機能を無効化して続行する設計にしておくと、運用事故を減らせます。

例えば Android では、初期化結果が null のときは Firebase を使わない分岐を作ります（ログ出力やアプリ内設定で ON/OFF を切り替えるのも有効です）。

// 共有コードから呼ぶ “Firebase 利用可否” の例（Android）
#if ANDROID
public static bool TryInitFirebaseAndroid()
{
    var app = Firebase.FirebaseApp.InitializeApp(Android.App.Application.Context);
    return app != null;
}
#endif

iOS も同様に、「Configure 済みか」をチェックして多重初期化を避けつつ、未初期化なら Firebase 関連を触らないようにします。

// 共有コードから呼ぶ “Firebase 利用可否” の例（iOS）
#if IOS
public static bool EnsureFirebaseiOS()
{
    if (Firebase.Core.App.DefaultInstance == null)
    {
        Firebase.Core.App.Configure();
    }
    return Firebase.Core.App.DefaultInstance != null;
}
#endif

この手の回避はあくまで暫定です。Crashlytics が取れない期間が発生するため、できれば早めに根本原因（初期化タイミング／設定ファイル／プラグイン不具合）を潰すのが理想です。

よくある質問

設定ファイルを置いているのに、なぜ初期化されないのですか？

「置いたつもりでもビルドに含まれていない」「アプリ ID が Firebase 側と一致していない」「初期化より前に Firebase を触っている」のどれかが多いです。まずは初期化の場所とID の一致を確認し、次に csproj でファイル取り込みを明示すると切り分けが進みます。

Android は動くのに iOS だけ落ちます

iOS は GoogleService-Info.plist がアプリバンドルに入っていないと Configure が成立しません。ファイル名の大小文字、配置場所、ビルドアクション（BundleResource）を重点的に確認してください。

Debug では動くのに Release でだけ落ちます

Release だけ Bundle Identifier / applicationId が変わっている、または Release のビルド設定でファイル取り込みが外れているケースがあります。構成ごとに ID と設定ファイルが対応しているか、csproj の Condition が正しいかを見直してください。加えて、Release の最適化で挙動が変わる場合もあるため、まずは「ID と設定ファイル」を疑うのが近道です。

Microsoft に問い合わせれば解決しますか？

サードパーティ製プラグインの不具合や実装詳細は、Microsoft の公式サポート範囲外として案内されることが多いです。まずはプラグインの GitHub Issue とドキュメントを確認し、再現するなら情報を添えて報告するのが現実的です。そのうえで、アプリ側の初期化順序と設定の整合性を固めると、解決に近づきます。

まとめ：正攻法は “プラグインの既知Issue確認” ＋ “初期化順序の徹底”

Default FirebaseApp is not initialized は「Firebase を使う前に初期化が終わっていない」サイン
Plugin.Firebase はサードパーティなので、まずは公式リポジトリの既知Issue・推奨手順を確認する
並行して、初期化のタイミング（Android: OnCreate / iOS: FinishedLaunching）と、設定ファイル取り込み、アプリ ID の一致を重点的にチェックする
どうしても直らない場合は、再現手順とログを揃えて Issue に報告し、バージョン組み合わせ問題を早期に潰す

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

.NET MAUI（.NET 8）Firebase 初期化エラー「Default FirebaseApp is not initialized」解決ガイド（Android/iOS・Crashlytics）

症状：Android / iOS で「Default FirebaseApp is not initialized」でクラッシュする

なぜ起きるのか：Firebase は “使う前に初期化” が必須

最優先の結論：Plugin.Firebase はサードパーティ。まずは公式リポジトリの既知Issueを確認する

切り分けの全体像：原因を最短で絞るためのチェック表

チェック1：初期化が「Firebase を使うより前」に実行されているか

Android：`FirebaseApp.InitializeApp(Context)` 相当を “最初期” に置く

iOS：`Firebase.Core.App.Configure()` 相当を起動時に呼ぶ

共有コードに寄せたい場合：LifecycleEvents で “早い” タイミングに寄せる

チェック2：設定ファイルの配置・ビルドアクションが “プラグイン要件どおり” か

Debug/Release で設定を分けている場合の注意

チェック3：Firebase コンソール側の登録情報（applicationId / Bundle Identifier）と一致しているか

チェック4：端末側に古い設定やキャッシュが残っていないか

それでも直らないとき：プラグイン起因を疑うための“証拠”を揃える

実務での暫定回避：Firebase を “必須” にせず、未初期化なら機能を無効化する

よくある質問

設定ファイルを置いているのに、なぜ初期化されないのですか？

Android は動くのに iOS だけ落ちます

Debug では動くのに Release でだけ落ちます

Microsoft に問い合わせれば解決しますか？

まとめ：正攻法は “プラグインの既知Issue確認” ＋ “初期化順序の徹底”

この記事を書いた人

コメント

コメントするコメントをキャンセル

.NET MAUI（.NET 8）Firebase 初期化エラー「Default FirebaseApp is not initialized」解決ガイド（Android/iOS・Crashlytics）

症状：Android / iOS で「Default FirebaseApp is not initialized」でクラッシュする

なぜ起きるのか：Firebase は “使う前に初期化” が必須

最優先の結論：Plugin.Firebase はサードパーティ。まずは公式リポジトリの既知Issueを確認する

切り分けの全体像：原因を最短で絞るためのチェック表

チェック1：初期化が「Firebase を使うより前」に実行されているか

Android：FirebaseApp.InitializeApp(Context) 相当を “最初期” に置く

iOS：Firebase.Core.App.Configure() 相当を起動時に呼ぶ

共有コードに寄せたい場合：LifecycleEvents で “早い” タイミングに寄せる

チェック2：設定ファイルの配置・ビルドアクションが “プラグイン要件どおり” か

Debug/Release で設定を分けている場合の注意

チェック3：Firebase コンソール側の登録情報（applicationId / Bundle Identifier）と一致しているか

チェック4：端末側に古い設定やキャッシュが残っていないか

それでも直らないとき：プラグイン起因を疑うための“証拠”を揃える

実務での暫定回避：Firebase を “必須” にせず、未初期化なら機能を無効化する

よくある質問

設定ファイルを置いているのに、なぜ初期化されないのですか？

Android は動くのに iOS だけ落ちます

Debug では動くのに Release でだけ落ちます

Microsoft に問い合わせれば解決しますか？

まとめ：正攻法は “プラグインの既知Issue確認” ＋ “初期化順序の徹底”

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

Android：`FirebaseApp.InitializeApp(Context)` 相当を “最初期” に置く

iOS：`Firebase.Core.App.Configure()` 相当を起動時に呼ぶ

コメントするコメントをキャンセル