Docs

Firebase iOS SDK Drops CocoaPods: Migration Tracking

Firebase's Apple SDK stops publishing to CocoaPods after October 2026 — what to instrument before an iOS migration silently breaks analytics.

Analytics

Google has confirmed that new versions of the Firebase Apple SDK will stop being published to CocoaPods after October 2026, pushing every iOS team still on Pods toward Swift Package Manager. On paper it’s a dependency-manager swap. In practice it’s the kind of change that breaks analytics quietly rather than loudly: a migration can compile cleanly, pass a manual smoke test, and still ship with Crashlytics symbolication broken, Analytics events firing to the wrong config, or a stale SDK version pinned because a transitive dependency didn’t resolve the way the old Podfile did.

The risk is concentrated in exactly the code most teams don’t retest carefully — SDK initialisation and crash reporting, because both fail silently. A misconfigured GoogleService-Info.plist reference or a dSYM upload step wired to the old build phase won’t throw a build error; it’ll just mean a percentage of crashes stop symbolicating, or a chunk of users stop appearing in Analytics, and nobody notices until a monthly report looks light. Teams that treat this as a mechanical package-manager swap, rather than a re-validation of the whole analytics pipeline, are the ones who find out three weeks later.

Data Points to Track

  • Firebase SDK version and integration method (CocoaPods vs. Swift Package Manager) tagged on every session, so a post-migration data anomaly can be isolated to the exact build that switched
  • Crash symbolication success rate, tracked before and after migration — a drop here is the clearest signal a dSYM or build-phase step didn’t carry over
  • session_start and first-open event volume per build version, to catch initialisation failures that silently drop the events analytics dashboards depend on most
  • Build phase / CI step completion for dSYM upload, logged as pass/fail per release, not assumed from a green build
  • Bundle ID and GoogleService-Info.plist checksum per build, to catch a stale or mismatched config file carried over from the old dependency setup

Setup Steps

  1. Migrate one build to Swift Package Manager in a separate branch first, and run it against a staging Firebase project so a broken pipeline doesn’t touch production data.
  2. Re-add the dSYM upload build phase explicitly rather than assuming Xcode’s SPM integration carries over the same script Pods generated automatically.
  3. Force a test crash and confirm it symbolicates in Crashlytics before merging the migration, not after the next real crash arrives.
  4. Compare session_start and first-open counts for a day of SPM traffic against the CocoaPods baseline, watching for a drop that would indicate an initialisation problem.
  5. Pin the exact Firebase SDK version in the SPM manifest rather than taking .upToNextMajor, so a future automatic bump doesn’t reintroduce the same class of silent failure.

Actionable Insights

The migration itself isn’t optional past October 2026, so the useful question is whether your analytics pipeline is instrumented well enough to catch a regression before it costs you a month of data. Version-tagging every event and comparing crash symbolication and session-start volume across the CocoaPods and SPM builds turns an invisible failure mode into a same-day alert. Teams that skip that comparison are relying on a monthly dashboard review to catch what a same-day version-tagged check would have flagged immediately.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert