TaCode Tuesdays: Integrating Push Notifications: Android vs. iOS
It’s Tuesday again. That means your favorite developer at Zang is here to deliver free snippets of code for use in your very own text/voice apps along with hilarious taco puns. This week I’m going to show you the differences between iOS and Android push notifications when it comes to app development.
Let’s Taco ’Bout Push Notifications
If you haven’t considered how your push notifications will appear before you actually start coding, your mobile app will probably fall into a black hole. Although push notifications are a great way to stay connected with mobile users by informing them of new content or encouraging them to take a specific action, significant differences exist between iOS push notifications and their Android counterparts.
Google’s Firebase Cloud Messaging (FCM), also referred to as Android push notifications, and Apple Push Notification Service (APNS) are the two main platforms in pushing messages through mobile. Whether you prefer developing for a specific platform or spend time developing for both, it’s important to distinguish between the two before you start coding your next mobile app.
Firebase Cloud Messaging for Android
Two types of messages can be sent via FCM: Notification and Data. Notification messages, sometimes referred to as display messages, are lightweight and should be used if you want to send a message that are directly configured in Firebase. Here’s a sample JSON coded string:
If you’re looking at custom-key value pairs, Data messages allows you to send up to 4KB. Note that this will be processed by your client app. Here’s a code sample:
Apple Push Notifications Service for iOS
Similar to Android push notifications, APNS allows sending 2-4KB of payload depending on the API provider that’s being used. Currently, Apple offers two types: HTTP/2 and APNS’ legacy binary interface. HTTP/2 is the newer version and stretches up to 4.1KB while the legacy binary interface only permits up to 2.05KB. When composing APNS push notifications, Apple recommends that your message contain at least one of the following: a sound, a number which goes to the application icon, and an alert message that will be displayed to the user.
With iOS push notifications you can send five different types of push notifications: alerts, badge, and sound; new content and custom made ones by using pre-defined keys. Using the alert string shows a standard alert or banner that can be closed or viewed. Here’s a sample code:
When developing push notifications, it’s best to remind users they have notifications that are still waiting to be viewed. To do this, use the badge key. It’s a number that goes to the icon- the one that actually piles up when a user keeps ignoring push notifications. If you encounter problems on auto-incrementing refer to this forum in . Here’s a sample code:
Another main difference to keep in mind is that an iOS app must seek permission from the end user to receive push notifications as soon as the app is installed. This is accomplished via a dialogue pop-up box that appears when the user launches the app for the first time. This setting can be changed later in the device’s settings menu. Android, on the other hand, does not give users this option upon installation of the app. The default Android setting is to automatically allow push notifications, unless the user disables them later.
Android push notifications always return a reply to the respective application server indicating if the message was delivered successfully. Importantly, this reply can assist the application server in determining if a device ID has been altered or if it has become invalid and cannot receive more push notifications. For iOS push notifications, you’ll need to query the feedback server frequently to find out if any device tokens have become invalid. With this in mind, neither APNS or GCM tell you if the message was delivered to the intended device. Instead, they only update you if the message was accepted for delivery.
Once the message leaves the server, there are also differences in how they’re handled. Most notably, GCM will save Android push notifications in a queue for later delivery if the initial attempt was unsuccessful, while APNS will only save one. This means if you send an iOS push notification before the first one was successfully delivered, the incoming message will delete the first one in the queue. With GCM, you can also determine how long your messages must wait in that queue with the time-to-live setting. The setting can be anywhere from zero seconds to four weeks. Unfortunately, APNS does not allow this. It also doesn’t disclose what it’s time-to-live period is for iOS push notifications that can’t be delivered initially.
Which Is Better?
When it comes to choosing between iOS and Android push notifications, the choice is yours. Each has its pros and cons which you should be aware of, especially if you’re hoping to develop a cross-platform notification system. Some developers prefer the freedom and customization that comes with Android push notifications, while others prefer the simplicity associated with iOS push notifications. This chart shows more differences between FCN and APNS, so you can judge for yourself: