お使いのiOSアプリはFirebase Cloud Messagingで実行されています。配信は機能しています。何も燃えていません。それでも、すべてのセグメントキャンペーン、すべてのA/Bテスト、「セールについてプッシュを送信できますか」というリクエストは、FCMは配信パイプを提供するだけで、それ以上のものは提供しないため、エンジニアリングキューに届きます。それが聞き覚えのあるものであれば、このガイドでは、サブスクライバーを失うことなく、再インストールを強制することなく、ユーザーに2回目の許可プロンプトを表示することなく、Firebase Cloud MessagingからiOSへ移行する方法を示します。
短いバージョン：iOSでは、移行は再構築ではなくレイヤースワップです。その理由と、正確な実行方法を説明します。
FCMが提供するもの、および停止する場所
Firebase Cloud Messagingは、無料の信頼性の高いインフラストラクチャです。多くのエンジニアリングチームにとって、それはデフォルトの選択肢であり、純粋な配信にとっては良い選択肢です。問題は、マーケティングチームがキャンペーンを実行したいと思った日に発生します。
| 機能 | FCM | PushEngage |
|---|---|---|
| APNs経由の通知配信 | はい | はい |
| 行動ターゲティング | トピックのみ | 動的セグメント、属性、ジオ、デバイス |
| アプリイベントからのトリガーキャンペーン | 自分で構築する | ダッシュボード設定 |
| ドリップシリーズとジャーニー | 自分で構築する | ビジュアルビルダー、テンプレート |
| A/Bテスト | Firebaseコンソール経由、開発者主導 | マーケター主導、スマートウィナー選択 |
| 収益アトリビューションと目標追跡 | いいえ | キャンペーンごと、ワークフローごと |
| マーケターアクセス可能なダッシュボード | いいえ | はい |
その表のパターンは、チームがFCMを卒業する理由です。配信を超えるすべてはエンジニアリングプロジェクトです。完全な比較については、PushEngage vs Firebase Cloud Messagingを参照してください。
iOSで実際に移行されるもの
移行の懸念は、ほぼ常にサブスクライバーリストに関するものです。「SDKを切り替えたら、オプトインしたユーザーを失いますか？」iOSでは、答えはいいえです。その理由を理解すると役立ちます。
iOSでの通知の許可は、SDKではなく、お使いのアプリに属します。ユーザーが許可を付与したとき、それはあなたのバンドルIDに付与され、Appleはお使いのアプリにAPNsデバイスートークンを発行します。これは、どのプッシュプロバイダーでも使用できます。iOSのFCM自体は、そのAPNsトークンのラッパーです。PushEngage SDKが初めて初期化されると、同じアプリレベルの許可を取得し、デバイスートークンをPushEngageに登録し、サブスクライバーはライブになります—再インストールなし、再プロンプトなし、ユーザーからのアクションは一切不要です。
つまり、オプトインしたベースは、更新されたアプリバージョンでデバイスがオンラインになるにつれて引き継がれます。通常のリリースは、2〜3週間以内にアクティブユーザーの大多数に到達します。これは、両方のシステムを並行して実行する計画を立てるべき期間です。
移行手順
ステップ1：PushEngage SDKを追加する
Swift Package Manager（推奨）またはCocoaPods経由でインストールします。1.0リリースは2つのモジュールとして提供されます。PushEngageをアプリターゲットに、PushEngageExtensionを通知サービス拡張ターゲットにリンクしてください。
# 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に向ける
既存の.p8認証キー（または.p12証明書）をPushEngageダッシュボードにアップロードします。これはFirebaseに提供したものと同じ認証情報です。Apple開発者設定は何も変更されません。セットアップガイドには、この画面ごとの説明があります。
ステップ5：確認してからリリースする
ダッシュボードからデバッグデバイスにテスト通知を送信し、リッチメディアが拡張機能を通じてレンダリングされることを確認し、購読者がオーディエンスビューに表示されることを確認します。その後リリースします。更新がロールアウトされるにつれて、PushEngageの購読者数は自動的に増加します。
移行中は両方のシステムを実行する
ハードカットオーバーは必要ありませんし、行うべきではありません。バックエンドが既に送信しているトランザクション関連のものはFCMをそのまま使用し、購読者が登録するにつれてマーケティング送信をPushEngageに移行してください。両方のSDKは同じアプリで共存できます。同じAPNsトークンを消費しているためです。アクティブなベースが再登録され、キャンペーンが完全に移行したら、Firebase Messagingの依存関係を削除するのはクリーンアップタスクであり、締め切りではありません。
マーケティングチームが初日から利用できるもの
この移行のポイントはSDKではなく、その後エンジニアリングチケットでなくなることです。ダッシュボードから、マーケティングチームはアプリが追跡するあらゆるイベントに基づいてトリガーキャンペーンを構築し、行動セグメンテーションでオーディエンスをカットし、ドリップジャーニーを実行し、コピーをA/Bテストし、目標追跡でキャンペーンごとの収益を属性化できます。統合後のあなたの関与は、チームが新しいトリガーを望むときに、trackEvent（1行の呼び出し）で新しいイベントをインストルメントすることです。
正直に言って、コストの問題
FCMの配信は無料です。生の配信だけが必要な場合は、FCMを使い続けてください。PushEngageを評価する際に価格設定しているのは、マーケティングレイヤー、つまりセグメンテーション、自動化、属性化、そしてマーケティングチームが単独で操作できるダッシュボードです。価格設定はアクティブな購読者のみに基づいてスケーリングされるため、エンゲージメントが混在する大規模なインストールベースでも請求額は膨らまず、リストが縮小すれば請求額も縮小します。Firebaseプッシュ通知の価格設定で、実際のコスト比較を詳しく説明しました。
移行する
Firebase Cloud Messaging on iOSからの移行は、午後の統合と忍耐のリリースサイクルです。SDKを追加し、App Groupを共有し、既にお持ちのAPNsキーをアップロードして、ロールアウトでベースを再登録させます。再インストールなし、購読者の喪失なし、2回目の許可プロンプトなし—そして、スプリントで待機するプッシュキャンペーンはもうありません。戦略的コンテキストが必要な場合は、アプリプッシュマーケティングガイドから始めてください。または、SDKに直接進んで、今週中にリリースしてください。すべての有料プランには、14日間の返金保証が付いています。
