Push Notifications: The Architecture Most Apps Get Wrong

What you need to know

• Push notifications that are irrelevant, poorly timed, or too frequent cause users to disable all notifications from the app. A disabled notification channel is worse than no notification feature.
• User-level notification preferences (per notification category, not just on/off) are a prerequisite for a sustainable push notification strategy.
• Timezone-aware delivery is not optional. Sending a marketing notification at 11pm in the user's timezone generates unsubscribes and app store reviews.
• Device tokens for APNs and FCM expire and become invalid when users reinstall the app or change devices. The backend must handle token invalidation gracefully.
• Notification delivery rates are not 100 percent. Track delivery confirmations and open rates to understand the real reach of each notification type.

The core argument

Push notifications are one of the highest-value user re-engagement mechanisms available to mobile apps, and one of the most consistently misimplemented features. The implementation mistakes are predictable: notifications sent to all users simultaneously without timezone awareness, notifications sent regardless of whether the user is currently active in the app, no mechanism for users to control which notification types they receive, and no measurement of whether notifications are producing engagement or driving unsubscribes.

The architectural problems stem from notifications being added as a feature after the core product is built, rather than designed as part of the product architecture from the start. A notification system bolted on after launch typically stores device tokens in the user table (rather than in a separate tokens table that handles multiple devices per user), sends notifications from synchronous request handlers (which doesn't scale for large user bases), and has no mechanism to track delivery or engagement (making optimization impossible).

The right architecture treats the notification system as a domain: a service that manages user notification preferences, device tokens (with multiple devices per user), notification history, delivery tracking, and frequency constraints. Notifications are triggered by application events (new message, activity notification, scheduled reminder) and processed by the notification service, which applies preferences, frequency caps, timezone constraints, and targeting before dispatching to FCM/APNs. This separation allows the notification system to evolve independently from the rest of the application.

Common mistakes

1. Sending the same notification to all users at a fixed time. A scheduled notification for an event should be sent at an appropriate time in each user's timezone, not at one universal time. A marketing email that references "this morning's update" should arrive in the morning in the recipient's timezone, not in the afternoon for half the user base.

1. Not implementing exponential backoff for delivery retries. APNs and FCM occasionally return temporary errors. Retrying immediately on error creates retry storms. Implement exponential backoff for delivery retries, with a maximum retry count after which the notification is dropped.

1. Not handling token expiration and invalidation. Device tokens become invalid when the app is uninstalled or when the OS refreshes the token. APNs returns specific error codes for invalid tokens (InvalidDeviceToken, Unregistered). The backend must remove or update invalid tokens based on these responses; sending to invalid tokens wastes API calls and may trigger rate limiting.

1. No notification history or delivery tracking. A notification system that sends notifications but does not record what was sent, when it was sent, and whether it was delivered or opened cannot be optimized. Track notification history, delivery status, and engagement metrics from the start.

1. Asking for notification permission immediately on app launch. iOS requires explicit user permission for push notifications. Asking for this permission on first app launch, before the user has experienced the app's value, produces low opt-in rates. Ask for permission at a moment of clear value: after the user completes an action where a notification would be helpful ("We'll send you a notification when your report is ready. Enable notifications?").

Where to start

1. Design the notification preference schema before implementation. Define the notification categories from the user's perspective, the default state for each category (opted in or opted out by default), and which categories are mandatory (security alerts). Build the preferences UI and backend storage before building any notification triggers.

1. Use a managed notification service for the delivery layer. Services like Expo Push Notifications, OneSignal, or Courier handle the FCM/APNs integration, token management, delivery tracking, and retry logic. Building this from scratch is significant infrastructure work that managed services provide as a product.

1. Implement timezone-aware delivery for any notifications that are time-sensitive. Store the user's timezone in the user record (or infer it from the device at registration time). Any scheduled notification should calculate the delivery time relative to the user's timezone.

Related reading

• Native iOS Development in 2026: SwiftUI, Combine, and the New Stack
• Native Android Development in 2026: Compose, KMP, and Where It Is Going
• PWA vs Native App: The Decision Every Startup Faces
• Job Failure Recovery: How Good SaaS Companies Sleep at Night