Mobile Push Notifications Definition
Mobile push notifications are short, real-time messages or alerts sent from a mobile app to a user's device, even when the app is not actively open or running. These notifications appear on the user's lock screen or notification center, acting as a direct communication channel between app developers and users. They serve to inform, engage, and prompt user actions, such as opening the app or interacting with specific content.
Push notifications are an integral part of mobile app ecosystems, helping apps maintain user engagement and deliver critical updates.
From a developer's perspective, implementing push notifications involves understanding various technical components such as notification services, APIs, device registration, payload formats, and app lifecycle management. Let's dive into the technical specifics of push notifications.
Silent Push Notifications: Silent notifications, which update app content without notifying the user, are increasingly being used to synchronize data or ensure real-time updates in apps, especially in social and news apps.
Key Statistics on Mobile Push Notifications
Push Notification Opt-in Rates iOS vs. Android:
Android users tend to have higher opt-in rates because notifications are enabled by default upon app installation, with an opt-in rate of ~91%.
iOS users need to explicitly allow push notifications, leading to lower opt-in rates, with an average of around 43% opt-in.
Push Notification Engagement:
Open Rates: Android tends to have higher open rates compared to iOS, with averages of 4.6% for Android and 3.2% for iOS.
Personalized Push Notifications increase engagement, with open rates increasing by 9% compared to generic notifications.
Retention Rates with Push Notifications:
Apps that send push notifications retain users more compared to those that don’t.
Daily active user (DAU) retention rates increase by 20% when users receive personalized push notifications.
Users who opt in to push notifications are 48% more likely to remain engaged with an app.
Effect on Conversion:
Push notifications have been shown to increase conversion rates by up to 28%, especially for promotions and targeted messaging.
Transactional notifications (like order confirmations, shipping updates) have some of the highest open rates, often reaching 50-70%.
Optimal Timing for Push Notifications:
Timing plays a crucial role in the effectiveness of push notifications. Sending notifications at the right time can increase engagement by up to 40%.
Midday and early evening (around 1 PM to 7 PM) have been shown to be the best times for sending notifications across most industries.
User Preferences and Unsubscribes:
On average, 60% of users disable push notifications when overwhelmed by frequency or irrelevant content.
Frequency matters: Sending 1-3 push notifications per week tends to be the sweet spot for maintaining engagement without overwhelming users.
Rich Push Notifications Performance:
Including rich media (images, videos, GIFs) in push notifications boosts engagement, with up to a 46% higher open rate compared to standard text notifications.
Rich notifications are especially popular in e-commerce, entertainment, and news apps, as they enhance the visual appeal and context.
Impact by Industry:
Media & Entertainment: Push notifications can increase engagement by 88% for media apps, particularly when targeting live event updates or news alerts.
E-commerce & Retail: Push notifications drive an 2-9% conversion rate for retail apps, especially during sales or promotional events.
Fitness & Health: Health and fitness apps see 20-40% higher retention rates with personalized notifications, such as workout reminders or progress tracking.
Key Components of Push Notification Architecture
Push Notification Services (PNS): Push notifications rely on platform-specific services to handle delivery:
Apple Push Notification Service (APNs) for iOS.
Firebase Cloud Messaging (FCM) for Android (formerly GCM: Google Cloud Messaging).
These services act as intermediaries between your server and the user's device, ensuring notifications are reliably delivered.
Device Registration: When a user installs or launches your app for the first time, it must register with the platform's PNS. This process involves:
Requesting permission from the user to send push notifications.
Generating a device token (iOS) or registration token (Android) that uniquely identifies the device with APNs or FCM.
Storing these tokens on your server for future use when sending notifications.
Server-Side Integration: To send push notifications, your server needs to communicate with APNs or FCM using their respective APIs. The process typically involves:
APNs (iOS): Your server sends HTTP/2 requests to Apple's API endpoint (https://api.push.apple.com/3/device/{device_token}), including the device token and payload.
FCM (Android): Your server interacts with Firebase's API, making HTTP POST requests to https://fcm.googleapis.com/fcm/send.
Both services require authentication:
APNs: Use a JSON Web Token (JWT) or legacy certificates.
FCM: Use a server key or OAuth access token.
Notification Payload Structure: Push notification payloads are sent in JSON format and must adhere to the guidelines of the respective platform:
APNs Payload (iOS):
{
"aps": {
"alert": {
"title": "Notification Title",
"body": "This is a notification message."
},
"badge": 1,
"sound": "default"
},
"custom_data_key": "custom_value"
}
The aps dictionary is required and may include fields like alert, sound, and badge. Custom data can be added outside of aps for specific app behavior.
FCM Payload (Android):
{
"to": "{registration_token}",
"notification": {
"title": "Notification Title",
"body": "This is a notification message."
},
"data": {
"custom_key": "custom_value"
}
}
FCM supports two types of messages:
Notification messages: Automatically displayed to the user in the notification tray.
Data messages: Delivered silently to the app for background processing or custom handling.
Handling Notifications in the App:
Foreground Notifications: When the app is in the foreground, developers have full control over how notifications are handled and displayed, often using a listener or callback method (onMessageReceived for FCM or userNotificationCenter:willPresentNotification for APNs).
Background Notifications: When the app is in the background or terminated, the operating system takes care of displaying the notification. However, you can configure the app to respond to the user's interaction with the notification.
Silent Push Notifications: Silent pushes, also known as background notifications, allow your app to receive data without alerting the user. These notifications are often used for background updates, syncing, or remote command execution. For example:
APNs silent notification payload:
{
"aps": {
"content-available": 1
},
"custom_data_key": "custom_value"
}
Setting "content-available": 1 tells iOS to wake the app in the background.
Android FCM silent notification: Omit the "notification" field and use only the "data" field for background processing.
Notification Lifecycle Management:
Token Expiry and Rotation: Device tokens may change due to device resets or app reinstalls. Developers need to handle invalid tokens and update the server's token registry accordingly.
Delivery Handling: Push notifications are not guaranteed to be delivered instantly. They may experience delays based on device connectivity, OS background optimizations, or throttling. FCM and APNs offer feedback mechanisms (e.g., feedback service or error codes) to notify developers when a notification fails to reach the device.
Advanced Features:
Rich Push Notifications (iOS): You can attach media (images, GIFs, videos) to notifications by including URLs in the payload. You may also customize the notification UI using Notification Service Extensions.
Notification Priority: Both APNs and FCM allow developers to set priority levels (high, normal) to control the importance and delivery speed of notifications.
Localization: For internationalized apps, you can include localized strings in the payload for title-loc-key and body-loc-key, allowing the system to display notifications in the user's language.
Key protocols for push notifications:
1. Native Apple Push Notification Service (APNs)
Platform: iOS, iPadOS, macOS, watchOS, tvOS
Protocol: APNs is Apple's proprietary, cloud-based service for delivering notifications to iOS and other Apple devices.
How it works: App developers send notifications to Apple’s APNs server. APNs forward the notification to the target device. Devices maintain a persistent connection with APNs, allowing notifications to be delivered even if the app is not running.
Supports silent notifications, badge updates, alerts, and sounds.
Delivers both background data (silent) and user-visible notifications.
Requires an APN token for security and identification.
2. Android Native Firebase Cloud Messaging (FCM)
Platform: Android, iOS (via Firebase), Web
Protocol: FCM is a cross-platform mobile push notification service provided by Google.
How it works: Developers send notifications via Firebase’s messaging platform. Firebase then sends the notification to Android devices, iOS devices (through APNs), or web browsers.
Free to use and scalable for large numbers of users.
Allows both upstream (device-to-cloud) and downstream (cloud-to-device) messaging.
Supports notification messages (for user notifications) and data messages (for silent background operations).
Flexible targeting options (individual users, device groups, or topics).
3. Web Push Protocol
Platform: Web browsers (Chrome, Firefox, Edge, etc.)
Protocol: This is a standardized protocol for delivering push notifications to web browsers.
How it works: Uses the W3C Push API and the Web Push Protocol (an open protocol for push services). When a user subscribes to notifications, a service worker is registered with the browser, which acts as a proxy between the web application and the server. Web push notification is sent via the browser’s push service, which forwards it to the service worker and the user.
Works even when the web page is not open, as long as the browser is running.
Requires HTTPS for secure delivery.
Web Push Payload Encryption ensures the privacy of messages.
4. Pub/Sub Protocols
Platform: Custom push notification systems for all platforms & systems.
Protocol: Publish / Subscribe protocols are used in custom messaging and notification systems, where publish-subscribe (Pub/Sub) architectures distribute messages to subscribers.
Examples: PubNub Push Notifications
How it works: Clients subscribe to topics, and when a message is published to that topic, all subscribers receive the message. Useful for real-time updates and event-driven architectures.
Flexible and scalable for various platforms.
5. Windows Notification Service (WNS)
Platform: Windows 8/10/11 and Integration with Universal Windows Platform (UWP) apps
Protocol: WNS is a notification service provided by Microsoft for delivering push notifications to Windows-based devices.
How it works: Notifications are sent to Microsoft’s WNS servers, which push them to Windows devices via cloud. Devices maintain an open connection with the WNS server to receive notifications. Supports toast notifications, tile updates, badge updates, and raw data notifications.
Provides flexibility for handling background tasks and silent notifications.
6. Amazon Device Messaging (ADM)
Platform: Amazon devices (Fire OS, Fire tablets, etc.)
Protocol: Amazon's ADM service allows developers to send push notifications to Fire OS devices.
How it works: Notifications are sent to the ADM service, which routes them to Amazon devices. Similar to FCM but tailored for Amazon’s ecosystem.
Used for Amazon Fire tablets and other Fire OS devices.
Supports both direct user notifications and background data sync.
7. Open Mobile Alliance Client Push (OMA Push)
Platform: Generic mobile platforms (mostly feature phones)
Protocol: OMA Push was an open standard for delivering notifications to mobile devices, used primarily in feature phones before the rise of smartphones.
How it works: Notifications are pushed using standard HTTP or WAP protocols.
Provides a way to push content or service settings to devices.
Used for basic notifications like SMS, MMS, or WAP-based alerts.
8. MQTT (Message Queuing Telemetry Transport)
Platform: IoT devices and custom push solutions
Protocol: MQTT is a lightweight publish-subscribe messaging protocol used in various IoT applications, but it can also be used for push notifications in custom systems.
How it works: Devices subscribe to a topic, and a central broker sends messages to those devices when new data is published.
Used in scenarios requiring low-bandwidth, low-power notifications. Ideal for telemetry, industrial IoT and sensors.
Persistent connection between the client and broker ensures real-time notification delivery.
9. [obsolete] Microsoft Push Notification Service (MPNS)
Platform: Windows Phone 6 / 7 / 8
Protocol: This was Microsoft’s original push notification service for Windows Phone devices (deprecated and replaced by WNS).
How it worked: Similar to WNS, notifications were sent via MPNS servers to Windows Phone devices. Supports toast notifications and live tile updates.
MPNS has been deprecated in favor of WNS, which is used for newer Windows devices.
Conclusion
Mobile push notifications are a powerful tool to maintain user engagement and enhance the user experience. However, implementing them requires careful system integration with platform-specific services (APNs for iOS and FCM for Android), robust server-side logic, and a thorough understanding of payload structure and lifecycle management.
Need help setting up push notifications? Try our out-of-the-box push solution, featuring lightning-fast worldwide delivery > Contact sales