React Native push notifications combine JavaScript code, operating-system permissions, provider credentials, device tokens, and app lifecycle behavior. This guide gives you a platform-aware implementation plan for Expo and bare React Native projects, a repeatable way to estimate the work involved, and a testing process for diagnosing missing or misrouted notifications.
Overview
A push notification is not sent directly from a React Native component to a phone. The app first requests permission, obtains a device or push token, sends that token to your backend, and then relies on a notification service to deliver a message through Android or iOS infrastructure. The app must also decide what to do when a notification arrives in the foreground, background, or after the user taps it.
There are two common implementation paths:
- Expo notifications: A practical choice when your project uses Expo tooling and you want a managed integration around permissions, tokens, notification handlers, and response events. Native configuration is still required for development and release builds.
- Native messaging libraries: A suitable path for projects that already manage native Firebase or other provider integrations, need lower-level control, or have an existing bare React Native setup. The exact library and configuration should match your provider and current React Native version.
The most important architectural decision is to treat notification delivery as a server-backed feature. Do not assume that a token is permanent, that permission is granted, or that a successful send means the user saw the notification. Store tokens against an authenticated user or installation, update them when the app reports a change, and keep delivery logs separate from in-app notification state.
For broader release planning, connect this work with your React Native production readiness checklist. Push notifications affect credentials, release builds, privacy decisions, deep-link routing, and operational support.
How to estimate
Estimate push-notification work by counting platform behaviors and failure paths rather than counting only screens or API calls. A useful planning formula is:
Implementation scope = platform setup + permission flow + token lifecycle + delivery service + app-state behavior + navigation + test matrix + monitoring.
Start by answering these questions:
- Will the app use Expo notifications, a native messaging library, or an abstraction that supports both?
- Do Android and iOS need the same notification categories, sounds, badges, and actions?
- Must notifications open a specific screen or preserve parameters such as an order, message, or appointment ID?
- Does the app need data-only background handling, or are visible notifications sufficient?
- Will one account use multiple devices, and can one device switch accounts?
- How will the backend disable stale, rejected, or revoked tokens?
Each “yes” adds implementation and testing work. For example, a simple reminder with one destination screen has a smaller scope than a messaging system with multiple device tokens, notification categories, unread counts, background synchronization, and account switching.
Build a test matrix before writing the integration. At minimum, include Android and iOS, a physical device for each platform, permission granted and denied, foreground and background states, a terminated app, a cold start caused by tapping a notification, and an expired or replaced token. This is more useful than estimating from the happy path alone.
Inputs and assumptions
Platform and build inputs
Push notifications depend on native app configuration, so test them in a development or preview build that includes the required native capabilities. A simulator or emulator may not reproduce all device-token and delivery behavior. Confirm that the application identifiers, signing configuration, notification entitlements, Android configuration, and provider credentials belong to the same app environments you are testing.
If you are deciding between Expo and the React Native CLI, compare the native configuration requirements with the rest of your project rather than choosing only by notification support. The Expo vs React Native CLI guide provides useful context for that broader decision.
Permission assumptions
Permission is a user decision, not an installation result. Request it at a meaningful point in the product flow, explain the value before showing the system prompt, and provide a recovery path when permission is denied. On Android, configure notification channels deliberately; a channel’s behavior can be controlled by the user after creation. On iOS, request only the notification capabilities the product actually uses, such as alerts, sounds, or badges.
Token and backend assumptions
Keep the token lifecycle explicit. Register a token after permission and native setup are available, send it to your backend with the user or installation identifier, and update the record if the token changes. A user may have several active installations, so avoid a database model that permits only one token unless that limitation is intentional.
On logout, decide whether the installation should be unregistered, associated with an anonymous device record, or retained for another account after the next login. Never use a notification token as an authentication credential. Your backend should authenticate token-registration requests and validate notification payloads before sending them.
App-state assumptions
Define separate behavior for foreground, background, and terminated states. In the foreground, you may show an in-app banner instead of a system notification, update local state, or do both. In the background, the operating system and provider determine how visible and data payloads are handled. When the user taps a notification, process the response once, wait for navigation to be ready when necessary, and make the destination idempotent so repeated handling does not duplicate work.
Worked examples
Example 1: A basic Expo notification flow
For a small Expo application, scope the work as five units: request permission, obtain the Expo or provider token, register the token with the backend, configure a notification handler, and listen for notification responses. Add an Android notification channel if the app targets channel-based behavior, then test a visible notification while the app is foregrounded, backgrounded, and terminated.
The payload should contain a stable notification identifier and only the routing data required by the client. When a user taps the message, the app can use that data to navigate to a detail screen. The detail screen should fetch authoritative data from the API instead of trusting the notification body as the source of truth.
Example 2: A bare React Native app with native messaging
For a bare workflow, add native provider configuration to both platforms, connect the chosen React Native messaging library, request permissions where required, and implement token registration. Then define how notification and data messages are handled in each lifecycle state. The estimate must include native build and signing work, not just JavaScript changes.
Use separate development, staging, and production credentials where your release process requires isolation. Keep configuration out of committed source files when it contains sensitive provider information, and document the relationship between each app identifier, build profile, and notification environment.
Example 3: Diagnosing a notification that never arrives
Work from the device backward. First confirm that permission is enabled in system settings. Next log the token safely in a non-production debugging workflow and verify that the backend stored the expected value. Confirm that the send request targeted the right environment and that the provider returned an accepted or rejected result. On Android, inspect the channel and importance settings. On iOS, inspect authorization status and native capabilities. Finally, test whether the issue is delivery, foreground presentation, or tap-to-navigation; these are separate problems that often look identical to a user.
For debugging and release automation, pair this work with the React Native CI/CD guide. A repeatable build process reduces the chance that a local native configuration is missing from a release artifact.
When to recalculate
Revisit your push-notification estimate whenever the app adds a platform, changes its Expo or React Native version, replaces its messaging provider, changes application identifiers, or moves from development builds to store releases. Recalculate again when the product introduces notification actions, badges, categories, rich media, background synchronization, multiple accounts per device, or new deep-link destinations.
Review the implementation after a permission-flow change, an authentication redesign, or a backend data-model migration. These changes can create stale tokens, duplicate registrations, incorrect account associations, or links that open the wrong screen.
Use this final checklist before release:
- Test physical Android and iOS devices with fresh installations.
- Record granted, denied, and previously denied permission paths.
- Verify token registration, refresh, logout, and account switching.
- Check Android channels and iOS presentation behavior.
- Test foreground, background, terminated, and cold-start tap flows.
- Confirm that deep links validate identifiers and do not trust message text.
- Log provider responses and remove or quarantine invalid tokens.
- Repeat the matrix for every release configuration that can send notifications.
Push notifications are best treated as a small distributed system inside your React Native app. Estimating the full lifecycle—rather than only the permission prompt—produces a more reliable implementation and gives your team a clear procedure when delivery behavior changes.
