Your iOS app runs on Firebase Cloud Messaging. Delivery works. Nothing is on fire. And yet every segmented campaign, every A/B test, and every “can we send a push about the sale” request still lands in your engineering queue, because FCM gives you a delivery pipe and nothing else. If that sounds familiar, this guide shows you how to migrate from Firebase Cloud Messaging on iOS — without losing a subscriber, forcing a reinstall, or showing your users a second permission prompt.
The short version: on iOS, migration is a layer swap, not a rebuild. Here’s why, and exactly how to do it.
What FCM gives you, and where it stops
Firebase Cloud Messaging is free, reliable infrastructure. For a lot of engineering teams it is the default choice, and for pure delivery it is a fine one. The problem shows up the day your marketing team wants to run campaigns.
| Mogelijkheid | FCM | PushEngage |
|---|---|---|
| Notification delivery via APNs | Ja | Ja |
| Behavioral segmentation | Topics only | Dynamic segments, attributes, geo, device |
| Triggered campaigns from app events | Build it yourself | Dashboard-configured |
| Drip series and journeys | Build it yourself | Visual builder, templates |
| A/B-testen | Via Firebase console, developer-driven | Marketer-driven, smart winner selection |
| Revenue attribution and goal tracking | Nee | Per campaign, per workflow |
| Marketer-accessible dashboard | Nee | Ja |
The pattern in that table is the reason teams outgrow FCM: everything beyond delivery is an engineering project. For the full comparison, see PushEngage vs Firebase Cloud Messaging.
What actually migrates on iOS
The migration fear is almost always about the subscriber list: “if we swap SDKs, do we lose our opted-in users?” On iOS, the answer is no, and it helps to understand why.
Notification permission on iOS belongs to your app, not to any SDK. When a user granted permission, they granted it to your bundle ID, and Apple issues your app an APNs device token that any push provider can use. FCM on iOS is itself a wrapper around that APNs token. When the PushEngage SDK initializes for the first time, it picks up the same app-level permission, registers the device token with PushEngage, and the subscriber is live — no reinstall, no re-prompt, no action from the user at all.
That means your opted-in base carries over as devices come online with the updated app version. A typical release reaches the large majority of active users within two to three weeks, which is exactly the window you should plan to run both systems in parallel.
The migration, step by step
Step 1: Add the PushEngage SDK
Install via Swift Package Manager (recommended) or CocoaPods. The 1.0 release ships as two modules: link PushEngage to your app target and PushEngageExtension to your Notification Service Extension target.
# Podfile
target 'YourApp' do
pod 'PushEngage', '~> 1.0.0'
end
target 'YourNotificationServiceExtension' do
pod 'PushEngageExtension', '~> 1.0.0'
endStep 2: Initialize alongside your existing setup
import PushEngage
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
PushEngage.setAppID(id: "YOUR_APP_ID")
PushEngage.setInitialInfo(for: application, with: launchOptions)
return true
}Because permission is already granted at the app level, existing subscribers register with PushEngage silently on their first launch of the updated build. New users go through your normal permission flow once.
Step 3: Configure the App Group
Add the App Groups capability to your app target and every notification extension target, using the same group ID, and declare it in each Info.plist. This is how the app and its extensions share subscriber state, and it is the step most integration bugs trace back to.
Step 4: Point your APNs key at PushEngage
Upload your existing .p8 authentication key (or .p12 certificate) in the PushEngage dashboard — the same credential you gave Firebase. Nothing about your Apple developer setup changes. The setup guide covers this screen by screen.
Step 5: Verify, then ship
Send a test notification from the dashboard to a debug device, confirm rich media renders through the extension, and confirm the subscriber appears in your audience view. Then release. Your subscriber count in PushEngage grows automatically as the update rolls out.
Run both systems during the transition
You do not need a hard cutover, and you should not do one. Keep FCM in place for anything transactional your backend already sends, and move marketing sends to PushEngage as subscribers register. Both SDKs can coexist in the same app — they are consuming the same APNs token. Once your active base has re-registered and your campaigns have fully moved, removing the Firebase Messaging dependency is a cleanup task, not a deadline.
What your marketing team gets on day one
The point of this migration is not the SDK — it is what stops being an engineering ticket afterward. From the dashboard, your marketing team can build triggered campaigns off any event your app tracks, cut the audience with behavioral segmentation, run drip journeys, A/B test copy, and attribute revenue per campaign with goal tracking. Your involvement after integration is instrumenting new events with trackEvent — a one-line call — when the team wants a new trigger.
The cost question, honestly
FCM’s delivery is free, and if raw delivery is all you need, keep it. What you are pricing when you evaluate PushEngage is the marketing layer — segmentation, automation, attribution, and a dashboard your marketing team can operate alone. Pricing scales only with active subscribers, so a large install base with mixed engagement does not inflate the bill, and a shrinking list shrinks it. We’ve broken down the real cost comparison in Firebase push notification pricing.
Make the move
Migrating from Firebase Cloud Messaging on iOS is an afternoon of integration and a release cycle of patience: add the SDK, share the App Group, upload the APNs key you already have, and let the rollout re-register your base. No reinstalls, no lost subscribers, no second permission prompt — and no more push campaigns waiting on a sprint. Start with the app push marketing guide if you want the strategy context, or go straight to the SDK and ship it this week. Every paid plan carries a 14-day money-back guarantee.
