GCM、FCM 與 APNs 的差異與實務考量

在行動應用的即時通訊設計中，推播服務是不可或缺的組件。雖然 GCM（Google Cloud Messaging）已於 2016 年正式退役，取而代之的是 FCM（Firebase Cloud Messaging），但許多系統仍在維持舊版 GCM 的支援。另一方面，Apple 推出的 APNs（Apple Push Notification service）則是 iOS、macOS、watchOS 等蘋果平台的唯一推播入口。本文針對三者的協定結構、功能差異、使用成本及安全性進行深入比較，並提供實務上遷移與整合的建議。

協定層面：傳輸協定與連線管理

GCM/FCM：使用 HTTP/2 或 XMPP（可選擇）作為下游傳輸協定。FCM 透過 google.golang.org/grpc 之類的 gRPC/HTTP2 連線，提供持久化連線、批次傳送與影子訊息功能。
APNs：自 2019 年起改為 HTTP/2 為主協定，取代原先的 binary interface。推播訊息以 JSON 或 binary payload 送至 api.push.apple.com，並利用 TLS 1.2+ 進行加密。

功能差異：訊息層級與擴充性

📂 收合（點我收起）

# Firebase Cloud Messaging 範例 (Android)
{
  "to": "fcm_token",
  "notification": {
    "title": "新訊息",
    "body": "您有一條新訊息"
  },
  "data": {
    "type": "chat",
    "chat_id": "12345"
  }
}

📂 收合（點我收起）

# Apple Push Notification Service 範例 (iOS)
{
  "aps": {
    "alert": {
      "title": "新訊息",
      "body": "您有一條新訊息"
    },
    "badge": 1,
    "sound": "default"
  },
  "type": "chat",
  "chat_id": "12345"
}

FCM：支援 Android、iOS、Web、Unity、C++。提供「Topic Messaging」「Device Group」以及「Message Persistence」等高階功能。
APNs：僅支援蘋果平台，但支援「Device Token」與「Topic」兩種送達方式。自 2024 年起，APNs 亦支援「Device Groups」與「Silent Push」的優化。
兩者皆允許自訂 data 欄位，但 APNs 的 payload 大小上限為 4KB，而 FCM 允許 4KB 以上（最大 4MB）。

安全性考量：憑證管理與訊息驗證

FCM：使用 Google API 金鑰或 OAuth 2.0 服務帳戶。訊息在傳送前經過 HMAC-SHA256 簽章，並由 Google 伺服器校驗。
APNs：採用蘋果提供的 PKCS#12 憑證或 JWT（使用 APNs Auth Key）進行認證。JWT 方式可減少憑證輪替頻率，且支援多個 topic。
兩者皆支援 TLS 1.2+，但 APNs 的 TLS 1.3 只在 macOS 12+ 與 iOS 15+ 可用。

實務遷移策略：從 GCM→FCM 以及跨平台整合

確認舊版 GCM 端點：https://gcm-http.googleapis.com/gcm/send 已停用，必須更新至 https://fcm.googleapis.com/fcm/send。
若系統同時支援 Android 與 iOS，建議使用 Firebase Cloud Functions 於後端統一處理 payload，並透過 APNs 與 FCM 兩個 SDK 分別推送。
使用「Topic Messaging」可降低多端推播的重複工作；在 iOS 上可使用 APNs 的「Topic」功能，Android 則使用 FCM 的同名 Topic。
為保持訊息一致性，建議在後端維持一套「訊息模板」結構，並在推送前轉換為目標平台所需的 JSON 形式。