In May 2026, I migrated Firebase Apple SDK from CocoaPods to Swift Package Manager across four of my iOS apps. Google has announced that CocoaPods-based distribution for Firebase will end in October 2026 — a hard deadline, not just a deprecation warning.
As a solo developer running an app business with over 50 million cumulative downloads, "managing deadline-driven migrations safely" is part of the job. I used Antigravity as a diagnostic partner throughout the process, migrating Beautiful HD Wallpapers, Ukiyo-e Wallpapers, Relaxing Healing, and Law of Attraction Everyday one by one.
Three specific issues caused friction. Here's what I ran into and how I resolved each one.
Why You Should Act Now — Understanding the Timeline
CocoaPods distribution for Firebase Apple SDK stops in October 2026. This isn't a soft deprecation — it means pod install will eventually fail to fetch the package.
New projects have effectively defaulted to SPM already, but apps built before 2020 often rely on CocoaPods. My oldest app has code written 12 years ago, and the Podfile had grown complex over the years. A simple copy-paste migration wasn't going to work.
I ran a pilot migration on relaxing-healing (Relaxing Healing) first, validated the process, then applied the same patterns to the remaining three apps.
Pitfall 1: Dropbox Conflict Copies Breaking the Build
The first issue had nothing to do with Firebase directly.
After migrating to SPM, .swiftpm/xcuserdata/ started syncing through Dropbox. When I switched between machines, Dropbox generated conflict copies (file (conflicted copy ...)), which broke the build silently.
I described the symptom to Antigravity, and it immediately suggested the xattr fix:
# Tell Dropbox to ignore this directory
xattr -w com.dropbox.ignored 1 build/Pods/.swiftpm/xcuserdataAfter converting to an Xcode workspace, the same issue reappeared for workspace-related paths:
xattr -w com.dropbox.ignored 1 YourApp.xcodeproj/project.xcworkspace/xcuserdataThese two commands eliminated the mysterious build failures. You won't find this in Firebase's official migration docs — it's an environment-specific issue that appears when you combine SPM with Dropbox-synced projects.
Pitfall 2: Crashlytics dSYM Upload Silently Failing
After the first TestFlight submission post-migration, crash reports started arriving as "Unsymbolicated." Crashlytics stopped symbolicating stack traces.
With CocoaPods, the Pods-*.sh script was automatically wired into Build Phases. After moving to SPM, that script was gone — and nothing replaced it automatically.
When I described the symptom to Antigravity ("Crashlytics stopped symbolicating after SPM migration"), it walked me through the correct Build Phase setup:
# Build Phases → New Run Script Phase
# For SPM (Xcode 15+), use the SourcePackages path:
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"
# Input Files:
# ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${TARGET_NAME}Equally important: checking Build Settings to confirm the Release scheme generates dSYM files:
Build Settings → Debug Information Format → DWARF with dSYM File
Without that setting, there's no dSYM file to upload in the first place.
From describing the symptom to Antigravity to applying the fix took about 30 minutes. Finding this independently would have cost most of a workday.
Pitfall 3: AdMob Mediation Partners Not Supporting SPM
All four apps include AdMob mediation. While Firebase itself is fully SPM-compatible, several mediation partners — Liftoff, InMobi, and Unity Ads among them — still distribute via CocoaPods only.
My solution: a hybrid approach. Firebase moved to SPM; mediation partners stayed in Podfile.
# Podfile (Firebase removed — handled by SPM)
platform :ios, '14.0'
target 'YourApp' do
# Mediation partners that don't yet support SPM
pod 'LiftoffMonetize-Sdk'
pod 'InMobiSDK'
pod 'UnityAds'
endI asked Antigravity whether mixing SPM (for Firebase) with CocoaPods (for mediation) would cause problems. The answer: technically fine, and Apple supports this configuration.
All four apps are running this hybrid setup without issues. Once mediation partners ship SPM support, the Podfile can be removed entirely.
Where Antigravity Added the Most Value
The strongest capability I noticed in this migration was working from symptoms backward to causes.
CocoaPods → SPM errors are often opaque. "Module 'FirebaseCore' not found" could mean a stale Package.resolved, a missing framework link in target settings, or a cache issue — the error message doesn't tell you which.
Antigravity's response to symptom descriptions consistently prioritized the most likely cause first:
# First diagnostic steps Antigravity recommended
rm -rf ~/Library/Developer/Xcode/DerivedData
# Then in Xcode: File → Packages → Reset Package Caches
# Then: Product → Clean Build FolderThe symptom → hypothesis → diagnostic step loop is slow when done manually. Antigravity handles it in seconds, which kept the migration moving at a steady pace across all four apps.
Build Time After Migration
A quick note on build performance: initial builds after migration were slower, because Xcode downloads and compiles Swift source packages from scratch. Subsequent builds matched CocoaPods performance once Derived Data was cached.
One thing to check before migrating: Derived Data grows larger with SPM. If your development machine is running low on storage, clear space first.
Next Step
If you're managing multiple apps with Firebase and haven't started this migration yet, the most practical approach is to pilot one app — ideally the simplest one — document what you encounter, and apply those patterns to the rest.
The October 2026 deadline is specific enough to plan around. Starting with a pilot now leaves time to handle anything unexpected before the cutoff.