A message pops up on your phone: your package is out for delivery, a friend replied, a match is about to start. Push notifications feel instant and almost magical, yet behind each one is a chain of systems working together. If you are learning app development, understanding that chain helps you design better features and debug problems faster. This article walks through how push notifications work, what the main pieces are, and how to use them without annoying your users.
Local vs. remote notifications
There are two broad kinds of notifications. Local notifications are scheduled by the app itself on the device. A reminder app that alerts you at 8 a.m. does not need a server; the app tells the operating system when to show the message. Remote notifications, usually called push notifications, are triggered from outside the device, typically by a server, even when the app is closed. This article focuses on the second kind, since it involves more moving parts.
The main players
A push notification involves four participants:
- The app on the device, which asks permission and registers for notifications.
- The operating system, which receives the message and displays it.
- The platform push service, run by the platform owner: Apple Push Notification service (APNs) for iOS and Firebase Cloud Messaging (FCM) for Android.
- Your backend server, which decides when and what to send.
Your server never talks directly to the phone. Instead, it hands the message to the platform service, which maintains a persistent, efficient connection with each device. This design saves battery, because the phone keeps a single shared connection rather than every app holding its own.
Step by step: how a push travels
The journey of a typical push notification follows a predictable sequence:
- Permission and registration. When the app starts, it asks the user for permission to show notifications and registers with the platform push service.
- Token creation. The platform service returns a unique device token, a long string that identifies that app on that device.
- Token storage. The app sends the token to your backend, which stores it, usually linked to a user account.
- Trigger. Something happens on your server, such as a new message or an order update, and your server decides to notify the user.
- Delivery request. The server sends a request containing the token and the message payload to APNs or FCM.
- Delivery to the device. The platform service forwards the message to the phone, and the operating system displays it or wakes the app to handle it.
What is inside a notification payload
The payload is the content of the message, usually in JSON format. It commonly includes a title, a body and optional extra data. A simple example looks like this:
{
"title": "Order shipped",
"body": "Your package is on its way.",
"data": { "orderId": "1042" }
}The extra data lets the app react when the user taps the notification, for instance by opening the exact order screen instead of the home page. Platforms also limit payload size, so notifications should carry a small amount of information and let the app fetch the rest when opened.
Notification messages vs. data messages
With Firebase Cloud Messaging, a useful distinction is between notification messages and data messages. A notification message includes title and body fields, and the system can display it automatically while the app is in the background. A data message carries only custom key-value pairs and is delivered to the app’s code, which decides what to do. Data messages offer more control, but they require your app to build and show the notification itself. Choosing between them depends on how much customization you need.
| Aspect | Notification message | Data message |
|---|---|---|
| Who displays it | The system (in the background) | Your app code |
| Customization | Limited | High |
| Typical use | Simple alerts | Custom logic, silent updates |
Permissions and user trust
Users must agree to receive notifications. On iOS, the app shows a system prompt asking for permission. On Android, recent versions also require the app to request a runtime permission before showing notifications. Because this prompt usually appears only once, timing matters. Asking at the very first launch, before the user understands the app’s value, often leads to a refusal that is hard to reverse. A better approach is to explain the benefit first and ask at a moment when the request makes sense, such as after the user places an order.
Common problems and how to think about them
When notifications do not arrive, the cause is usually in one of a few places. The token may be outdated, since tokens can change when an app is reinstalled or data is restored, so your server should update them regularly and remove invalid ones. The user may have disabled notifications in system settings. The device may be in a battery-saving mode that restricts background activity. Finally, the payload may be malformed or too large. Checking each link of the chain, from token to payload, is the fastest way to find the failure.
Writing notifications people want
Technical delivery is only half the story. A notification is useful only if it is relevant. A few habits make a big difference:
- Send messages tied to something the user cares about, like a status change or a direct reply.
- Keep text short and clear, with the key information first.
- Let users choose which categories they receive.
- Avoid sending too often, since frequent alerts push people to mute or uninstall.
- Link each notification to the right screen inside the app.
Conclusion
Push notifications rely on a simple idea: your server asks a platform service to reach a device using a token, and the operating system shows the result. Knowing each step makes it easier to build reliable features and respectful ones. If you want to practice these concepts in real projects, the app development courses at Cursa can help you move from theory to building mobile apps with confidence.
