关于iOS中Firebase Cloud Messaging的Swizzling概念及适用场景咨询

Hey Ryan, let me break down what swizzling is in the context of FCM and when you need to care about enabling or disabling it— I’ve been exactly where you are, so I get the confusion!

What Exactly is Swizzling? #

Swizzling is a trick made possible by Objective-C’s runtime (and accessible in Swift via Objective-C runtime APIs). At its core, it lets you swap the implementation of two methods at runtime.

For example: If the system normally calls your AppDelegate’s application:didRegisterForRemoteNotificationsWithDeviceToken: when your app gets a push token, swizzling can reroute that call to a method in the FCM SDK instead— without you having to manually write code to forward the request.

How FCM Uses Swizzling (By Default) #

FCM’s iOS SDK relies on swizzling to simplify integration. Here’s what it does automatically when swizzling is enabled:

• It hooks into your app’s remote notification lifecycle methods (like token registration and push receipt handlers).
• It automatically passes the APNS device token to FCM, so you don’t have to write Messaging.messaging().apnsToken = deviceToken yourself.
• It handles incoming push messages by routing them to FCM’s internal logic, so you don’t need to manually trigger FCM’s message processing code.

When to Use (or Disable) Swizzling #

Stick with Default Swizzling (Enabled) If: #

• You’re looking for a quick, no-fuss FCM integration: Swizzling cuts down on boilerplate code significantly, perfect for getting push notifications up and running fast.
• You don’t have custom remote notification logic: If your app doesn’t already handle token storage or push receipt on its own, FCM’s default swizzling works seamlessly.

Disable Swizzling If: #

• You have custom remote notification handlers: For example, if you need to save the device token to your own backend in addition to sending it to FCM, swizzling might override your custom implementation. Disabling it lets you manually control when and how you pass data to FCM.
• You’re using multiple push services: If your app uses FCM alongside another push SDK (like OneSignal or a custom solution), swizzling from both SDKs can conflict— leading to missing tokens, unprocessed pushes, or unpredictable behavior. Disabling swizzling for all SDKs lets you manually manage each one’s logic.
• You need fine-grained control over push flow: Maybe you want to validate incoming pushes before passing them to FCM, or handle different push types separately. Disabling swizzling puts you in full control of the notification lifecycle.

Quick Note on Disabling Swizzling #

To turn off FCM’s swizzling, add this key-value pair to your Info.plist:

<key>FirebaseAppDelegateProxyEnabled</key>
<false/>

Once disabled, you’ll need to manually wire up FCM’s required calls:

1. In application:didRegisterForRemoteNotificationsWithDeviceToken:, set the APNS token for FCM:

   Messaging.messaging().apnsToken = deviceToken
   

2. In your push receipt methods (like userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:), tell FCM to process the message:

   Messaging.messaging().appDidReceiveMessage(response.notification.request.content.userInfo)
   

Hope that clears things up— let me know if you have more questions!

内容的提问来源于stack exchange，提问作者Binh Le