Just after Japan's May holidays, I ran pod install in the Relaxing Healing repository and noticed a Firebase update notice quietly announcing that CocoaPods distribution for the Apple SDK will end in October 2026. Counting Beautiful HD Wallpapers, Ukiyo-e Wallpapers, and Law of Attraction Everyday, I have four iOS apps that all embed Firebase Crashlytics and Analytics. The moment that fact registered, I sketched a rough estimate in my head: half a day per app, two days total.
In practice, the line between what Antigravity could handle and what I had to handle myself was surprisingly clear, and all four migrations finished within a single day. Today I want to leave behind the sequencing that made that possible, along with the traps I stepped into along the way.
Build the migration recipe on Relaxing Healing first
Touching all four apps in parallel guarantees that when something breaks, you cannot tell where. I chose Relaxing Healing as the pilot for a simple reason: it depends on the fewest Pods, so verification is cheap. After running an indie iOS business since 2014, one lesson has stuck with me — the more uncertain a task feels, the faster "try it small first" turns out to be in the end.
My first request to Antigravity was to read the Podfile and produce a Markdown table mapping each Pod to its SPM equivalent and minimum version. It returned a single sheet covering the Firebase iOS SDK URL https://github.com/firebase/firebase-ios-sdk and each sub-product (FirebaseAnalytics, FirebaseCrashlytics, FirebaseRemoteConfig). That sheet became the migration checklist for the remaining three apps, which meant I never had to rebuild it.
# Podfile before SPM migration (Relaxing Healing)
target 'RelaxingHealing' do
pod 'Firebase/Analytics'
pod 'Firebase/Crashlytics'
pod 'Firebase/RemoteConfig'
pod 'GoogleMobileAds'
endOn the SPM side, that maps to three products from firebase-ios-sdk and the SPM-compatible Google Mobile Ads package. Having Antigravity codify this once saved real time on app two through four.
Do not get the CocoaPods removal order wrong
This is the step where accidents happen. The first time, I ran pod deintegrate too eagerly and ended up unable to open the .xcworkspace at all — recovering took about thirty minutes. The correct order is: close Xcode, add SPM packages while Pods are still installed, confirm the build passes, then remove CocoaPods.
I asked Antigravity's Inline Agent to turn that order into a shell script that pauses on each step with read -n 1. Within ten minutes I had a migration script that breathed at my pace. Choosing where the boundary sits between manual control and agent automation, based on my own risk tolerance, is one of the things Antigravity does well.
#!/usr/bin/env bash
# Firebase SDK migration (CocoaPods → SPM)
set -e
echo "[1/4] Close Xcode. Press any key when ready."
read -n 1
echo "[2/4] Add firebase-ios-sdk via SPM"
echo " Xcode > File > Add Package Dependencies"
echo " URL: https://github.com/firebase/firebase-ios-sdk"
read -n 1
echo "[3/4] Verify a Release build succeeds"
echo " Press any key if green, Ctrl+C if it fails"
read -n 1
echo "[4/4] Removing CocoaPods"
pod deintegrate
rm -f Podfile Podfile.lock
rm -rf Pods .xcworkspace
echo "✅ Migration done. Review with git diff before committing."Reusing this script on all four apps brought the per-app time down to about forty minutes from app two onward. Only the first app took two and a half hours, because I was hand-verifying every "do not skip this" assumption.
Watch for the leftover dSYM upload Run Script
When Firebase Crashlytics was installed via CocoaPods, Xcode had a Run Script in the build phases pointing at ${PODS_ROOT}/FirebaseCrashlytics/run. Switching to SPM leaves that Run Script in place while removing the file it points to, so Release builds fail with "No such file or directory".
I tripped over this on Relaxing Healing. With hindsight, I should have asked Antigravity's Browser Agent up front for a summary of the typical errors that surface during a Firebase Crashlytics SPM migration. By the time I got to Beautiful HD Wallpapers as the fourth app, I asked the same question first and confirmed the new Run Script path before touching anything.
The correct Run Script under SPM looks like this:
# Build Phases > Run Script
${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/runAdding $(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH) and ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME} to Input Files makes sure dSYMs upload correctly during TestFlight distribution, so any future crashes come back symbolicated.
Do not touch mediation SDKs at the same time
All four apps run Google Mobile Ads with AppLovin MAX mediation (Liftoff, InMobi, Unity Ads). My first instinct was, "while I'm in here, let me clean up the AdMob side too." I caught myself partway through. Firebase SDK migration plus AdMob mediation reshuffling is exactly the combination that makes post-release diagnosis hard.
If both move at once and eCPM dips after release, you cannot cleanly tell whether the Firebase change or the mediation reshuffling caused it, and your rollback surface gets uncomfortably wide. In Antigravity's Manager Surface I kept the branches fully separated — migration/firebase-spm for the SPM work and feature/admob-mediation-iframe for the mediation update.
Years of running an indie app business teach you that "change one thing at a time" is, against intuition, the fastest constraint. Keeping monthly AdMob revenue above the seven-figure-yen mark for years has been less about brilliance and more about being able to summarize what changed since the last release in a single sentence.
Where Antigravity earned its keep across four apps
Looking back, Antigravity contributed in three concentrated places. First, generating the kind of mapping table that humans get wrong out of fatigue. Second, wrapping a sequence so my attention only had to land on the parts that mattered. Third, acting as an interviewer that pulled traps out of my own past memory before I hit them again. The final calls — when to remove CocoaPods, when to push to TestFlight — stayed with me.
October's CocoaPods cutoff still leaves a few other SDKs that need attention. The mediation side is next, one app at a time, and I will probably keep a record of that here as well. If you also maintain four or more iOS apps as an indie developer, I hope this sequencing helps you skip a few of the half-day detours I took.
The SPM migration steps for firebase-ios-sdk are documented at Firebase Apple SDK on GitHub, though the real-world sequencing across multiple apps with mediation tends to be left as an exercise for the reader. I hope this record fills a small part of that gap.