Push notifications allow your app to provide timely information to your users, even when it's backgrounded. They are a powerful tool, but it comes at a cost. Push requires the right infrastructure and implementation to execute properly. This article will give you a complete overview of setting up push notifications without getting into the weeds.
What is a Push Notification?
First, I would like to clarify what exactly push notifications are and what they can do. Besides getting the popup message on your phone when your app is "backgrounded" or not actively being used, push notifications can also add a number badge to the app icon, arrive with or without a sound, or silently push data to the app without any alerts displayed to the user. There are also scheduled “local notifications” which originate from the app itself and can display a popup message at a set time. But here I’ll just go over push notifications.
Getting Started
Both Apple and Android devices require you to enable the push notification ability in the app manifests.
Both platforms have a hook in the app startup code that allows you to get a special push notification token that is unique to the device and the app if the user has allowed push notifications. You can then post the token to your servers for generating push notification requests to Apple or Google. This token needs to be updated at every startup because it expires at an unknown time, and also may change for various other reasons.
Since these tokens are unique to the device, a separate server request is required for every push notification you want to generate in the case of iOS devices. These requests will fail if a token is expired or invalid, so there are some special considerations for making push requests.
APNs
For push on iOS, a request must be sent to Apple Push Notification service. The request must be streamed via HTTP/2 and TLS protocols and must have either an auth key or certificate, along with the device token and other payload requirements. You can make requests directly to Apple's servers from your servers, but there are services for this that make it much easier that I'll cover below.
FCM and GCM
For push on Android, Google Cloud Messaging is the legacy service for making push requests. The new, current way is to use Firebase Cloud Messaging. It also requires auth and device tokens for each request, but you can include multiple tokens for sending multiple notifications in a single request.
Services for Sending Push Notifications
Although it’s possible to call APNs and FCM directly, Azure and Firebase provide services for sending push notifications. Both provide SDKs for mobile and server, and both allow for creating tagged groups and sending bulk notifications to devices.
Azure
Azure provides Notification Hubs that completely manage device tokens and allow you to compose messages through their UI. This service is more geared toward marketing-type messages to groups of users, although it's possible to send individual notifications. For $10 a month you can send up to a million notifications per month on 200K devices.
Notification Hubs are set up to allow you to solely use their services instead of maintaining your own service to hold tokens and communicate with Azure. In other words, you'll send tokens directly to Azure, and initiate push requests from the Notification Hubs website. But you should be aware this will have less flexibility in terms of event-triggered, personal notifications.
Firebase
Firebase Cloud Messaging is completely free and can make push requests for both iOS and Android devices. It provides a UI for sending messages and also an SDK for you to make event-triggered notifications from your servers. Azure calls FCM for Android push notifications.
A Push in the Right Direction
From the mobile side, it's trivial to get and update tokens for push. You will need to build a service which will accept and store the tokens, along with the date that they were captured, and associate them with that specific user. If a token is too old, you should avoid making a push request. Google recommends that you consider a token stale if it is older than 2 months.
Your backend services can then use the Azure or Firebase SDK to generate push notifications based on any events, providing the necessary token(s) for each push request. In the case of Firebase, the SDK handles Google auth for you and only requires you to upload an Apple auth key generated in the Apple Developer Member Center. The push notification payload can include arbitrary data that will allow the app to open a specific page for the notification and the SDKs provide some normalization of the payload for sending to both platforms. You should also consider if your app needs to respond to a notification, such as navigating to a specific tab, and handle that in the app code.
Conclusion
I hope this article gave you a better understanding of what's required to implement push notifications. From here you should be able to start planning and get your team rolling. Although push requires a considerable amount of effort, your organization and users will surely reap the benefits.