Comparison – Apple Push Notification Service (APNS), Google Cloud Messaging (GCM), Firebase Cloud Messaging (FCM) and Windows Notification Service (WNS)

Whenever an MDM server (or any app server) wants to communicate with the client app installed on a device, the server sends a notification to the device. This notification is transferred over another server known as the push notification server.

Push notification service overview

Different push notifications are catering to various needs or use cases. A standard one sends a single notification to the user base allowing users to receive the updates in real-time. During the enrollment process itself, MDM registers the enrolling devices for the Push Notification Service of the respective platform which are:

• Apple Push Notification service (APNs) by Apple
• Firebase Cloud Messaging (FCM) by Google
• Windows Notification Service (WNS) by Microsoft

Once a device is enrolled, the MDM server requests the device through push notification to establish a communication session with it whenever it is necessary to apply or modify any settings on the enrolled device. If a device is offline when the MDM server requests for a management session, the notification will be delivered to the device as and when the device comes online. The Push Notification Service of each platform has its own caching method to make this possible.

Creating a secure connection between your MDM server and the push notification service is the primary step for communication. The basic mechanism is similar for all notification services. When the organization wants to communicate with a particular device, the MDM server generates the request containing the data and the unique device identifier. This request is forwarded to the Push Notification Service which delivers it to the user device. The device’s OS checks and delivers the notification to the client upon receiving it from the service. The client app handles the notified data and performs the changes requested by the MDM server.

A notification consists of two components:

1. The device token (in APNS), device ID (in FCM) or Notification Channel URI (in WNS).
2. Payload.

The device token is obtained from APNs after the device registers in the APNs. This token is included with payload so that when a notification is sent, then the token identifies the app in the required device to which notification is to be sent. Since the device token is included within the payload, the device token takes up some of the notification payloads.

The device token in APNs is a 64-byte hex string, and the Device ID in FCM is a 183-byte string, containing [a-zA-Z0-9_\-] (all numbers, lowercase, and uppercase alphabets, and symbols like \, _ and –).

Notification format

Notification in FCM is sent as JSON payloads with parameters registration_ids, data, collapse_key, delay_while_id_, time_to_live and dry_run. APNs sends notifications as string or dictionary, containing alert, sound, badge, and token. The alert contains the body, action-loc-key, loc-key, loc-args, and launch-image. WNS sends the notification as a string.

Payload

The maximum notification payload allowed through APNs is 4 KB in iOS 8 and above. It was only 256 bytes operating systems prior to iOS 8. Keep in mind that the notification payload is the sum of notification size and device token.

Through FCM, it is also possible to send messages apart from notifications. FCM describes two different payload sizes for different functions. The maximum notification payload size allowed is 2 KB which is lowest when comparing FCM with APNs and WNS. The maximum message payload size is 4 KB.

WNS is the one that allows the highest notification payload among the three, and that is 5 KB.

Communication

Both APNs and WNS work in a similar way. The notification received by the client device says, “Go talk to your server”. That is, when a notification is received by the client device, then the client device directly communicates with its server without the notification server in between.

FCM has two types of implementation at the app server’s side – the HTTP and XMPP implementations. HTTP implementation works in a similar way to that of APNs and WNS, but the XMPP has a different aspect. When XMPP implementation is done, then the upstream messages (messages from the client to app server), as well as the downstream messages (messages from the app server), are handled by the push notification server. In this case, it can be said that there is an improvement in reliability of service because it is possible to send acknowledgments for a notification from the client device through FCM. It is also known that FCM will send ‘success’ or ‘failure’ on successful or unsuccessful deliveries, respectively.

Since push notifications are not reliable in APNs, it is recommended that the client app acknowledges the server manually in the retrieval of notification and this acknowledgment is to be sent directly to the server from the client device. But, there is a feedback server that is used to send the notification back to the server when a particular app (the app to which notification is to be sent) was not found on a device, probably due to the app being uninstalled before the notification was received by the device.

WNS sends HTTP response codes on various events in it.

HTTP Response Codes

• 200 OK – Returns when WNS successfully authenticates notification from the app server.
• 400 Bad Request – Returns when headers are incorrectly specified or are conflicting with other headers.
• 401 Unauthorized – The app server presented an invalid authentication ticket to WNS.
• 403 Forbidden – Even if the app server is authenticated to WNS, they are not authorized to send messages to the notification channel URI.
• 404 Not Found – Notification channel URI is not identified by WNS or the URI isn’t valid.
• 405 Method Not Allowed – Only POST (for Windows and Windows Phone) and DELETE (for Windows Phone) are allowed.
• 406 Not Acceptable – High rate of transferring notifications.
• 410 Gone – Attempting to send a notification through an expired notification channel URI.
• 413 Request Entity Too Large – Notification payload size larger than 5 KB.
• 500 Internal Server Error – Delivery of notification failed due to an internal server error.
• 503 Service Unavailable – Server is unavailable.

Recommended action for each HTTP Response Codes

• 200 OK – No action required.
• 400 Bad Request – Log the details of the request, analyze the request, and compare the details with the documentation.
• 401 Unauthorized – Use the access token request to authenticate the cloud service and request a valid access token.
• 403 Forbidden – Check the package name in your app’s manifest and make sure that it is matching with the cloud service credentials given to your app.
• 404 Not Found – Log the details of the request. Ensure that you never send further notifications as the notifications send to the channel will definitely fail.
• 405 Method Not Allowed – Log the details of the request. Use HTTP POST.
• 406 Not Acceptable – Log the details of the request. Limit the notification sending rate.
• 410 Gone – Log the details of the request. Ensure that you never send further notifications to the channel. Request for another channel URI.
• 413 Request Entity Too Large – Log the details of the request. Make sure that the payload size is within the allowed limit.
• 500 Internal Server Error – Log the details of the request. You may have to report the issue in the developer forum.
• 503 Service Unavailable – Log the details of the request. You may have to report the issue in the developer forum.

It is a good practice that the developers log and inspect the details of all the requests and the response codes as they have to provide the response code as well as the header information while reporting an issue.

Storage of notifications

What if when there is no network connectivity on a device when the app server sends a notification? Well, in that case, the push notification server stores the notification for a limited period of time and tries to send the notification repeatedly after a certain period of time until the device is available to receive push notifications. Different push notification servers have their own rules for storing notifications in such cases.

The APNs stores only one notification per app. If a second notification to the same app arrives, then the first notification is replaced by the second. The notifications are deleted if the device remains offline for 28 days.

FCM does not store notifications on a ‘per app’ perspective. Instead, it stores 100 notifications per device. Like in APNs, the notifications are stored for a maximum time period of 28 days.

WNS stores both tile notifications and badge notifications. Tile and badge notifications look similar but are actually different.  A badge notification is a number from 1 to 99 and is displayed on the tile; either on the app icon or at the corner of the tile. Tile notifications are those which modify the tiles itself or appear as a part of the tile (appear to be the app icon itself).

If queuing is enabled, then WNS can store up to five tile notifications and one badge notification per communication channel when the device is offline. Otherwise, WNS stores only one tile notification and one badge notification per channel. Communication channels are opened per app when notifications are to be sent to client devices, so ‘per communication channel’ means per app. These notifications are deleted when the device remains offline for 30 days. Even if the device receives and displays notifications, and the users do not interfere with them within three days, the notifications are no longer displayed.

Support for multiple platforms

APNs and WNS do not support multiple platforms. They are designed to work with their native platforms. But, FCM supports multiple platforms such as Android and iOS and even supports Chrome web apps.

Ports used

APNs use four TCP ports, which are:

443: Used for communicating with APNs when communication using port 5223 is not possible.

2195: Used to send the notification to APNs.

2196: Used for APNs feedback.

5223: Used for communicating with APNs.

Ports 5228, 5229, and 5230 are to be used in Firebase Cloud Messaging. Google uses any of these three ports (different ports at different times). TCP port 443 should be open in the case of the Windows Notification Service.

Comparison – Google Cloud Messaging (GCM) and Firebase Cloud Messaging (FCM)

GCM is the older version of FCM. Google recommends migrating to FCM, as new features will not be added to GCM. Google currently supports the latest version of GCM SDKs as the migration takes time.

• The maximum number of subscribers supported by GCM was 1 million. FCM takes off this restriction, so there can be more than a million subscribers.
• SDKs are changed, so there is less need for coding. Coding for subscription and error handling is not required any more.
• Permissions were to be specified inside the Android Manifest file in GCM, but in FCM, all required permissions are added automatically.
• FCM introduced C++ programming in addition to the Swift programming in GCM.
• GCM supported Android, iOS, and Chrome, and FCM will continue supporting them.

Comparison – Microsoft Push Notification (MPNS) and Windows Notification Service (WNS)

• MPNS provided native support for Windows Phone 8 and Windows Phone 8.1, and MPNS was replaced later with WNS. MPNS can also be used, but only when:
  1. The device was already registered with MPNS,
  2. Windows app is converted to Microsoft Silverlight app, and
  3. MPNS target Silverlight platform.
•  WNS also supports Windows 10 Mobile, Windows 10, XBOX, and other supported platforms.