Join Community
Home Events Academy Speakers Organizers Stories Gallery Blog FAQs Join Community
← All courses

Push Notifications Architecture

🗓 May 31, 2026 • ⏱ 3 min read

How can a closed app get a message?

Your app isn’t running most of the time, yet it can receive a chat message or a breaking-news alert. This works through push notifications, delivered by the platform’s always-on service — FCM (Firebase Cloud Messaging) on Android, and APNs (Apple Push Notification service) on iOS. Understanding this flow is core mobile system design.

The end-to-end flow

Your backend FCM / APNs OS service App (notification)
  1. The app registers and gets a unique device token from FCM/APNs.
  2. The app sends that token to your backend, which stores it for that user/device.
  3. To notify a user, your backend tells FCM/APNs “send this to token X”.
  4. The platform delivers it to the device’s OS, which shows the notification (or wakes your app).

Notification vs data messages

  • Notification message — the system displays it directly; simplest for alerts.
  • Data message — delivered to your app code so you decide what to do (update the DB, show a custom UI, sync). More powerful and flexible.
  • Many apps use data messages to trigger a sync (“new messages available → fetch them”) rather than putting all content in the push.

Token management is the tricky part

Device tokens change (reinstall, restore, OS refresh). If your backend has a stale token, the user silently stops getting notifications. Design for this: refresh the token on app start, update the backend whenever it changes, and remove dead tokens when the platform reports them invalid.

Reliability & good behaviour

  • Push is best-effort — not guaranteed or instant. For critical data, also sync when the app opens; don’t rely on push alone.
  • Permissions — iOS (and Android 13+) require the user to grant notification permission. Ask in context, explain the value, handle denial.
  • Don’t spam — respect frequency and let users control categories (notification channels on Android).
  • Deep link — tapping a notification should open the exact relevant screen, not just the home screen.

Scaling considerations

At scale, your backend fans out notifications to millions of tokens via queues and batching, handles per-platform payload limits (~4KB), and tracks delivery/opens. As the mobile engineer, you design the client side: registration, token sync, message handling, deep linking and permissions.

Common mistakes

  • Not updating the backend when the device token changes (notifications silently stop).
  • Relying on push for critical data instead of also syncing on open.
  • Requesting notification permission at launch with no context (users deny).
  • Tapping a notification dumps the user on the home screen instead of deep-linking.
Summary: Push works via FCM/APNs: the app gets a device token, your backend stores it and asks the platform to deliver messages. Manage changing tokens carefully, prefer data messages that trigger a sync for critical content, request permission in context, deep-link on tap, and never rely on push alone for important data.