您的 iOS 应用运行在 Firebase Cloud Messaging 上。推送已送达。一切正常。然而，每一个细分营销活动、每一次 A/B 测试以及每一个“我们能否发送关于促销活动的推送”的请求，仍然会落入您的工程队列，因为 FCM 只为您提供了一个推送通道，除此之外别无他物。如果这听起来很熟悉，那么本指南将向您展示如何从 iOS 的 Firebase Cloud Messaging 迁移 — 而不丢失任何订阅者、强制重新安装或向用户显示第二次权限提示。
简而言之：在 iOS 上，迁移是一次层级替换，而不是重建。原因如下，以及具体的操作方法。
FCM 能为您做什么，以及它的局限性
Firebase Cloud Messaging 是免费、可靠的基础设施。对于许多工程团队来说，它是默认选择，并且对于纯粹的推送送达来说，它是一个不错的选择。当您的营销团队想要开展营销活动时，问题就出现了。
| 功能 | FCM | PushEngage |
|---|---|---|
| 通过 APNs 进行通知送达 | 是 | 是 |
| 行为细分 | 仅主题 | 动态细分、属性、地理位置、设备 |
| 从应用事件触发的营销活动 | 自行构建 | 仪表板配置 |
| 渐进式系列和流程 | 自行构建 | 可视化构建器、模板 |
| A/B 测试 | 通过 Firebase 控制台，由开发人员驱动 | 营销人员驱动，智能获胜者选择 |
| 收入归因和目标跟踪 | 否 | 按营销活动、按工作流程 |
| 营销人员可访问的仪表板 | 否 | 是 |
该表格中的模式是团队最终会超越 FCM 的原因：除了推送送达之外的所有内容都是一个工程项目。有关完整比较，请参阅 PushEngage vs Firebase Cloud Messaging。
在 iOS 上实际迁移的内容
迁移的担忧几乎总是围绕着订阅者列表：“如果我们更换 SDK，我们会丢失已选择加入的用户吗？”在 iOS 上，答案是否定的，了解原因很有帮助。
iOS 上的通知权限属于您的应用，而不是任何 SDK。当用户授予权限时，他们授予的是您的 bundle ID，Apple 会向您的应用颁发一个 APNs 设备令牌，任何推送提供商都可以使用该令牌。FCM 在 iOS 上本身就是该 APNs 令牌的包装器。当 PushEngage SDK 首次初始化时，它会获取相同的应用级别权限，将设备令牌注册到 PushEngage，订阅者即可上线 — 无需重新安装，无需重新提示，用户无需执行任何操作。
这意味着当您的已选择加入的用户在更新的应用版本上线后，您的已选择加入的基础用户群就会随之转移。典型的发布会在两到三周内覆盖绝大多数活跃用户，这正是您应该计划同时运行两个系统的窗口期。
迁移步骤详解
步骤 1：添加 PushEngage SDK
通过 Swift Package Manager（推荐）或 CocoaPods 进行安装。 1.0 版本包含两个模块：将 PushEngage 链接到您的应用目标，将 PushEngageExtension 链接到您的 Notification Service Extension 目标。
# Podfile
target 'YourApp' do
pod 'PushEngage', '~> 1.0.0'
end
target 'YourNotificationServiceExtension' do
pod 'PushEngageExtension', '~> 1.0.0'
end步骤 2：与现有设置并行初始化
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
}由于应用层级已授予权限，现有订阅者在首次启动更新版本时会自动注册到 PushEngage。新用户将正常经历一次权限流程。
步骤 3：配置应用组
为您的应用目标和每个通知扩展目标添加应用组功能，使用相同的组 ID，并在每个 Info.plist 中声明它。这是应用及其扩展共享订阅者状态的方式，也是大多数集成错误的根源。
步骤 4：将您的 APNs 密钥指向 PushEngage
在 PushEngage 控制台中上传您现有的 .p8 认证密钥（或 .p12 证书）——与您提供给 Firebase 的凭据相同。您的 Apple 开发者设置不会改变。 设置指南 屏幕将详细介绍此过程。
步骤 5：验证，然后发布
从控制台向调试设备发送测试通知，确认富媒体通过扩展程序正确渲染，并确认订阅者出现在您的受众视图中。然后发布。随着更新的推出，您在 PushEngage 中的订阅者数量会自动增长。
在过渡期间同时运行两个系统
您不需要也不应该进行硬切换。对于您的后端已发送的任何交易性消息，请继续使用 FCM，并在订阅者注册时将营销消息发送转移到 PushEngage。两个 SDK 可以在同一个应用中共存——它们会消耗相同的 APNs 令牌。一旦您的活跃用户群重新注册并且您的广告系列已完全迁移，移除 Firebase Messaging 依赖项将是一项清理任务，而不是一个截止日期。
您的营销团队第一天就能获得什么
此次迁移的重点不在于 SDK——而在于之后不再是工程部门的工单。通过控制台，您的营销团队可以根据您的应用跟踪的任何事件构建 触发式广告系列，使用 行为细分 来筛选受众，运行渐进式旅程，进行文案 A/B 测试，并通过目标跟踪来归因每个广告系列的收入。集成后，您的参与仅限于在团队需要新的触发器时使用 trackEvent 进行插桩——这是一个单行调用。
坦诚地说，成本问题
FCM 的推送是免费的，如果您只需要原始推送功能，请继续使用它。当您评估 PushEngage 时，您是在为营销层定价——细分、自动化、归因以及您的营销团队可以独立操作的控制台。 定价仅随活跃订阅者数量扩展，因此拥有大量活跃用户但参与度不高的用户群不会增加账单，而不断缩小的列表会减少账单。我们在 Firebase 推送通知定价 中详细分解了实际成本比较。
开始迁移
将 Firebase Cloud Messaging 从 iOS 迁移过来，只需要一个下午的集成和一次发布周期的耐心：添加 SDK，共享 App Group，上传你已有的 APNs 密钥，然后让发布重新注册你的基础。无需重新安装，无需丢失订阅者，无需第二次权限提示——并且推送活动不再需要等待一个冲刺周期。如果你想要策略背景信息，请从应用推送营销指南开始，或者直接使用 SDK，本周即可上线。所有付费套餐均提供 14 天退款保证。
