Firebase Apple SDK の CocoaPods → SPM 移行で詰まった3つのポイント — 4アプリ実例から

2026年5月、私の4つのiOSアプリで Firebase Apple SDK の CocoaPods → Swift Package Manager（SPM）移行を進めました。 Googleが2026年10月をもってCocoaPods経由でのFirebase配信を停止することを発表していたため、対応期限が明確でした。

累計5,000万DLのアプリ事業を個人で運営している立場として、「期限のある移行作業を安全にこなす」というのは常に緊張を伴います。今回は Antigravity を診断・作業の相棒として使い、4アプリ（Beautiful HD Wallpapers、Ukiyo-e Wallpapers、Relaxing Healing、Law of Attraction Everyday）を順次移行しました。

詰まったポイントは主に3つありました。同じ作業を控えている方の参考になれば幸いです。

なぜ今すぐ動くべきか — Googleの発表を確認する

CocoaPods経由のFirebase Apple SDK配信は2026年10月に停止されます。これは「推奨しなくなる」ではなく「配信停止」です。既存のPodfileにpod 'Firebase/Analytics'と書いたままpod installを実行しても、将来的にパッケージが取得できなくなります。

新規プロジェクトはすでにSPM移行が事実上のデフォルトになっていますが、2013年以降に作ったアプリはCocoaPodsベースのものが多く、移行コストが発生します。私の場合、最も古いアプリは12年前に書いたコードが残っており、Podfileのエントリー数も多く、単純なコピー移行では済みませんでした。

最初のアプリ（relaxing-healing）での検証を先行させ、問題なければ残り3アプリに展開するというアプローチを取りました。

詰まりポイント1: Dropbox競合コピーがビルドを壊す

最初に遭遇したのは、Dropbox同期が原因の問題でした。

.swiftpm/xcuserdata/ 以下のファイルがDropboxにより同期され、別デバイスからのアクセスで競合コピー（file (conflicted copy ...)）が生成されていました。 SPM移行後はこのディレクトリに新しいファイルが増えるため、競合コピーがビルドエラーの原因となりました。

Antigravityに症状を伝えると、すぐにxattrコマンドを提案してくれました。

# Dropboxの同期対象から除外する（競合コピーを防ぐ）
xattr -w com.dropbox.ignored 1 build/Pods/.swiftpm/xcuserdata

このコマンドは、指定したディレクトリをDropboxの同期対象から除外します。 Xcodeプロジェクトをワークスペースにした後も同様の問題が起きたため、以下のパスにも同じ処置を施しました。

xattr -w com.dropbox.ignored 1 YourApp.xcodeproj/project.xcworkspace/xcuserdata

これだけで、謎のビルドエラーが消えました。公式のFirebase移行ドキュメントには一切書かれていない落とし穴です。

詰まりポイント2: Crashlytics の dSYM アップロードが静かに失敗する

SPM移行後、初回のTestFlight提出でCrashlyticsのシンボリケーションが機能しなくなりました。クラッシュレポートが「Symbolicated」ではなく「Unsymbolicated」として届くようになっていました。

原因は、CocoaPodsを使っていたときはPods-*.shスクリプトが自動でBuild Phaseに組み込まれていたのですが、SPMに移行した後はこのスクリプトが失われていたことです。

Antigravityへの質問：「Crashlyticsがシンボリケーションしなくなった。SPM移行後です」回答で得た対処法：

Xcodeの「Build Phases」に以下のRun Scriptを追加します。

# Build Phases → "+" → New Run Script Phase
# Script content:
"${PODS_ROOT}/FirebaseCrashlytics/run"

ただし、SPMではPodsディレクトリが存在しないため、このパスは使えません。代わりに、Xcode 15以降では以下のアプローチが正しいとわかりました。

# Build Phases → Run Script（SPM対応版）
# Input Files に追加:
# ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${TARGET_NAME}
 
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"

加えて、「Build Settings」で以下を確認する必要があります。

Debug Information Format: DWARF with dSYM File（Releaseビルドで必須）

この設定がなければdSYMファイル自体が生成されず、アップロードしようにもファイルがない状態になります。 Antigravityに症状を伝えてから正しいパスにたどり着くまで30分ほどでしたが、自力で探すと半日は溶けていたと思います。

詰まりポイント3: AdMobメディエーションのPodがSPM非対応

4アプリにはAdMobメディエーションを組み込んでいます。 Firebase本体はSPM対応が完了していますが、メディエーションパートナーのSDK（Liftoff、InMobi、Unity Ads）はSPMに対応していないものが混在しています。

私の場合、この3パートナーについては引き続きCocoaPodsで管理するというハイブリッド構成を選択しました。

# Podfile（Firebase本体を除き、メディエーションのみ残す）
platform :ios, '14.0'
 
target 'YourApp' do
  # Firebase本体はSPMに移行済みなので記述しない
  # メディエーションパートナー（SPM未対応のもの）
  pod 'LiftoffMonetize-Sdk'
  pod 'InMobiSDK'
  pod 'UnityAds'
end

Xcodeの「Package Dependencies」にFirebaseを追加しつつ、Podfileにはメディエーションのみ残す構成です。

Antigravityへ「Firebase本体SPM + メディエーションCocoaPodsの混在構成は問題ないか」と確認したところ、「技術的には可能で、Appleも支持する構成」という回答を得ました。実際に4アプリとも動作しており、今のところ問題は出ていません。

メディエーションパートナーがSPM対応を完了次第、Podfile自体を削除する方向で考えています。

Antigravityが特に役立ったフェーズ

今回の移行作業でAntigravityを使って特に感じた強みは「症状から原因を逆算する能力」でした。

CocoaPods → SPMの移行は、エラーメッセージが直感的でないケースが多いです。「Module 'FirebaseCore' not found」と表示されても、それがPackage.resolved の不整合なのか、ターゲットのリンク設定の問題なのか、キャッシュの問題なのかが見えにくい。

Antigravityに現象を伝えると、「まずPackage.resolvedを削除してDerived Dataをクリアしましょう」というように、診断の優先順位を明確に返してくれました。

# Antigravityが最初に提案した診断手順
rm -rf ~/Library/Developer/Xcode/DerivedData
# Xcodeで File → Packages → Reset Package Caches
# その後 Product → Clean Build Folder

この「症状→仮説→診断手順」のサイクルを人間相手にやると時間がかかります。 Antigravityはそれを数秒で返してくれるため、移行作業のリズムが保てました。

SPM移行後のビルド時間変化

余談ですが、SPM移行後のビルド時間についても触れておきます。

4アプリとも、初回ビルド時間は延びました（Swiftのソースコードをダウンロードしてビルドするため）。ただし2回目以降は、Derived Dataにキャッシュされるためか、CocoaPods時代と大差ない印象です。

気になった点として、Derived DataのサイズがCocoaPods時代より増えました。開発マシンのストレージに余裕があるかどうかは、移行前に確認しておくことをおすすめします。

移行作業の全体所要時間と優先順位の考え方

参考として、私が4アプリを移行した際の所要時間をまとめます。

1アプリあたりの実作業時間は2〜4時間でした（検索・調査込み）。 Antigravityで診断しながら進めたため、試行錯誤の時間は最小限に抑えられたと感じています。

作業の優先順位としては、以下の順に進めることをおすすめします。

Podfileの整理: まず現在のPodfileを棚卸しし、Firebase本体とメディエーションを分離する
1アプリで先行検証: 最もシンプルなアプリで移行し、問題箇所を洗い出す
Derived DataとPackage.resolvedのリセット: トラブル時の初手はこれ
Build Phasesの手動確認: Crashlyticsのスクリプトパスは必ず手動で更新する

急いで全アプリを同時に移行しようとするよりも、1アプリずつ確認しながら進める方が結果的に早く完了します。私自身、Relaxing Healingでの先行検証があったおかげで、残り3アプリは半日で済みました。

全体を振り返って — 10月の期限に向けてやること

Firebase SPM移行で詰まりやすいポイントは、公式ドキュメントには書かれていない実装環境固有の問題です。

今すぐできる対応として、まず1つのアプリで先行移行を試すのが現実的です。私はrelaxing-healing（Relaxing Healing）で先行検証し、問題なかったパターンを他3アプリに展開しました。

同じ構成のアプリが複数ある場合は、最もシンプルな構成のものから始め、そこで得た知見を残りに転用するアプローチをお勧めします。