Rork Max 製 iOS アプリの Firebase CocoaPods を Swift Package Manager へ移行した実録——2026年10月の廃止前に対応した手順と3つの落とし穴

移行前の準備——CocoaPods 依存関係の棚卸し

移行を始める前に、現在の Podfile を丁寧に確認します。Firebase 以外に CocoaPods で入れているライブラリがある場合、それらが SPM 対応しているかどうかを事前に調べておく点が肝心です。

# Relaxing Healing の Podfile（移行前）
platform :ios, '14.0'
use_frameworks!
 
target 'RelaxingHealing' do
  pod 'Firebase/Core'
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Analytics'
  pod 'Firebase/Performance'
end

SPM 移行後、同等の機能は以下のパッケージで提供されます。

• Firebase/Core → FirebaseCore
• Firebase/Crashlytics → FirebaseCrashlytics
• Firebase/Analytics → FirebaseAnalytics（または FirebaseAnalyticsWithoutAdIdSupport）
• Firebase/Performance → FirebasePerformance

注意点として、FirebaseAnalytics は広告識別子（IDFA）へのアクセスを含む場合があります。ATT フレームワークによる許諾が不要な場合は FirebaseAnalyticsWithoutAdIdSupport を選ぶと審査リジェクトのリスクが下がります。私のアプリでは ATT プロンプトを表示しているため通常版を使っていますが、ここは各アプリのポリシーに合わせて判断してください。

Firebase 以外に CocoaPods にしか存在しないライブラリがある場合は、Podfile を完全削除できません。その場合は Firebase 分だけ SPM に移行し、他のライブラリは引き続き CocoaPods で管理するという混在構成も可能です。今回の4本はいずれも Firebase のみが CocoaPods 依存だったため、Podfile を完全に削除できました。

Podfile.lock を捨てる前に、いま動いているバージョンを写し取る

移行の順番でひとつだけ、後から効いてきた判断があります。SPM に入れる Firebase のバージョンを、いまビルドが通っている版に固定してから始めることです。

pod deintegrate の勢いで Podfile.lock まで消してしまうと、次に Xcode の Package Dependencies で「Up to Next Major Version」を選んだ瞬間、SPM への移行と Firebase 本体のバージョンアップが同時に起きます。この状態で何かが壊れると、原因が「SPM の構成」なのか「新しい Firebase」なのか切り分けられません。私は Relaxing Healing でこれをやってしまい、リンクエラーの調査に1時間ほど余計に使いました。

削除する前に、解決済みのバージョンを控えておきます。

# Podfile.lock から Firebase の解決済みバージョンだけを抜き出す
grep -E '^[[:space:]]+- Firebase' Podfile.lock | sed 's/^[[:space:]]*//'
 
# 出力例
#   - Firebase/Analytics (11.8.0)
#   - Firebase/Core (11.8.0)
#   - Firebase/Crashlytics (11.8.0)
#   - Firebase/Performance (11.8.0)

この番号を Xcode の Package Dependencies で Exact Version として指定します。移行を2段階のコミットに分けると、後から原因を辿れる形になります。

第1コミットが通った時点で Package.resolved が生成されます。このファイルは必ずコミットしてください。SPM における Podfile.lock の役割を担うファイルで、これを追跡していないと、別の Mac でクローンしたときに異なるバージョンが引かれます。Xcode のプロジェクト構造によって置き場所が変わるため、見つからない場合は検索します。

find . -name "Package.resolved" -not -path "*/DerivedData/*"
# .../MyApp.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved

戻せる状態を作ってから pod deintegrate を叩く

pod deintegrate は Podfile を消すコマンドではなく、.xcodeproj の中身（Build Phases・xcconfig 参照・Framework の紐付け）を書き換えるコマンドです。実行後に「やっぱり戻したい」と思っても、手作業での復元はまず現実的ではありません。

私は Dropbox のバージョン履歴があるから大丈夫だろうと考えていたのですが、これは誤算でした。.xcodeproj は複数ファイルの集合体で、Dropbox の巻き戻しは1ファイル単位です。整合性の取れた状態へまとめて戻す用途には向いていません。

始める前に、git で退避点を作ります。

# 移行前に必ず1コミット作ってタグを打つ
git add -A
git commit -m "chore: snapshot before SPM migration"
git tag pre-spm-relaxing-healing
 
# 万一戻すとき（Podfile / Podfile.lock / .xcodeproj がまとめて復元される）
git checkout pre-spm-relaxing-healing -- .
pod install

あわせて、SPM が生成する作業ファイルを追跡対象から外しておきます。ここを外しておかないと、後述する Dropbox 競合コピーの断片がそのままリポジトリに入り込みます。

# .gitignore に追加
.swiftpm/
DerivedData/
*.xcworkspace/xcuserdata/
*.xcodeproj/xcuserdata/

タグ名にアプリ名を含めているのは、4本を順番に移行していく過程で pre-spm だけだとどのアプリの退避点か分からなくなったためです。細かい話ですが、2本目以降の作業がずいぶん楽になりました。

実際の移行手順——Relaxing Healing での先行検証

Step 1: CocoaPods の Firebase Pod を削除して完全除去

まず pod deintegrate を実行します。Podfile から行を削除するだけではなく、CocoaPods が .xcodeproj に注入した設定を綺麗に取り除くためにこのコマンドが必要です。

# プロジェクトルートで実行
cd /path/to/RelaxingHealing
pod deintegrate
 
# Podfile と関連ファイルを削除
rm -f Podfile Podfile.lock
rm -rf Pods/

pod deintegrate を実行すると、.xcodeproj から CocoaPods 関連の設定が削除されます。この後、.xcworkspace ではなく .xcodeproj を直接 Xcode で開くようにします。.xcworkspace は CocoaPods が生成するファイルで、Pods が不要になったら使いません。

Step 2: Xcode の Swift Package Dependencies に Firebase を追加

Xcode でプロジェクトを開き、パッケージ依存関係を設定します。

1. プロジェクトナビゲーターでプロジェクトを選択
2. 「Package Dependencies」タブを開く
3. 「+」ボタンをクリック
4. https://github.com/firebase/firebase-ios-sdk を入力して検索
5. バージョンを選択（現在の安定版を推奨）
6. 必要なモジュールだけチェックして追加

✅ FirebaseCore
✅ FirebaseCrashlytics
✅ FirebaseAnalytics（または FirebaseAnalyticsWithoutAdIdSupport）
✅ FirebasePerformance

モジュールは使っているものだけを追加します。全部にチェックを入れると、使っていない Firebase SDK まで含まれてビルドサイズと時間が増加します。Podfile と見比べながら必要なものだけ選ぶのが重要です。最初のビルドは SPM のパッケージダウンロードが走るため数分かかりますが、2回目以降はキャッシュが効いて早くなります。

Step 3: Build Settings の CocoaPods 残存設定をクリーンアップ

pod deintegrate は多くの設定を取り除きますが、一部の設定が残ることがあります。Xcode の Build Settings で PODS と検索して、残存している参照がないかを確認します。

⚠️ 残存しがちな設定（削除が必要）:
  Other Linker Flags: -ObjC （Firebase SPM版では不要）
  Header Search Paths: $(PODS_ROOT)/...
  Library Search Paths: $(PODS_ROOT)/...
  Framework Search Paths: $(PODS_ROOT)/...

これらを削除した後、ビルドを走らせて通ることを確認します。ビルドが通れば基本的な移行は完了です。

落とし穴 1: Dropbox 競合コピー問題

ここが最も詰まった箇所でした。プロジェクトを Dropbox で同期しているため、SPM が生成する .swiftpm/xcuserdata ディレクトリが Dropbox の競合コピーを引き起こしたのです。

症状としては、Xcode を開くたびに error: cannot find module 'Firebase' in scope のエラーがエディタに表示されます。しかしビルドを実行すると通る——という不安定な状態です。エディタのインデックスが正常に機能せず、補完も壊れた状態になります。

原因は .swiftpm/xcuserdata を Dropbox が同期しようとして、複数の Mac 間でファイルロックの競合が起きていたことでした。CocoaPods 時代にも似た症状に当たったことがあるのですが、SPM では競合の起きるパスが変わるため、同じ穴にもう一度落ちました。

解決策は xattr コマンドで該当ディレクトリを Dropbox の同期対象外にすることです。

# プロジェクトのルートで実行
xattr -w com.dropbox.ignored 1 ".swiftpm"
xattr -w com.dropbox.ignored 1 "$(find . -name 'xcshareddata' -path '*swiftpm*' 2>/dev/null | head -1)"
 
# Derived Data が Dropbox 内にある場合も同様に
# （通常は ~/Library/Developer/Xcode/DerivedData に置くことを推奨）

この設定を適用した後、Xcode を完全に終了し、Dropbox の同期が完了するのを待ってから再起動します。再起動後はエディタのエラーが消えて正常な状態に戻ります。xattr による Dropbox 除外は再起動後も維持されるため、一度設定すれば以後の操作で繰り返す必要はありません。

Dropbox でプロジェクトを管理している個人開発者の方は、移行前にこのステップを先に済ませておくと、後から詰まるのを防げます。

なお、Dropbox の競合コピーが発生した場合は「ファイル名 (競合しているコピー 〜).xcuserdata」のようなファイルが生成されます。これが .xcodeproj 内に混入すると、Xcode が同名のファイルが2つあると判断してエラーになることがあります。移行後に原因不明のビルドエラーが出た場合は、プロジェクト内の競合コピーファイルを検索してみてください。

落とし穴 2: dSYM アップロードスクリプトのパス変更

Firebase Crashlytics を使っている場合、クラッシュのシンボル解析のために dSYM ファイルをアップロードするビルドフェーズスクリプトが必要です。CocoaPods 版での設定はこうなっていました。

# CocoaPods 版（旧・移行後は動かない）
"${PODS_ROOT}/FirebaseCrashlytics/run"

SPM 移行後は $PODS_ROOT が存在しないため、このスクリプトはビルドエラーになります。この問題が厄介なのは、スクリプトがサイレントに失敗する設定になっていた場合、ビルドは通るのに dSYM がアップロードされず、App Store Connect でクラッシュレポートがシンボル化されないという状況が続くことです。

SPM 版での正しいパスは以下の通りです。

# Swift Package Manager 版（新）
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"

このパスが Xcode のバージョンや DerivedData の場所によって変わることを考慮して、動的に検索するスクリプトを使うとより堅牢です。

#!/bin/bash
# Firebase Crashlytics dSYM upload — SPM版
# Xcode の Run Script Build Phase に追加
 
FIREBASE_RUN=$(find "${BUILD_DIR%Build/*}SourcePackages/checkouts" \
  -name "run" \
  -path "*/Crashlytics/run" \
  2>/dev/null | head -1)
 
if [ -z "$FIREBASE_RUN" ]; then
  echo "warning: Firebase Crashlytics run script not found."
  exit 0
fi
 
"$FIREBASE_RUN"

また、Build Settings → Debug Information Format が Release ビルドで DWARF with dSYM File になっているかを必ず確認してください。DWARF のみではシンボルファイルが出力されず、クラッシュレポートで行番号が表示されません。

Release ビルドの設定:
  ✅ DWARF with dSYM File → シンボル化されたクラッシュレポートが見られる
  ❌ DWARF のみ → 行番号なし、アドレスのみ表示

落とし穴 3: ビルドの編集時エラーが消えない

SPM 移行直後によく起きる問題として、ビルドは通るのに Xcode エディタ上で module 'FirebaseCore' not found のエラーが赤く表示され続けることがあります。補完も壊れた状態になります。

これは Xcode のインデックスキャッシュが古い状態のままになっているために起きます。

# ステップ1: Derived Data を削除
rm -rf ~/Library/Developer/Xcode/DerivedData/<AppName>-*
 
# その後 Xcode を再起動
 
# ステップ2: Clean Build Folder (Cmd+Shift+K)
 
# ステップ3: File → Packages → Reset Package Caches

この3ステップで大抵は解消されます。それでも残る場合は、プロジェクトを閉じてから .xcodeproj を再度開き直すと直ることがほとんどです。初回移行後に1〜2回発生しますが、以後は安定します。

この現象は移行直後のほか、Xcode のメジャーアップデート後にも発生することがあります。その場合も同じ手順で解消できます。Derived Data の削除は「プロジェクトを壊す操作」ではなく「ビルドキャッシュを再構築させる操作」なので、躊躇わずに実行してください。削除した Derived Data は次回のビルド時に自動的に再生成されます。

移行後のビルド時間最適化

Firebase を SPM で追加した後、初回フルビルドが以前より大幅に遅くなるケースがあります。これは SPM パッケージの初回コンパイルキャッシュが生成されるためで、正常な動作です。しかし毎回遅い場合は対応が必要です。

Build Phases の Run Script で「Based on dependency analysis」を有効にすると、変更がない場合はスクリプトの実行をスキップするようになります。

Build Phases → Run Script（各フェーズ）
→ ✅「Based on dependency analysis」にチェックを入れる
→ Firebase Crashlytics の dSYM スクリプトも毎回実行しなくなる

Relaxing Healing では、この設定を有効にした後で差分ビルド時間が6分から約90秒に戻りました。コードを書いている間はフルビルドではなく差分ビルドが走るため、この設定の効果は日常的な開発体験に直結します。

4本を並行して保守していると、1本のビルドが遅いだけでその日の切り替え回数が目に見えて減ります。差分ビルドを90秒台に戻せたことは、移行そのものよりも日々の作業に効きました。

残り3本への展開——パターン化による効率化

Relaxing Healing での経験をもとに、残り3本（Beautiful HD Wallpapers・Ukiyo-e・Law of Attraction）の移行を行いました。各アプリ共通の事前準備リストを作ることで、1本あたりの移行時間を短縮できました。

最初の Relaxing Healing では試行錯誤で4時間かかりましたが、2本目以降は平均30分程度で完了しました。その差を生んだのは主に2点——Dropbox 競合コピーへの先手対応と、dSYM スクリプトのテンプレートを使い回せたことです。

#!/bin/bash
# pre-spm-migration.sh — 各アプリの移行前に実行
 
echo "1. CocoaPods を除去..."
pod deintegrate
 
echo "2. Podfile 関連ファイルを削除..."
rm -f Podfile Podfile.lock
rm -rf Pods/
 
echo "3. Dropbox 同期除外を設定..."
xattr -w com.dropbox.ignored 1 ".swiftpm" 2>/dev/null || true
 
echo "4. 現在の dSYM スクリプト内容をバックアップ..."
grep -r "PODS_ROOT.*Crashlytics" . --include="*.pbxproj" > dSYM_backup.txt 2>/dev/null || true
 
echo "完了。Xcode で .xcodeproj を開いて Firebase を Package Dependencies から追加してください。"

このスクリプトを実行してからXcodeを開くことで、移行後に遭遇する典型的な問題のうち2つを予防できます。

AppLovin MAX メディエーションとの共存

Beautiful HD Wallpapers では AdMob メディエーションに AppLovin MAX を利用しています。AppLovin MAX の iOS SDK も CocoaPods で管理していたため、Firebase と同時に SPM 移行を検討しました。

AppLovin MAX は SPM 対応済みですが、メディエーションアダプタ（Liftoff・InMobi・Unity Ads）が個別に SPM 対応しているかを確認する必要があります。2026年5月時点では主要アダプタの多くが SPM 対応済みですが、マイナーなアダプタでは CocoaPods のみの場合があります。対応状況は各パートナーの公式ドキュメントで確認してください。

AppLovin MAX SPM 移行確認リスト（2026-05時点）:
✅ AppLovin MAX SDK 本体: SPM 対応済み
✅ Liftoff アダプタ: SPM 対応済み
✅ InMobi アダプタ: SPM 対応済み
✅ Unity Ads アダプタ: SPM 対応済み
⚠️ 一部マイナーアダプタ: 要個別確認

AppLovin MAX を CocoaPods から SPM に移行する場合、Firebase と同じ手順で進められます。ただし AppLovin MAX は独自の設定ファイル（AppLovinSettings.plist）が必要なため、移行後にプロジェクトへの追加を忘れないようにしてください。

Rork Max ユーザーへの注意点——プロジェクト再生成時のPodfile復活

Rork Max でプロジェクトを管理している場合、プロジェクトの再生成時に Podfile が復元される可能性があります。

Rork Max は iOS プロジェクトを生成する際に、設定によっては Podfile を含むプロジェクト構造を出力します。SPM 移行後に Rork Max でコードを再生成した場合、手動で削除した Podfile が復活しないよう注意が必要です。

対処法を2つご紹介します。

方法A: Rork Max のプロジェクト設定で CocoaPods を無効にする（バージョンによって対応状況が異なります）。

方法B: Rork Max での再生成後に実行する確認スクリプトをワークフローに組み込む。

#!/bin/bash
# post-rork-generate.sh — Rork Max 再生成後に必ず実行する
 
if [ -f "Podfile" ]; then
  echo "⚠️  Podfile が検出されました（Rork Max が再生成した可能性）"
  echo "🗑  CocoaPods ファイルを削除して SPM の設定を保持します..."
  rm -f Podfile Podfile.lock
  rm -rf Pods/
  echo "✅  削除完了。Xcode で Package Dependencies を確認してください。"
fi

このスクリプトは2秒で完了しますが、見落としによるサイレント移行戻りを防ぐ重要な安全網です。Rork Max でコードの再生成を行う頻度が高い方は、CI パイプラインに組み込んでおくと安心です。

Firebase バージョン管理——移行後の更新戦略

SPM 移行後のもう一つのメリットは、Firebase SDK のバージョン管理が Xcode の UI だけで完結することです。CocoaPods では pod update Firebase をターミナルで実行し、Podfile.lock の差分を目で追う必要がありましたが、SPM では Xcode の「Package Dependencies」タブから GUI でバージョンを更新できます。

ただし、Firebase のメジャーバージョンアップ時は破壊的変更が含まれることがあります。私が実践しているのは、まず1本のアプリで新バージョンを試してから残りのアプリに展開するという段階的な更新です。Relaxing Healing が先行検証アプリの役割を果たしており、そこで問題がなければ他のアプリに同じバージョンを適用します。

バージョン指定には「Up to Next Major Version」を使うのが一般的ですが、安定性を優先する場合は「Exact Version」を指定しておき、意図したタイミングだけ更新するという方法もあります。個人開発でアプリが安定して動いているなら、メジャーバージョンの更新は変更ログを確認してからにすることをお勧めします。

Firebase SDK のバージョンアップ情報は GitHub のリリースページや公式ブログで確認できます。特にメジャーリリース前後は Crashlytics と Analytics の初期化コードの書き方が変わることがあります。

私自身、リリースノートを読み飛ばしたままマイナー更新を適用し、Analytics の自動収集イベントの扱いが変わっていたことに数日経ってから気づいたことがあります。焦らず、TestFlight で確認してからリリースするペースを保つほうが、結局は速いと感じています。

移行後の動作確認チェックリスト

SPM 移行が完了したら、以下の項目を実機で確認します。

□ アプリが起動する（クラッシュなし）
□ Firebase Analytics のイベントが Firebase Console に届いている
□ テストクラッシュ（Crashlytics.crashlytics().crash()）が記録される
□ dSYM がシンボル化されている（App Store Connect で行番号確認）
□ Release ビルドで Archive → Distribute が完走する
□ TestFlight にアップロードして実機で動作確認
□ Build Settings に $(PODS_ROOT) の参照がゼロ件
□ プロジェクトルートに Podfile がない

dSYM のシンボル化確認が最も見落とされやすい項目です。Archive 直後に Firebase Console の Crashlytics ページでテストクラッシュを確認して、スタックトレースに行番号とクラス名が表示されているかを目視してください。アドレスのみが表示されている場合は dSYM アップロードが機能していません。

全体を振り返って——余裕のある今のうちに1本だけ移行してみる

CocoaPods の廃止まで時間はあるように見えて、移行中に想定外の問題が出ると追い詰められます。最初の Relaxing Healing では4時間かかりましたが、そのほとんどは Dropbox 競合と dSYM スクリプトのパス問題の調査時間でした。

Rork Max を使っている方はプロジェクト再生成後の Podfile 復活に注意してください。それ以外の移行手順は一般的な iOS プロジェクトと変わりません。

まず1本を移行してみることをお勧めします。Firebase のモジュールが最も少ないアプリから始めると、学習コストを低く抑えられます。Relaxing Healing での4時間の試行錯誤がこの記事に詰まっているので、きっと最初から30〜60分で終えられると思います。

同じ課題に取り組んでいる方の参考になれば幸いです。

移行後しばらくは Crashlytics のダッシュボードを通常より頻繁に確認することをお勧めします。移行直後に見落としていた設定ミスがクラッシュレポートの欠落として表れることがあります。1週間問題なく動いていれば、移行は完全に成功したと判断していいでしょう。それまでの間は App Store の更新を控えて、まず TestFlight で様子を見るのが安全です。