In October 2026, Firebase Apple SDK will officially stop distributing via CocoaPods. I stumbled on this in a release note, and as someone who has been running four iOS apps independently since 2014 — with a cumulative total of over 50 million downloads — the deadline felt suddenly real.
My apps span wallpaper, relaxation, and positive-thinking categories, and some have years of accumulated code. A few have CocoaPods and Swift Package Manager already coexisting in the same project. Migrating carefully was going to take time.
I chose Beautiful HD Wallpapers as the first test case. It has a clean Firebase setup — Crashlytics and Analytics only — making it a safe pilot before I touch the others.
What Makes the Migration Tricky
The official migration guide looks straightforward on paper. In practice, a few things can go wrong.
Dropbox conflict copies are one issue if your Xcode project lives in a Dropbox folder. After deleting the Pods/ directory, Dropbox starts syncing .xcuserdata and related files in the middle of SPM resolution, which can leave Xcode holding stale or corrupt references. Strange build errors that don't point anywhere useful tend to follow.
The dSYM upload script disappearing is another. When CocoaPods managed Firebase, it also owned the Run Script phase that called Pods/FirebaseCrashlytics/run. Remove CocoaPods and that phase is gone — Crashlytics stops receiving symbols, and your crash reports pile up as "unsymbolicated" without any clear warning.
These are exactly the kinds of gaps that don't show up in official documentation but do show up in solo development. Claude Code helped me surface them before I hit them.
The Claude Code Workflow
Before touching anything, I had Claude Code read the Xcode project structure and Podfile, then asked it to enumerate every Firebase-related Pod and lay out the SPM migration steps — specifically including the Crashlytics dSYM configuration.
claude "Read the Podfile in this project and give me a step-by-step
plan for replacing Firebase-related Pods with SPM packages.
Pay special attention to Crashlytics dSYM upload configuration."The response included "you'll need to manually re-add the Run Script phase" — a detail that pre-empted what would otherwise have been a puzzling debugging session after the migration.
The xattr Trick for Dropbox
The most practical suggestion Claude Code offered was this xattr command:
# Exclude these directories from Dropbox sync before deintegrating CocoaPods
xattr -w com.dropbox.ignored 1 YourProject.xcodeproj/project.xcworkspace/xcuserdata
xattr -w com.dropbox.ignored 1 Pods
# Also exclude SPM's user data directory
xattr -w com.dropbox.ignored 1 .swiftpm/xcuserdataRunning these before pod deintegrate keeps Dropbox from creating conflict copies during the transition. Neither CocoaPods documentation nor Firebase's migration guide mentions this — it's the kind of thing you only learn by working in a Dropbox-backed project for years.
Restoring the dSYM Run Script
After switching to SPM, Crashlytics needs a manually configured Run Script in Build Phases:
# Add to Build Phases → Run Script
# Shell: /bin/sh
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"Alongside this, verify that your Scheme's Archive setting uses DWARF with dSYM File — not just DWARF. Without the dSYM file, the upload script finishes silently and sends nothing. I found two apps in my set where this had drifted to the wrong value.
Fixing ATT Prompt Ordering While I Was There
The Firebase migration gave me a good moment to also audit the AdMob initialization flow. ATT (App Tracking Transparency) prompt ordering matters more than it might seem:
// ✅ Correct: request ATT authorization before initializing the ads SDK
ATTrackingManager.requestTrackingAuthorization { status in
GADMobileAds.sharedInstance().start(completionHandler: nil)
}
// ❌ Incorrect: initializing ads SDK before ATT result is known
GADMobileAds.sharedInstance().start(completionHandler: nil)
// ATT prompt appears later...If the SDK initializes before the ATT authorization is returned, it assumes the user has not consented and configures tracking accordingly. That means lower eCPM for impressions that should have been eligible for personalized ads. For an indie developer, AdMob revenue is real money — this is worth getting right.
What the Migration Felt Like
The Beautiful HD Wallpapers migration took about a day from start to finish. I verified Crashlytics was working by triggering a forced crash in a debug build and confirming the symbolicated stack trace appeared correctly in Firebase Console.
The remaining three apps — Ukiyo-e Wallpapers, Law of Attraction Everyday, and Relaxing Healing — now have a tested playbook to follow.
What Claude Code contributed most was preventing omissions. When you're working alone, it's easy to miss a step between "remove CocoaPods" and "verify the release build actually uploads symbols." Having something that reads your actual project and sequences the work for you is different from reading documentation. It's closer to having a second pair of eyes on the checklist.
If you're running iOS apps with Firebase and haven't started the SPM migration yet, October is closer than it looks. And if your project is inside a Dropbox folder, don't skip the xattr step.
For setting up Claude Code with Xcode from scratch, Claude Code × Xcode — Setup and Practical Guide for iOS/macOS Developers covers the full environment setup.