Push Notifications in Mobile Development — Essence, Types, and How They Work

What are Push Notifications?

Push notifications are short messages that the app server sends to the user’s device without an explicit request. They appear as banners, icon badges, or sound signals, attracting the user’s attention to the app and informing them about important events.

Definition and Purpose

A push notification consists of a title, a message body, and optional payload data. Unlike SMS, Push notifications are free for the user and are delivered through cloud service infrastructure — FCM for Android and APNS for iOS. The main goals of Push notifications are: increasing engagement, informing about events, and bringing the user back to the app.

Usage statistics show that properly configured Push notifications increase app retention by 30–60%. However, excessive notification frequency leads to unsubscribes — over 60% of users disable notifications if they are sent more than three times a day.

Push System Architecture

A Push system includes three components: the app server, the platform service (FCM/APNS), and the client application on the device. The server sends a request to the platform service, which delivers the notification to the target device through a persistent connection with the OS.

How Do Push Notifications Work?

The delivery mechanism of Push notifications is based on a persistent connection between the device and the platform service. The operating system maintains an encrypted communication channel through which all Push messages pass.

Registration and Token Acquisition

On first launch, the app requests permission to send notifications and receives a unique device token from FCM or APNS. This token is a string up to 4 KB long that uniquely identifies the app instance. The token changes when the app is reinstalled or the device is restored from a backup.

class FirebaseMessagingService :
    FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        sendTokenToServer(token)
    }

    override fun onMessageReceived(
        message: RemoteMessage
    ) {
        showNotification(message.notification)
    }
}

Sending Through the App Server

The app server sends an HTTP request to the FCM API or APNS API, specifying the target token, title, body, and additional data. The platform service responds with a delivery status: success, invalid token (the device uninstalled the app), or rate-limited (send frequency exceeded).

fetch("https://fcm.googleapis.com/fcm/send", {
    method: "POST",
    headers: {
        "Authorization": "key=AIzaSy...",
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        to: "device_token_here",
        notification: {
            title: "New message",
            body: "You have a new notification!"
        }
    })
})

FCM vs APNS: Platform Comparison

The choice between FCM and APNS depends on the target platform. FCM supports Android and iOS, while APNS supports only the Apple ecosystem. Let’s examine the key differences important for cross-platform mobile app development.

Firebase Cloud Messaging (FCM)

FCM is a Google service running on top of Google Play Services. It supports two delivery schemes: display notifications with automatic rendering and data notifications that the app handles on its own. FCM is free and has no limits on the number of messages sent.

Apple Push Notification Service (APNS)

APNS is Apple’s service with support for multimedia attachments (images, video, audio) up to 10 MB. Sending via APNS requires a TLS certificate or authentication key. APNS limits the send frequency to a single device — no more than 150 notifications per minute, after which rate limiting kicks in.

Types of Push Notifications

Push notifications are classified by display method and purpose. Understanding the types helps choose the right strategy for each user interaction scenario.

Display Notifications

The most common type — a displayed notification with a title and body. The OS automatically shows it in the notification shade, on the lock screen, and as a banner. The developer can configure sound, vibration, icon badge, and action buttons for direct actions (reply, open, dismiss).

Data Notifications

Data notifications contain only payload without visual display. The app processes them in the background: synchronizes data, updates cache, or triggers downloads. On Android, data notifications are delivered reliably; on iOS, only when the app is active or through background fetch.

Multimedia and Rich Notifications

Modern mobile OSes support rich and media notifications with images, GIFs, video, and audio. On iOS, this is implemented through UNNotificationAttachment; on Android, through BigPictureStyle and InboxStyle for customizing the notification appearance in the system shade.

Silent Notifications

Silent notifications are not displayed to the user and are used for background synchronization. On iOS, they have high priority for tasks like updating data before the app is opened. Android treats them as data notifications with minimal priority.

Setting Up Push Notifications in a Project

Setting up Push notifications requires actions at the infrastructure, server, and client code levels. Let’s look at the typical process for a cross-platform mobile project.

FCM Setup for Android

For Android, you need to create a project in the Firebase Console, add google-services.json to the project, and configure FirebaseMessagingService. The device token is obtained through FirebaseInstanceId or FirebaseMessaging.getInstance().token, after which it is sent to the server via API on first launch or when it changes.

APNS Setup for iOS

For iOS, you need an Apple Developer Program subscription, creation of a Push certificate or APNS key in the Developer Portal, and enabling the Push Notifications capability in Xcode. Notification registration is done through UIApplication.shared.registerForRemoteNotifications, receiving the deviceToken in AppDelegate.

import UIKit
import UserNotifications

@main
class AppDelegate: UIResponder,
    UIApplicationDelegate {

    func application(
        _ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken
        deviceToken: Data
    ) {
        let token = deviceToken
            .map { String.format("%02x", $0) }
            .joined()
        // send token to your server
    }
}

Server-Side Sending

On the server side, Push notifications are sent via REST API or Admin SDK. FCM uses the Firebase Admin SDK (available for Node.js, Java, Python, Go), while APNS uses pusher libraries (pushy for Java, apn2 for Node.js). It is recommended to store tokens in a database with a last-updated timestamp.

Push Notification Security

Push notification security is critically important, as confidential data may be transmitted through them. Both platforms provide basic protection mechanisms, but the developer must use them correctly.

Payload Encryption

A Push notification payload may contain personal data of users: names, transaction amounts, message links. Even though the communication channel between FCM/APNS and the device is encrypted, data can be intercepted at the application level if a third-party app intercepts the notification. It is recommended to encrypt sensitive payload on the server using AES-256 and decrypt it on the device using a key stored in Keychain (iOS) or EncryptedSharedPreferences (Android).

Token Validation on the Server

The device token is a session identifier that can be compromised if the device is hacked or traffic is intercepted. The app server should validate tokens before sending: check them against the database, track inactive tokens, and remove them on repeated InvalidToken errors. FCM and APNS return InvalidRegistration status for invalid tokens — do not ignore it.

Spam Protection

Without frequency control, Push notifications can become a spam tool that annoys users and reduces retention. Set server-side limits: no more than 5 notifications per hour for a single user and no more than 3 identical messages. For transactional notifications (order confirmation, password change), limits can be higher — up to 10 per hour, as they carry critically important information. Use rate limiting at the API send level so an attacker cannot trigger mass notifications through your server.