◉ANTIGRAVITY LABEN
← ブログ一覧

Antigravity で iOS 4本の Firebase SDK を CocoaPods から SPM に移行する — 1日で終えるための順序設計

AntigravityFirebaseSwift Package ManagerCocoaPodsiOS個人開発SDK 移行

5月の連休明け、iOSアプリ「Relaxing Healing」のリポジトリで pod install を走らせたら、Firebase の更新通知に「2026年10月で CocoaPods 配信を停止します」という案内が混じっていました。Beautiful HD Wallpapers、Ukiyo-e Wallpapers、Law of Attraction Everyday を含めると、私の手元には Firebase Crashlytics と Analytics を組み込んだ iOSアプリが合計4本あります。10月までに全部 Swift Package Manager（SPM）に切り替える必要があると気づいた瞬間、頭の中で「半日 × 4本 = 2日」というざっくり見積もりが立ちました。

実際にやってみると、Antigravity に任せられる部分と、自分の判断で進めるしかない部分の線引きが意外にはっきりしていて、結果的に丸1日で4本すべての移行を終えられました。今日はその順序設計と、途中でぶつかった落とし穴を残しておきます。

まず Relaxing Healing 1本だけで「移行レシピ」を作る

4本同時に手を出すと、どこで何を間違えたかが分からなくなります。私はまず Relaxing Healing をパイロットに選びました。理由は単純で、4本の中でいちばん依存している Pod が少なく、検証コストが小さいからです。2014年から個人開発を続けていて学んだのは、不確実性のあるタスクほど「小さく試す」順序が最終的にいちばん速い、という教訓です。

Antigravity に最初に頼んだのは、Podfile を読んで「SPM に置き換えた場合の URL と最小バージョンの対応表を Markdown で出して」という指示でした。Firebase の公式 URL https://github.com/firebase/firebase-ios-sdk と、各サブパッケージ（FirebaseAnalytics、FirebaseCrashlytics、FirebaseRemoteConfig）の対応関係を1枚の表にしてくれて、これがそのまま4本分の移行チェックリストになりました。

# Podfile から SPM に置き換える前の状態（Relaxing Healing）
target 'RelaxingHealing' do
  pod 'Firebase/Analytics'
  pod 'Firebase/Crashlytics'
  pod 'Firebase/RemoteConfig'
  pod 'GoogleMobileAds'
end

SPM 側で対応するのは firebase-ios-sdk の3つのプロダクトと、Google Mobile Ads の SPM 対応版です。Antigravity がここで一覧化してくれたおかげで、後の3本では「またこの対応表を作る」という手戻りが発生しませんでした。

CocoaPods を完全に剥がす順序を間違えない

ここがいちばん事故が起きやすい工程です。私は最初、勢いで pod deintegrate を叩いてしまい、.xcworkspace ごと開けなくなって30分ほど復旧に費やしました。正しい順序は、「Xcode を閉じる → Pods を残したまま SPM を追加する → ビルドが通ることを確認する → そのあとで CocoaPods を剥がす」です。

Antigravity の Inline Agent に「この順序をシェルスクリプトにして、各ステップの前で read -n 1 で待たせてほしい」と頼んだら、こちらの呼吸に合わせて止まってくれる移行スクリプトが10分で出てきました。手動操作とエージェントの自動化の境目を、自分のリスク許容度で決められるのが Antigravity の良いところだと感じています。

#!/usr/bin/env bash
# Firebase SDK 移行スクリプト（CocoaPods → SPM）
set -e
 
echo "[1/4] Xcode を閉じてください。閉じたら何かキーを押してください"
read -n 1
 
echo "[2/4] SPM 経由で firebase-ios-sdk を追加します"
echo "      Xcode > File > Add Package Dependencies"
echo "      URL: https://github.com/firebase/firebase-ios-sdk"
read -n 1
 
echo "[3/4] Release ビルドが通るか確認してください"
echo "      ✅ 通ったらキー入力、失敗したら Ctrl+C"
read -n 1
 
echo "[4/4] CocoaPods を剥がします"
pod deintegrate
rm -f Podfile Podfile.lock
rm -rf Pods .xcworkspace
 
echo "✅ 移行完了。git diff で確認してから commit してください"

このスクリプトを4本すべてで使い回した結果、2本目以降は1本あたり40分前後で終わりました。最初の1本だけ2時間半かかったのは、「やらない選択肢」を1つずつ手で確かめていたからです。

dSYM upload Run Script が消えていないか必ず確認する

CocoaPods で Firebase Crashlytics を入れていたとき、ビルドフェーズに ${PODS_ROOT}/FirebaseCrashlytics/run を呼び出す Run Script が自動挿入されていました。SPM に切り替えると、この Run Script がプロジェクトに残ったまま参照先が消えるので、Release ビルドで「No such file or directory」のエラーが出ます。

私はこの罠を Relaxing Healing で踏みました。Antigravity の Browser エージェントに「Firebase Crashlytics の SPM 移行時にビルドフェーズで起きる典型的なエラーをまとめて」と聞いておけばよかった、と移行後に思いました。実際、4本目の Beautiful HD Wallpapers では事前に同じ質問を投げて、Run Script の置き換え先を確認してから手を動かしました。

SPM 環境での正しい Run Script はこうなります。

# Build Phases > Run Script
${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run

Input Files には $(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH) と ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME} を追加しておくと、TestFlight 配信時に dSYM が正しくアップロードされて、後でクラッシュが起きてもシンボル化された状態で読めます。

メディエーション SDK は同じタイミングで触らない

4本のアプリには Google Mobile Ads と AppLovin MAX のメディエーション（Liftoff、InMobi、Unity Ads）が入っています。私は当初、「ついでに AdMob まわりも整理してしまおう」と考えましたが、途中で手を止めました。Firebase の SDK 移行と AdMob のメディエーション設定変更は、原因切り分けが難しくなる組み合わせだからです。

両方を同時に触ると、リリース後にもし広告 eCPM が下がっても、「Firebase 側の変更が原因か、メディエーション側の構成変更か」を切り分けるためにロールバックの幅が広がりすぎます。Antigravity の Manager Surface でブランチを分けて、SPM 移行は migration/firebase-spm、メディエーション更新は feature/admob-mediation-iframe のように完全に切り離しました。

個人開発で長くアプリ事業を続けていると、「一度に1つだけ変える」という制約が結果的にいちばん速いと身体で覚えます。AdMob 月間収益を 100万円を超えるレベルで維持してこられたのも、リリースのたびに「何を変えたか」を1行で説明できる状態を保ってきたからだと感じています。

4本同時運用で見えてきた Antigravity の使いどころ

移行を終えてから振り返ると、Antigravity が貢献した工程は次の3つに集中していました。1つ目は「対応表の生成」のような、人間がやると単調で間違いやすい作業の代行。2つ目は「順序を守ってくれるラッパー」を作って、自分の集中力を要所だけに使えるようにする支援。3つ目は「過去の自分が踏んだ罠を引き出す」ためのインタビュー相手。逆に、最終判断（CocoaPods をいつ剥がすか、TestFlight にいつ上げるか）はすべて自分の手元に残しました。

10月の CocoaPods 配信停止まで、Firebase 以外にもまだ移行が必要な SDK がいくつか残っています。次はメディエーション側を1本ずつ整えていく予定で、その記録もまたこちらに残していこうと思います。同じく4本以上の iOSアプリを抱えている個人開発者の方の参考になれば嬉しいです。

firebase-ios-sdk の SPM 移行手順は公式ドキュメント Firebase Apple SDK on GitHub にも記載がありますが、メディエーションを含む実運用での順序設計は意外に書かれていません。今回の記録がその空白を少し埋められたらと思っています。