Push Notifications in Mobile Apps: How to Design and Implement Them
How push notifications work through APNs and FCM, how to handle tokens, permissions and payloads, and how to design notifications users value instead of disabling.
Quick answer
Push notifications are messages your backend sends through Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM) to specific app installations, identified by device tokens. Implementing them well means requesting permission in context, storing and refreshing tokens, sending payloads that deep link to the right screen, separating transactional from marketing messages, giving users control over categories and frequency, and measuring delivery, opens and opt-outs. Relevance, not volume, is what keeps notifications enabled.
How Push Notification Systems Work
The app registers with the operating system and receives a device token from APNs or FCM. It sends that token to your backend, linked to the user. When something happens, your backend builds a payload and sends it to the push service, which delivers it to the device. The OS displays the notification, and a tap opens the app to the relevant screen.
APNs and Firebase Cloud Messaging
Apple Push Notification service is the only route for delivering notifications to iOS devices. Firebase Cloud Messaging delivers to Android and can also send to iOS by forwarding through APNs. Many teams use FCM as a single sending API for both platforms, but APNs credentials must still be configured for iOS. Current FCM sending uses the HTTP v1 API.
Device Tokens
Tokens identify an app installation, not a person. A user may have several devices, and tokens change after reinstalls, restores or at the service's discretion. Send the latest token to your backend at every launch, associate it with the signed-in user, remove it on logout, and delete tokens that APNs or FCM report as invalid.
Notification Permissions
iOS requires the user's permission to show alerts, and offers provisional authorization that delivers quietly to the Notification Center first. On Android 13 and later, apps must request the POST_NOTIFICATIONS runtime permission. On both, ask when the user can see the value, for example after they place an order, rather than on first launch.
Android vs iOS Considerations
| Area | iOS | Android |
|---|---|---|
| Delivery service | APNs | FCM |
| Permission | Required; provisional option | Runtime permission on Android 13+ |
| User categories | Notification settings per app; interruption levels | Notification channels per category |
| Rich content | Notification service and content extensions | Expanded styles, images, actions |
| Background data messages | Throttled; not guaranteed | Subject to battery optimizations |
Payloads and Deep Linking
Keep payloads small (both APNs and FCM cap payload size) and include a route or deep link identifying where the tap should go, plus an ID for analytics. Don't put sensitive personal data in the visible text, which can appear on a locked screen. The deep linking guide covers routing, including signed-out users and missing content.
Planning notifications for your app?
ZSpace designs and builds notification systems end to end: permission UX, backend sending, deep links and analytics.
Transactional vs Marketing Notifications
Transactional notifications, like order shipped, payment failed or appointment tomorrow, are expected and valued. Marketing notifications, like promotions and re-engagement, need more restraint. Separate them into categories or channels so users can keep the useful ones while muting the rest, and follow the platforms' rules on promotional content and consent.
Segmentation, Personalization and Scheduling
Send notifications based on what users have done and said they want, not to everyone at once. Respect time zones and quiet hours, cap frequency per user, and schedule time-sensitive messages close to the moment they matter.
Rich Notifications and Notification UX
Images, action buttons and grouped threads make notifications more useful when they carry real information. Write short, specific text, lead with what changed, and make the tap destination obvious. Provide in-app notification preferences in addition to system settings.
Handling Notification Taps
The app may be closed, in the background or in the foreground when a tap arrives. Handle all three. Route to the destination screen, prompt sign-in first if needed and then continue to the destination, and show a helpful state if the content has been removed.
Analytics and Delivery Failures
Track sends, delivery results reported by the push service, opens, the actions taken afterward, and opt-outs by category. Log errors from APNs and FCM, remove invalid tokens, and alert on sudden drops in delivery that may signal expired credentials. See mobile app analytics for measuring impact beyond opens.
Common Implementation Mistakes
- Requesting permission on first launch without context
- Never refreshing or cleaning up device tokens
- Sending marketing messages through a transactional channel
- Taps that open the home screen instead of the relevant content
- Sensitive data visible on the lock screen
- No frequency caps or quiet hours
- Ignoring push service error responses
Want your notification strategy reviewed?
Talk to ZSpace about notifications users keep enabled, with the analytics to prove they're working.
Conclusion
Push notifications work when the plumbing is reliable (tokens, payloads, error handling) and the content is timely, relevant and easy to control. Ask for permission in context, deep link every tap, separate transactional from marketing messages, and measure what users do next. For the wider build context, see the mobile app development guide.
Common questions
Your backend sends a message to the platform push service, Apple Push Notification service for iOS or Firebase Cloud Messaging for Android, addressed to a device token. The service delivers it to the device, and the operating system displays it or passes it to the app.