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 を完全に削除できました。

実際の移行手順——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 間でファイルロックの競合が起きていたことでした。2014年からアプリ開発をしてきて、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本のビルドが遅いだけで1日の作業効率が大幅に落ちます。ビルド時間を短縮することで生まれた余裕は、コードの品質向上やアプリの新機能追加に充てられます。「速いビルド」は開発者の集中力を保つ上でも重要で、ビルドを待つ間に別のことに気を取られるのを防いでくれます。

残り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 では とターミナルで実行する必要がありましたが、SPM では Xcode の「Package Dependencies」タブから GUI でバージョンを更新できます。

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

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

Firebase SDK のバージョンアップ情報は GitHub のリリースページや公式ブログで確認できます。特にメジャーリリース前後は Crashlytics と Analytics の初期化コードの書き方が変わることがあります。リリースノートを丁寧に読む習慣が重要です。2013年以来アプリを運営してきた経験から言えば、アップデートを慌てて適用して壊した経験もあります。焦らず、テスト環境で確認してからリリースするペースを保つのが長続きの秘訣だと感じています。

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

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 で様子を見るのが安全です。