FCM/Firebase, when used with iOS clients, supports the standard push notifications based on the device token. The iOS-FCM-Client retrieves the device token for this, sends it to the FCM Gateway and stores it there to access the Apple APNS-Gateways when a push notification needs to be delivered.
The disadvantage of standard push notifications is, at least for iOS, that they cannot reach an app when it e.g. has been killed.
When it comes to call- or real-time apps, the obvious requirement is that notifications need to be always received by the app, not matter of the current phone state (doze-mode, app background, app killed, etc).
Implementing such real-time apps on Android works fine using FCM.
For iOS instead, PushKit needs to be implemented on the client side, having a different token (VoIP token), different hooks and using a different APNS-Gateway. Notifications send via this scheme also reach out to killed apps.
As a cause, for to build a reliable app on iOS, FCM cannot be used as a singleton solution, one must manually and in addition implement direct access to the Apple PushKit-APNS Gateway and handle the appropriate VoIP token management in addition to the FCM access anyway required for Android devices.
The changes required to fix this in the iOS-FCM-client and server-side code seem quite straight forward. In addition to the standard device token the iOS client code would also need to register the PushKit implementation, retrieve the VoIP token from it and send that additionally to the device token to the FCM Gateway.
The FCM gateway, when sending out a new notification, just needs to look into the headers of the notification and can by that select which of the APNS-Gateways and which of the both tokens it must use to deliver it.
As this is the state for years now I have no clue why this more-or less easy and critical feature is still not implemented by FCM.
Does anyone know any reason why?
To outline what this request is about:
FCM/Firebase, when used with iOS clients, supports the standard push notifications based on the device token. The iOS-FCM-Client retrieves the device token for this, sends it to the FCM Gateway and stores it there to access the Apple APNS-Gateways when a push notification needs to be delivered.
The disadvantage of standard push notifications is, at least for iOS, that they cannot reach an app when it e.g. has been killed.
When it comes to call- or real-time apps, the obvious requirement is that notifications need to be always received by the app, not matter of the current phone state (doze-mode, app background, app killed, etc).
Implementing such real-time apps on Android works fine using FCM.
For iOS instead, PushKit needs to be implemented on the client side, having a different token (VoIP token), different hooks and using a different APNS-Gateway. Notifications send via this scheme also reach out to killed apps.
As a cause, for to build a reliable app on iOS, FCM cannot be used as a singleton solution, one must manually and in addition implement direct access to the Apple PushKit-APNS Gateway and handle the appropriate VoIP token management in addition to the FCM access anyway required for Android devices.
The changes required to fix this in the iOS-FCM-client and server-side code seem quite straight forward. In addition to the standard device token the iOS client code would also need to register the PushKit implementation, retrieve the VoIP token from it and send that additionally to the device token to the FCM Gateway.
The FCM gateway, when sending out a new notification, just needs to look into the headers of the notification and can by that select which of the APNS-Gateways and which of the both tokens it must use to deliver it.
As this is the state for years now I have no clue why this more-or less easy and critical feature is still not implemented by FCM.
Does anyone know any reason why?