Blog

Recently I spent some time looking into mobile push notification architecture mainly focused on Android and iOS. Before I go into explaining how mobile push notification works, here are some terminologies I used throughout the post:

Platform – These are services provided by mobile device builders (e.g. Apple, Google, Amazon) that transport the messages to the end devices. The Platforms offer device registration, app token creation and management, and the delivery channel for notifications to be delivered to devices. There are several different services that you can use to send push notifications to the users of your applications. The platform you use largely depends on which app store your customers use to obtain your app. The most common platforms are Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM), Baidu Cloud Push, and Amazon Device Messaging (ADM).

Provider – The Provider allows app registration and messaging to be coordinated by your mobile apps backend system, to allow for event or schedule based interactions from your backend with your mobile app. They typically utilise underlining mobile platforms to communicate with your mobile app. Examples are AWS SNS, AWS Pinpoint, OneSignal, Expo Push API, etc.

Client – This is the mobile application running on a physical device or simulator.

The overall architecture looks like the following:

As you can see from the diagram, your service/push trigger will talk to AWS SNS which uses FCM/APNs to push notifications to clients. Note that FCM could also push notifications to iOS devices according to their documentation, but underneath it is also using APNs which you still need to setup.

The first thing you need to do is to create a project in your chosen mobile platform, then use the project information to create a platform application in SNS. The push notification workflow using SNS is shown as below:

1. Your mobile app sets up secure connection with mobile platforms to register for app push notification and request a device and app specific device token
2. The platform returns the device token back to your mobile app
3. Your mobile app could pass the device token along with other information to your service
4. You service calls AWS SNS to set up an application endpoint using the device token and additional user data
5. SNS returns application endpoint response back to your service to save for future reference
6. When your service wants to push a notification, it will call SNS application endpoint with the message for the platform
7. SNS calls mobile platform to deliver the message
8. Mobile platform pushes the message to your mobile client

There are several react native mobile libraries you can use for step 1-2:

• If you are using Expo to create your mobile application, you can use their expo-notifications to receive notifications and call Notifications.getDevicePushTokenAsync() to retrieve native token instead of Expo token. At the time of writing, this approach does not work with Expo Go app and the apple environment is default to production. This library works best with Expo Push API so you might need to put in extra effort to set it up and it also requires physical device in both Apple and Android for push notification to work. One advantage of using this library is that you write in pure JavaScript without having to set up Android and iOS native code.
• If you are using reactive native, there are react-native-push-notification (Warning: No longer actively maintained) and react-native-notifications.

Note: Apple always requires physical devices for push notification while Android simulator could be used to test locally.

One important thing I found out through the research was that there are so many solutions out there and each of them gives you pros and cons. It is better to gather your requirements first then pick the one most suitable for you.