Migrating Firebase CocoaPods to SPM in Rork Max Apps

Pre-Migration: Auditing Your CocoaPods Dependencies

Before removing anything, list every pod in your Podfile and verify SPM availability for each one.

# Relaxing Healing Podfile (before migration)
platform :ios, '14.0'
use_frameworks!
 
target 'RelaxingHealing' do
  pod 'Firebase/Core'
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Analytics'
  pod 'Firebase/Performance'
end

The SPM equivalents map directly:

• Firebase/Core → FirebaseCore
• Firebase/Crashlytics → FirebaseCrashlytics
• Firebase/Analytics → FirebaseAnalytics (or FirebaseAnalyticsWithoutAdIdSupport)
• Firebase/Performance → FirebasePerformance

One decision to make on Analytics: the standard FirebaseAnalytics includes IDFA access. If your app doesn't request ATT authorization, FirebaseAnalyticsWithoutAdIdSupport avoids review friction. My apps all use ATT prompts, so I stayed with the standard variant.

If you have non-Firebase pods that don't have SPM support, you won't be able to remove Podfile entirely. You can run Firebase through SPM while keeping other dependencies in CocoaPods — it's a supported configuration, just slightly more to manage. For all four of my apps, Firebase was the only CocoaPods dependency, so I could do a clean removal.

Record Your Resolved Versions Before Deleting Podfile.lock

One ordering decision paid off more than anything else here: pin the Firebase version in SPM to whatever is currently building, before you change anything else.

If you delete Podfile.lock along with the rest of CocoaPods and then pick "Up to Next Major Version" in Xcode's Package Dependencies, you have just done two migrations at once — CocoaPods to SPM, and one Firebase version to another. When something breaks after that, you can't tell whether it's the package manager or the SDK. That's exactly what happened on Relaxing Healing, and it cost me roughly an extra hour chasing a linker error that turned out to be unrelated to SPM.

Capture the resolved versions first:

# Extract only the resolved Firebase versions from Podfile.lock
grep -E '^[[:space:]]+- Firebase' Podfile.lock | sed 's/^[[:space:]]*//'
 
# Example output
#   - Firebase/Analytics (11.8.0)
#   - Firebase/Core (11.8.0)
#   - Firebase/Crashlytics (11.8.0)
#   - Firebase/Performance (11.8.0)

Enter that version in Xcode as an Exact Version, and split the migration into two commits so each class of failure has an unambiguous cause:

Once commit 1 builds, Xcode generates Package.resolved. Commit that file. It plays the same role Podfile.lock did — without it under version control, a fresh clone on another machine can silently resolve to different versions. Its location depends on your project structure, so search for it rather than guessing:

find . -name "Package.resolved" -not -path "*/DerivedData/*"
# .../MyApp.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved

Create a Restore Point Before Running pod deintegrate

pod deintegrate is not a command that deletes your Podfile. It rewrites the inside of .xcodeproj — build phases, xcconfig references, framework linkage. If you decide midway that you want to go back, reconstructing that by hand is not realistic.

I assumed Dropbox version history had me covered. It didn't. An .xcodeproj is a bundle of files, and Dropbox restores one file at a time — it's the wrong tool for rolling a project back to a consistent state.

Make a git restore point first:

# Commit and tag before touching anything
git add -A
git commit -m "chore: snapshot before SPM migration"
git tag pre-spm-relaxing-healing
 
# If you need to go back (restores Podfile, Podfile.lock, and .xcodeproj together)
git checkout pre-spm-relaxing-healing -- .
pod install

While you're there, stop tracking the working files SPM generates. Skipping this is how fragments of the Dropbox conflict copies described below end up committed:

# Add to .gitignore
.swiftpm/
DerivedData/
*.xcworkspace/xcuserdata/
*.xcodeproj/xcuserdata/

The app name in the tag matters more than it looks. Working through four apps in sequence, a bare pre-spm tag stops telling you which project it belongs to by the second one.

Step-by-Step Migration — The Relaxing Healing Walkthrough

Step 1: Remove CocoaPods Completely with pod deintegrate

Don't just delete the Podfile — run pod deintegrate first to cleanly remove all CocoaPods integration artifacts from your .xcodeproj.

cd /path/to/RelaxingHealing
pod deintegrate
 
# Remove Podfile and related files
rm -f Podfile Podfile.lock
rm -rf Pods/

After this, use .xcodeproj directly in Xcode. The .xcworkspace file was generated by CocoaPods and is no longer needed once Pods are gone.

Step 2: Add Firebase via Swift Package Dependencies

In Xcode, with your .xcodeproj open:

1. Select the project in the navigator
2. Open the Package Dependencies tab
3. Click + to add a package
4. Enter https://github.com/firebase/firebase-ios-sdk
5. Choose a version (latest stable recommended)
6. Select only the modules you actually use

✅ FirebaseCore
✅ FirebaseCrashlytics
✅ FirebaseAnalytics
✅ FirebasePerformance

Only check what you were using via CocoaPods. Adding modules you don't need increases binary size and build time. The first package resolution downloads the full SDK and takes a few minutes. Subsequent builds use cached packages and are significantly faster.

Step 3: Remove CocoaPods Residue from Build Settings

Even after pod deintegrate, some CocoaPods-injected settings can linger. Open Build Settings in Xcode and search for PODS. Remove any remaining references.

Things to check and remove:
  Other Linker Flags: -ObjC (usually only needed for CocoaPods)
  Header Search Paths: $(PODS_ROOT)/... entries
  Library Search Paths: $(PODS_ROOT)/... entries

Build the project and confirm it compiles cleanly before moving on.

Pitfall 1: Dropbox Conflict Copies Corrupting SPM Index

This was the most time-consuming problem I ran into, and it's completely undocumented.

I sync my projects through Dropbox across multiple Macs. After adding Firebase via SPM, Xcode creates .swiftpm/xcuserdata directories inside the project. Dropbox aggressively syncs these, and when Xcode was open on two machines simultaneously, the file locking conflicts corrupted SPM's package index.

The symptom: error: cannot find module 'Firebase' in scope appeared in the editor persistently, even though clean builds succeeded. Autocomplete stopped working. The inconsistency between editor behavior and build results is the signature of this problem.

The fix is to mark the affected directories as Dropbox-ignored using xattr:

# Run from your project root
xattr -w com.dropbox.ignored 1 ".swiftpm"
xattr -w com.dropbox.ignored 1 "$(find . -name 'xcshareddata' -path '*swiftpm*' 2>/dev/null | head -1)"

After applying this, quit Xcode, let Dropbox finish syncing, then reopen the project. The module errors cleared up immediately and have not recurred.

I encountered similar Dropbox sync issues with CocoaPods' xcuserdata directories back when I started using this setup in 2014. SPM's paths are different, but the underlying problem is the same. If you manage iOS projects in Dropbox, apply this fix before opening the project in Xcode for the first time after migration.

Pitfall 2: The dSYM Upload Script That Breaks Silently

Firebase Crashlytics requires a Run Script build phase to upload dSYM files for crash symbolication. The CocoaPods version references $(PODS_ROOT):

# Old CocoaPods version — breaks after migration
"${PODS_ROOT}/FirebaseCrashlytics/run"

After removing CocoaPods, this path doesn't exist. Depending on how your Run Script phase is configured, this either causes a build error or fails silently — the latter being worse, because builds succeed but your crash reports in App Store Connect will show unsymbolicated hex addresses instead of file names and line numbers. You won't notice the problem until you're looking at an actual user crash.

The SPM replacement path:

# Swift Package Manager version
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"

For a more robust version that's resilient to DerivedData location changes:

#!/bin/bash
# Firebase Crashlytics dSYM upload — SPM version
 
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. Skipping."
  exit 0
fi
 
"$FIREBASE_RUN"

Also check this setting, which is easy to overlook:

Build Settings → Debug Information Format
Release: DWARF with dSYM File   ← Required for symbolication to work
(NOT just "DWARF" — that omits dSYM output entirely)

Pitfall 3: Editor Module Errors That Persist After Successful Builds

A common post-migration symptom: the app builds and runs correctly, but Xcode's editor shows persistent red underlines on Firebase imports with module 'FirebaseCore' not found. Autocomplete is broken. Everything looks wrong but actually works.

This is a stale Xcode index cache. The fix:

# Step 1: Delete Derived Data for your app
rm -rf ~/Library/Developer/Xcode/DerivedData/<AppName>-*
 
# Then: restart Xcode
 
# Step 2: Product → Clean Build Folder (Cmd+Shift+K)
 
# Step 3: File → Packages → Reset Package Caches

This three-step sequence resolves it almost every time. If the errors persist, close the project completely and reopen the .xcodeproj. I've seen this issue occur once or twice after the initial migration; after that, it doesn't come back.

Build Performance After Migration

The first full build after adding Firebase via SPM is noticeably slower — SPM compiles and caches packages fresh. This is expected. The issue is if every subsequent build is also slow.

If incremental builds are slower than before, check your Run Script build phases. Any script running unconditionally adds time on every build. Enable "Based on dependency analysis" on scripts that don't need to run when nothing has changed:

Build Phases → Each Run Script phase
→ ✅ Check "Based on dependency analysis"
→ The Firebase Crashlytics dSYM script will only run when the binary changes

Enabling this on Relaxing Healing brought incremental build times from about 6 minutes back down to around 90 seconds. The difference matters significantly during active development when you're building frequently.

Expanding to the Other Three Apps

With Relaxing Healing done, I migrated Beautiful HD Wallpapers, Ukiyo-e Wallpapers, and Law of Attraction Everyday using a consistent pre-migration script:

#!/bin/bash
# pre-spm-migration.sh — run before opening each project in Xcode
 
echo "1. Deintegrating CocoaPods..."
pod deintegrate
 
echo "2. Removing CocoaPods files..."
rm -f Podfile Podfile.lock
rm -rf Pods/
 
echo "3. Setting Dropbox ignore attributes..."
xattr -w com.dropbox.ignored 1 ".swiftpm" 2>/dev/null || true
find . -name "xcshareddata" -path "*swiftpm*" \
  -exec xattr -w com.dropbox.ignored 1 {} \; 2>/dev/null || true
 
echo "4. Backing up current dSYM script path..."
grep -r "PODS_ROOT.*Crashlytics" . --include="*.pbxproj" \
  > dSYM_backup.txt 2>/dev/null || true
 
echo "Done. Open .xcodeproj in Xcode and add Firebase via Package Dependencies."

Running this script first meant the Dropbox conflict issue and the dSYM path problem were both pre-empted before I even opened Xcode. The Relaxing Healing migration took 4 hours of debugging; each of the other three took about 30 minutes.

Coexisting With AppLovin MAX Mediation

Beautiful HD Wallpapers uses AppLovin MAX for AdMob mediation, and its iOS SDK was also managed through CocoaPods. That raised an obvious question: migrate both at once, or one at a time?

AppLovin MAX itself supports SPM. The variable is the mediation adapters — each partner adapter is a separate package, and SPM support arrived at different times for each. As of May 2026, the adapters I depend on were all available:

AppLovin MAX SPM readiness (checked 2026-05):
✅ AppLovin MAX SDK core: SPM supported
✅ Liftoff adapter: SPM supported
✅ InMobi adapter: SPM supported
✅ Unity Ads adapter: SPM supported
⚠️ Smaller / regional adapters: verify individually

Check each adapter against its partner's own documentation rather than assuming parity with the core SDK — that's where a mediation stack tends to break.

The migration steps are identical to Firebase. The one thing easy to forget is that AppLovin MAX needs its own AppLovinSettings.plist in the project; removing the Pods directory does not remove that requirement, but a careless cleanup can remove the file.

I migrated Firebase first and left AppLovin MAX on CocoaPods for two weeks. Keeping the ad stack unchanged meant that if revenue moved, I knew it wasn't the mediation layer.

Managing Firebase Versions After Migration

One practical benefit of SPM over CocoaPods: version updates happen entirely within Xcode's UI. No terminal commands, no Podfile edits. From the Package Dependencies tab, you can see the current version of each package and update with a click.

For major version updates, Firebase occasionally introduces breaking changes. My practice is to test a new major version on one app before rolling it out to all four. Relaxing Healing serves as the pilot — if it runs cleanly for a week in TestFlight, I apply the same version to the others.

On version strategy: "Up to Next Major Version" is the default, which means Xcode will automatically pull minor and patch updates. For apps running stably in production, I prefer "Exact Version" for major packages so updates happen deliberately rather than automatically. I've had minor Firebase updates change logging behavior unexpectedly in the past, and controlling when updates happen makes it easier to isolate the cause of any new issues.

The Firebase SDK release notes are published on GitHub and in the Firebase blog. Major releases typically include a migration guide. Reading the release notes before updating has saved me debugging time more than once.

Rork Max Specific: Podfile Restoration After Project Regeneration

If you use Rork Max to manage your project, be aware that project regeneration can restore the Podfile you deleted.

Rork Max generates iOS project structure based on your configuration, and depending on your settings, it may output a Podfile as part of that structure. After SPM migration, if you regenerate the project with Rork Max for any reason, you might find a fresh Podfile has silently appeared.

Two ways to handle this:

Option A: Check Rork Max's project settings for a way to disable CocoaPods generation (availability varies by version).

Option B: Add a post-generation validation step to your workflow:

#!/bin/bash
# post-rork-generate.sh — run after any Rork Max project regeneration
 
if [ -f "Podfile" ]; then
  echo "⚠️  Podfile detected — possibly restored by Rork Max regeneration"
  echo "🗑  Removing to preserve SPM migration..."
  rm -f Podfile Podfile.lock
  rm -rf Pods/
  echo "✅  Removed. Verify Package Dependencies in Xcode."
fi

This script takes a couple of seconds and prevents silent regressions that are easy to miss in the middle of an active development session.

Post-Migration Verification Checklist

Before submitting to App Store, confirm:

□ App launches cleanly on physical device
□ Firebase Analytics events appear in Firebase Console (within ~1 hour)
□ Force crash (Crashlytics.crashlytics().crash()) registers in Crashlytics dashboard
□ Crash report shows symbolicated stack trace with file names and line numbers
□ Release Archive → Distribute App completes without errors
□ TestFlight build installs and runs on device
□ No $(PODS_ROOT) references remain in Build Settings
□ No Podfile present in project root

The symbolication check is the one most commonly skipped. You need to explicitly confirm that a crash report shows file names and line numbers — not just hex addresses. The only way to know dSYM upload is working correctly is to trigger a test crash and verify what appears in the Crashlytics dashboard.

Start With One App

The migration itself is straightforward once you know where the pitfalls are. The Dropbox sync issue and the dSYM script path change are not in Firebase's official migration documentation, but both are likely if your development setup resembles mine.

If you're using Rork Max, the Podfile restoration issue is the only additional concern. Everything else maps directly to standard Xcode iOS migration.

Start with your simplest app — fewest Firebase modules, lowest traffic in case something goes wrong. Run it through TestFlight for a few days before submitting an App Store update. Then apply the same approach to each remaining app in sequence.

October 2026 will arrive whether the migration is done or not. Starting now means you control the timing.

Thank you for reading — I hope this saves you some of the debugging hours I spent getting here.