Firebase CocoaPods support is ending. What happens to iOS push notifications?

After October 2026, pod update FirebaseMessaging will not get you the latest Firebase Messaging fixes. Firebase says it will stop publishing new Firebase Apple SDK versions to CocoaPods, so if an iOS, Xcode, APNs, or Firebase change affects push delivery, your CocoaPods-based app may be stuck on the wrong side of the fix.

That is the uncomfortable part of the Firebase CocoaPods migration. Firebase is not pulling old pods from the registry, so pod install can still pass, CI can still go green, and your app can still ship.

But new Firebase Apple SDK releases will move through Swift Package Manager or manual installation. If your app uses Firebase Cloud Messaging through CocoaPods, FirebaseMessaging can quietly become the old part of your push pipeline.

Push notifications depend on a long chain: APNs registration, FCM token mapping, backend targeting, iOS display rules, and tap handling. When one part of that chain gets stuck on an aging SDK, failures do not always look like build errors. They look like missing notifications, stale tokens, broken analytics callbacks, or bugs that show up after an Xcode or iOS upgrade.

TL;DR

• Firebase stops publishing new Firebase Apple SDK versions to CocoaPods in October 2026, including FirebaseMessaging.
• CocoaPods trunk becomes read-only on December 2, 2026, so the public registry stops accepting new pod versions.
• Existing Firebase CocoaPods versions will remain available. Your current app will not stop working overnight.
• To keep receiving Firebase updates, you should migrate Firebase iOS dependencies to Swift Package Manager (SPM) or use manual XCFramework installation.
• If you use Firebase Cloud Messaging on iOS, treat this as a notification reliability project, not only a dependency-manager cleanup.
• After migration, test APNs registration, FCM token generation, foreground notifications, background notifications, silent pushes, cold-start tap handling, and any analytics callbacks.

What this means for your app

Firebase CocoaPods migration is primarily a push notification risk if your app uses FirebaseMessaging. That SDK sits between your app, APNs, FCM tokens, notification callbacks, and notification analytics. Once Firebase stops publishing new Apple SDK versions to CocoaPods, any future FirebaseMessaging fixes or improvements will land somewhere else first: Swift Package Manager or manual installation.

The bad outcomes are concrete. You can end up with stale or hard-to-debug FCM token behavior. You can hit foreground or background delivery bugs after an iOS or Xcode upgrade and find that the fix is not coming through pod update. You can have CI passing while your app quietly builds against a frozen Firebase SDK stack.

The blast radius is not limited to push. You can also miss Firebase fixes for auth, Firestore, Crashlytics, Remote Config, and analytics. But if FirebaseMessaging is part of your iOS notification path, this is first and foremost a notification reliability deadline.

This guide focuses on that path: what changes, what does not change, how to audit FirebaseMessaging, and how to migrate Firebase from CocoaPods to Swift Package Manager without accidentally breaking APNs registration, FCM token generation, or notification delivery.

The Firebase and CocoaPods timeline

There are two related deadlines: Firebase's publishing cutoff and CocoaPods trunk read-only mode.

The gap between October and December also gives wrapper SDKs time to absorb the change, because frameworks like FlutterFire, Firebase Unity SDK, and Firebase C++ SDK depend on the native Firebase Apple SDK release cycle.

Will Firebase stop working with CocoaPods?

No. Firebase will not stop working with CocoaPods on the cutoff date.

Existing Firebase pod versions will remain available in the CocoaPods registry, and deployed apps using those versions will keep running. CI pipelines that run pod install against existing versions should also keep resolving those pods.

The change is about future updates. After October 2026, Firebase will stop publishing new Firebase Apple SDK versions to CocoaPods. If your app still depends on Firebase through a Podfile, you can keep building against old versions, but you will not receive new Firebase features, performance improvements, or critical bug fixes through CocoaPods.

That distinction matters. "My build still works" is not the same as "my notification infrastructure is healthy."

Why this matters for push notifications

If you use Firebase Cloud Messaging on iOS, the affected dependency is FirebaseMessaging. That SDK sits in the middle of your APNs and FCM registration flow. It maps APNs tokens to FCM registration tokens, handles notification callbacks, and supports Firebase's analytics behavior around notifications.

The risk is not that FirebaseMessaging disappears. The risk is that your app gets stuck on a frozen CocoaPods version while Firebase continues shipping updates somewhere else.

Here is the chain reaction to watch:

1. Your app pins Firebase through Podfile and Podfile.lock.
2. Firebase stops publishing new Apple SDK versions to CocoaPods.
3. Your FirebaseMessaging version stops receiving future updates through pod update.
4. Your app keeps shipping with an older push SDK while Xcode, iOS, APNs behavior, and Firebase continue moving.
5. Push issues become harder to debug because your app, CI pipeline, and provider SDK are no longer on the current supported path.

That is why this migration belongs on your notification reliability plan. If push is a critical channel for your product, you should not treat FirebaseMessaging CocoaPods migration as a last-minute dependency chore.

Which Firebase pods are affected?

Firebase says the CocoaPods change applies to all Firebase CocoaPods and their associated dependencies. That includes commonly used pods like:

• Firebase
• FirebaseAnalytics
• FirebaseAppCheck
• FirebaseAuth
• FirebaseCore
• FirebaseCrashlytics
• FirebaseDatabase
• FirebaseFirestore
• FirebaseFunctions
• FirebaseInstallations
• FirebaseMessaging
• FirebasePerformance
• FirebaseRemoteConfig
• FirebaseStorage

If you use Firebase through CocoaPods, assume you are affected unless you have confirmed that your app is already using Swift Package Manager or manual installation.

Audit your app before you migrate

Before you run pod deintegrate, figure out exactly where Firebase and CocoaPods show up in your project. This is especially important if you maintain more than one iOS app, a white-label app, or a cross-platform app where CocoaPods is hidden under a framework.

Start with the obvious files:

• Check for a Podfile.
• Check Podfile.lock for Firebase entries and pinned versions.
• Check for a generated .xcworkspace.
• Search for FirebaseMessaging, FirebaseCrashlytics, FirebaseAnalytics, FirebaseAuth, and FirebaseApp.configure().
• Confirm that GoogleService-Info.plist is included in the right app target.
• Search CI config for pod install, pod update, bundle exec pod install, or CocoaPods caching.

Then check your target configuration:

• Look at Build Phases for Crashlytics dSYM upload scripts and any custom Firebase-related scripts your project added.
• Look at Other Linker Flags for -ObjC, especially if you use Firebase Analytics.
• Check whether Firebase frameworks are linked directly in the target.
• Check whether you have multiple app targets, extensions, notification service extensions, or test targets that depend on Firebase.
• Check whether non-Firebase dependencies still require CocoaPods.

If your app uses push notifications, audit the registration flow too:

• Where do you call registerForRemoteNotifications()?
• Where do you receive the APNs token in didRegisterForRemoteNotificationsWithDeviceToken?
• Where do you set or read the FCM registration token?
• Do you rely on Firebase method swizzling?
• Do you manually forward notification callbacks to Firebase Messaging?
• Do you test foreground and background notification handling on a physical device?

This audit gives you the migration map. Without it, you are guessing.

Choose your migration path

Firebase recommends Swift Package Manager for new Apple projects, and for most existing apps it is the right migration target. But there are a few valid paths depending on your dependency graph.

Firebase warns that mixing CocoaPods and Swift Package Manager in the same target can create dependency cycles and build errors. Mixing dependency managers across separate targets can be workable during a migration, but avoid linking the same Firebase products through both systems in one target. Firebase's guidance is to use a single installation method for the target you are migrating.

If your non-Firebase dependencies do not support SPM yet, manual Firebase installation may be the more stable short-term bridge while you clean up the rest of the project.

How to migrate Firebase from CocoaPods to SPM

For a straightforward native iOS app, the Firebase Swift Package Manager migration usually follows this shape.

First, close Xcode. From the root of your iOS project, remove CocoaPods integration:

pod deintegrate

Then remove the generated workspace:

rm -rf YourApp.xcworkspace

Open the .xcodeproj file in Xcode, not the old .xcworkspace.

In Xcode:

1. Go to File > Add Package Dependencies.
2. Add the Firebase iOS SDK repository:

https://github.com/firebase/firebase-ios-sdk.git

3. Choose the Firebase version you want to use.
4. Add the Firebase products your target needs, such as FirebaseMessaging, FirebaseAnalytics, FirebaseCrashlytics, FirebaseAuth, or FirebaseFirestore.
5. Confirm each Firebase product is linked to the correct app target.

If you use a Package.swift manifest, Firebase dependencies look like this:

dependencies: [
  .package(
    name: "Firebase",
    url: "https://github.com/firebase/firebase-ios-sdk.git",
    from: "11.0"
  )
]

Then add the Firebase products to the target that needs them:

.target(
  name: "NotificationsApp",
  dependencies: [
    .product(name: "FirebaseMessaging", package: "Firebase"),
    .product(name: "FirebaseAnalytics", package: "Firebase"),
    .product(name: "FirebaseCrashlytics", package: "Firebase")
  ]
)

The version above is illustrative. Use the current Firebase Apple SDK version from Firebase's release notes when you migrate. Do not copy a version from an old blog post and call it done.

Firebase's official Swift Package Manager install path is https://github.com/firebase/firebase-ios-sdk.git. Some Firebase products use prebuilt binary targets internally, but you should follow Firebase's current SPM installation docs rather than switching to a different package URL unless Firebase explicitly recommends it.

Product-specific migration checks

Some Firebase products need extra attention after you move from CocoaPods to SPM.

Firebase Messaging

For FirebaseMessaging, verify both APNs and FCM token flow.

At minimum, confirm:

• Your app still requests notification permission.
• Your app still calls registerForRemoteNotifications().
• didRegisterForRemoteNotificationsWithDeviceToken still receives an APNs token.
• Firebase Messaging still receives or maps the APNs token.
• Messaging.messaging().token returns an FCM registration token.
• Foreground notifications still render or call your foreground handler.
• Background notifications still arrive on a physical device.
• Tapping a notification still routes the user to the expected screen.

If you disabled Firebase method swizzling with FirebaseAppDelegateProxyEnabled, check your manual callback forwarding carefully. Your code will compile fine while analytics, token mapping, or notification handling silently stops behaving the way you expect. Firebase's FCM receive docs call out a few places that need explicit wiring:

• application(_:didRegisterForRemoteNotificationsWithDeviceToken:) should set Messaging.messaging().apnsToken = deviceToken.
• Messaging.messaging().delegate should be set, and messaging(_:didReceiveRegistrationToken:) should still send token refreshes to your backend.
• userNotificationCenter(_:willPresent:) should call Messaging.messaging().appDidReceiveMessage(userInfo) if you rely on Firebase notification analytics for foreground notifications.
• userNotificationCenter(_:didReceive:) should call Messaging.messaging().appDidReceiveMessage(userInfo) for notification taps.
• application(_:didReceiveRemoteNotification:fetchCompletionHandler:) should call Messaging.messaging().appDidReceiveMessage(userInfo) for silent or background pushes.

If the token callbacks are missing after the migration, FCM tokens can go stale silently. If the notification callbacks are missing, delivery analytics and downstream handling can drift from what you expect. Either way, nobody notices until a campaign underdelivers.

Notification Service Extension

If your app uses rich push (images, mutable content, decryption, custom UI), your Notification Service Extension is a separate target with its own dependency graph. SPM does not link the extension automatically.

After moving Firebase to SPM, check:

• The NSE target lists FirebaseMessaging (and any other Firebase products it uses) under Frameworks and Libraries.
• The NSE bundle identifier, code signing, entitlements, and App Group memberships survived the workspace-to-project switch.
• The NSE's Info.plist still declares NSExtension correctly and the deployment target matches the main app.
• If you share code between the app and the NSE through an embedded framework, that framework still resolves its Firebase dependency under SPM.

Smoke test the NSE specifically by sending a push with mutable-content: 1 and an image attachment. If the image renders, your extension is linked and running. If only the text shows up, the extension is not getting invoked.

Firebase Analytics

Firebase Analytics may require the -ObjC linker flag, especially when included transitively. After migrating to SPM, check your target's Other Linker Flags and make sure Analytics events still appear where you expect.

Firebase Crashlytics

Crashlytics dSYM upload scripts change because the SDK no longer lives under PODS_ROOT.

With Swift Package Manager, Firebase documents the run script path as:

${BUILD_DIR%Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run

If your CI was calling a script from Pods/FirebaseCrashlytics, update that path and test symbol upload before you rely on Crashlytics for production crash visibility.

Firebase Performance

If you use Firebase Performance, include it in your post-migration smoke tests. Confirm FirebasePerformance is linked through SPM and that performance data still appears after a release build. Unlike Crashlytics, Firebase's general SPM install docs do not call out a separate Performance upload script, so avoid carrying over CocoaPods-specific build phase assumptions unless your project added custom Performance scripts.

Firebase App Check, Remote Config, Auth, and Firestore

These products are less likely to affect push delivery directly, but they can still affect launch behavior, authentication flows, feature flags, and data reads. After migration, test the startup path for every target that initializes Firebase.

Update CI/CD after removing CocoaPods

Your local Xcode project is only half the migration. Your CI pipeline probably has CocoaPods assumptions too.

Look for steps like:

bundle exec pod install --repo-update
xcodebuild -workspace YourApp.xcworkspace

After moving to SPM, you will likely build the project instead of the workspace. Resolve packages as a separate step first so dependency fetches do not eat into your build timeout, then build:

xcodebuild -resolvePackageDependencies \
  -project YourApp.xcodeproj \
  -scheme YourApp

xcodebuild \
  -project YourApp.xcodeproj \
  -scheme YourApp \
  -destination "generic/platform=iOS Simulator" \
  build

Splitting the resolve step also makes SPM caching easier on hosted runners because you can cache the resolved SourcePackages directory between jobs. Use generic/platform=iOS Simulator for build-only CI jobs. If you run tests, replace the destination with a simulator installed on your CI runner.

You may also need to update:

• Dependency caching, because SPM packages are resolved differently than CocoaPods.
• Build scripts that reference PODS_ROOT.
• Xcode project paths in Fastlane.
• Crashlytics symbol upload paths.
• Any CI job that assumes .xcworkspace exists.
• Any lockfile or dependency review process that previously watched Podfile.lock.

Run a clean CI build before merging the migration. A migration that works only on one developer machine is not finished.

Push notification smoke test after migration

Do not stop after the app builds. If you use Firebase push notifications on iOS, run a push notification smoke test on a physical device.

Use this checklist:

1. Install a fresh build. Delete the app first so you test registration from a clean state.
2. Request notification permission. Confirm the permission prompt appears when expected.
3. Register with APNs. Confirm didRegisterForRemoteNotificationsWithDeviceToken receives a token.
4. Confirm the FCM token. Log or inspect the token returned by Firebase Messaging.
5. Send a foreground notification. Confirm your foreground display or handler runs.
6. Send a background notification. Lock the device and confirm delivery.
7. Send a silent push with content-available: 1. Confirm the app wakes and application(_:didReceiveRemoteNotification:fetchCompletionHandler:) runs to completion.
8. Tap the notification while the app is in the background. Confirm the app foregrounds to the right place.
9. Kill the app, then tap a fresh notification. Cold-start tap routing is where deep link handlers usually break.
10. Reinstall the app and check token refresh. A fresh install should produce a new FCM token and report it to your backend.
11. Check analytics behavior. If you use Firebase notification analytics, confirm callbacks still fire.
12. Restart the app normally. Confirm token handling still works after a relaunch from a warm state.
13. Run the same test in CI or a release candidate build. Debug builds can hide production-only issues.

Simulators are better for push than they used to be. iOS 16 and later support drag-and-drop .apns files for local delivery testing, which is great for smoke checks during development. But real APNs delivery, background wakeups, and token behavior still need a physical device. That was true for the iOS 26 UISceneDelegate warning, and it is true here too.

What about React Native, Flutter, Unity, and C++?

You may be affected even if you never manually added pod 'FirebaseMessaging' to a native iOS project.

FlutterFire

Firebase says most Unity and Flutter developers do not need direct action for the Firebase migration itself, because updating to the latest SDKs should migrate the underlying Apple dependency manager to Swift Package Manager.

That does not mean you can ignore your iOS folder. If your Flutter app has other iOS dependencies managed through CocoaPods, you still need to audit those dependencies separately. Check ios/Podfile, ios/Podfile.lock, and your CI setup.

React Native Firebase

React Native apps often use CocoaPods under the hood for native iOS dependencies. If you use React Native Firebase, check your current React Native version, your React Native Firebase version, and your ios/Podfile.

Look for:

• @react-native-firebase/app
• @react-native-firebase/messaging
• Firebase pods in ios/Podfile.lock
• CI steps that run cd ios && pod install
• Any custom native modules that still require CocoaPods

React Native Firebase SPM support has been actively evolving, so verify against the current library docs before planning a migration.

Firebase Unity SDK and Firebase C++ SDK

Firebase says the transition also impacts distributions that wrap the native Firebase Apple SDK, including the Firebase Unity SDK and Firebase C++ SDK. If you manage underlying iOS dependencies through CocoaPods, follow Firebase's migration guidance for Apple apps and verify the wrapper SDK's current release notes.

Your action plan

Here is the practical order of operations.

Now

1. Audit your Podfile, Podfile.lock, .xcworkspace, Firebase imports, and CI pipeline.
2. Identify every Firebase product you use, especially FirebaseMessaging, FirebaseCrashlytics, and FirebaseAnalytics.
3. Check whether non-Firebase dependencies still require CocoaPods.
4. Decide whether SPM or manual installation is the right migration path.

Before October 2026

1. Migrate Firebase dependencies away from CocoaPods.
2. Update CI to build from the right project or workspace structure.
3. Update Crashlytics, Performance, Analytics, and Firebase Messaging integration details.
4. Run clean builds locally and in CI.

Before shipping

1. Run the push notification smoke test on physical devices.
2. Verify analytics, crash reporting, auth, remote config, and any other Firebase-backed flows.
3. Document the new dependency update process so future Firebase upgrades do not depend on old CocoaPods habits.

Wrapping up

The Firebase CocoaPods migration is not an emergency today, but it is a real deadline. October 2026 is when Firebase stops publishing new Apple SDK updates to CocoaPods. December 2, 2026 is when CocoaPods trunk becomes read-only.

If your app uses Firebase through CocoaPods, your existing build should keep working. But staying there means accepting a frozen Firebase update path. For notification-heavy apps, that is not a great long-term place to be.

Start with an audit. Move Firebase to Swift Package Manager or manual installation when your dependency graph is ready. Then test the parts that matter most: APNs registration, FCM token generation, push delivery, notification tap handling, and your CI release pipeline.

Push notifications are only reliable when the whole chain is reliable. Your package manager is now part of that chain.

Frequently asked questions

What is CocoaPods?

CocoaPods is a dependency manager for Apple app projects. You list third-party SDKs in a Podfile, run pod install, and CocoaPods downloads those libraries, wires them into Xcode, and generates an .xcworkspace for the app. For years, it was one of the default ways to install SDKs like Firebase in iOS apps.

Will Firebase stop working with CocoaPods in 2026?

No. Existing Firebase CocoaPods versions will remain available, and apps using those versions will keep working. The change is that Firebase stops publishing new Apple SDK versions to CocoaPods in October 2026.

When does Firebase stop publishing Apple SDK updates to CocoaPods?

Firebase will stop publishing new Firebase Apple SDK versions to CocoaPods in October 2026.

When does CocoaPods become read-only?

CocoaPods trunk is scheduled to become permanently read-only on December 2, 2026. After that, the central registry will not accept new pod versions or new podspecs.

Do I need to migrate Firebase to Swift Package Manager?

If you want to keep receiving new Firebase Apple SDK updates, yes, you should migrate away from CocoaPods. Firebase recommends Swift Package Manager for most Apple projects, with manual installation available for projects that need it.

Can I keep using Firebase CocoaPods after 2026?

You can keep using existing Firebase pod versions, but you will be pinned to versions published before Firebase's October 2026 cutoff unless you take on your own private podspec maintenance.

Does CocoaPods read-only affect Firebase Messaging?

Yes. FirebaseMessaging is one of the Firebase Apple SDK pods affected by the CocoaPods publishing cutoff. Existing versions will remain available, but future updates will not be published to CocoaPods after October 2026.

How do I test push notifications after migrating Firebase to SPM?

Test on a physical device. Confirm APNs registration, FCM token generation, foreground delivery, background delivery, silent pushes with content-available: 1, cold-start tap handling, and any Firebase analytics callbacks you rely on.

Should I remove CocoaPods entirely?

That depends on your other dependencies. Firebase recommends avoiding mixed CocoaPods and SPM usage in the same target because it can create dependency cycles and build errors. Mixing dependency managers across separate targets can be workable during a migration, but avoid linking the same Firebase products through both systems in one target. If you use use_frameworks! in your Podfile, watch for modular header conflicts when you start mixing in SPM-linked Firebase. If non-Firebase dependencies still require CocoaPods, consider manual Firebase installation as a bridge while you migrate the rest of the project.