If mobile app push notifications are not working, diagnose the delivery chain in order: user permission, operating-system settings, app registration, device token, backend send request, push-provider response, and on-device display logic. A successful request from your server does not prove that the customer saw a notification. You need evidence from each stage and a test that reproduces the failure on the affected platform, app version, and app state.

This guide is for teams whose Android or iPhone app sends no notifications, reaches only some users, delivers late, or behaves differently in the foreground and background.

Mobile app push notifications not working: define the failure first

“Notifications are broken” is too broad to debug. Collect a small set of facts before changing code:

• Is the issue on Android, iOS, or both?
• Does it affect every user or a particular app version, device model, or operating-system version?
• Does the notification fail when the app is open, in the background, or fully closed?
• Do transactional notifications fail, marketing notifications fail, or both?
• Was the problem introduced after an app release, certificate change, backend deployment, or messaging-provider update?

Use one known test user and one known device for each platform. Record the app version, operating-system version, permission status, device-token timestamp, send timestamp, provider response, payload type, and what appeared on the device. This evidence turns a vague complaint into a reproducible path.

Check whether the user allowed notifications

On Android 13 and later, most app notifications require the POST_NOTIFICATIONS runtime permission. Declaring it in the app manifest is not enough; the app must request it at an appropriate moment, and the user can deny it. Android’s current notification-permission documentation also explains how permission behaves for app updates and restored devices.

On Apple devices, the app requests authorization through the User Notifications framework. The user may allow alerts but change other options later in Settings. Apple’s authorization guidance recommends asking in context, when the user understands why the notification is useful.

Your app should detect the current authorization state rather than assuming that an earlier “allow” decision still applies. If notifications are disabled, explain the benefit plainly and offer a route to system settings. Do not repeatedly pressure users or disguise a permission prompt.

Verify Android notification channels

Android 8.0 and later uses notification channels. Each notification must reference a valid channel, and users can change a channel’s importance, sound, vibration, and visibility. Android states that when an app targets API level 26 or higher and posts without a notification channel, the notification does not appear.

Check that the channel is created before the first notification uses it, that the payload references the correct channel ID, and that the user has not disabled that channel. Android’s channel documentation should be the source of truth for implementation details.

Design channels around understandable categories such as order updates, appointment reminders, account security, and promotions. One catch-all channel makes it harder for customers to keep essential notifications while muting optional ones.

Confirm app registration and device-token handling

Push providers address an app installation through a registration token or device token. That identifier can change after reinstalling the app, restoring a device, clearing app data, or other registration events. The client app should send refreshed tokens to your backend, and the backend should associate them with the correct user and app environment.

For Apple Push Notification service (APNs), Apple explains that the app must register with APNs so the service knows the device address. The app then receives a device token that must reach the notification provider. Review Apple’s APNs registration workflow when an iOS installation never receives a token.

For Firebase Cloud Messaging (FCM), remove tokens that the provider reports as unregistered or invalid rather than continuing to send to them. Protect tokens in logs and support tickets as application identifiers.

Read the provider response, not just your application log

A backend log that says “send function completed” may only mean that your code called an API. Capture the HTTP status, provider error code, message identifier, target platform, payload type, and timestamp.

Firebase documents specific errors for invalid registrations, malformed requests, rate limits, and authentication failures. Its FCM error-code reference notes that a third-party authentication error for an iOS target can indicate missing or invalid APNs credentials. Check that the credential belongs to the correct Apple developer team, app, and production environment.

Retry temporary failures with controlled backoff, remove permanently invalid tokens, and fix bad credentials or malformed payloads rather than resending them.

Test payload and app-state behaviour

Push systems distinguish between provider-handled notification content and data that the app processes. Behaviour can differ when the app is open, backgrounded, or terminated. A payload that displays automatically in the background might require your app to render an in-app banner while it is in the foreground.

Use a minimal known-good payload first. Then add deep links, images, custom sounds, data fields, localization, and action buttons one at a time. Validate platform-specific fields rather than assuming one payload behaves identically on Android and iOS. Firebase’s cross-platform message guidance supports common fields plus Android-, Apple-, and web-specific configuration.

Check message lifespan as well. A short-lived alert may expire while a phone is offline, while a stale promotional notification should not arrive days late. Choose time-to-live values according to the business event instead of applying one default to every message.

Separate delivery from display and user action

Track three different outcomes:

1. The push provider accepted the message.
2. The device received or displayed it.
3. The user opened it and completed the intended action.

Do not collapse these into one “sent” number. Available delivery reports and client events should state exactly what each measurement proves.

Add a correlation ID that follows a message from the business event through the backend and provider response. Do not put personal data in that ID. For critical flows, log the app version, platform, notification category, token reference, send time, response, and relevant client event. Set retention and access rules so diagnostics do not become an uncontrolled store of customer data.

Use a small test matrix before a wider release

Test	What it isolates	Expected evidence
Android with permission granted and denied	Runtime permission and app explanation	Correct status handling in both cases
Each Android notification channel	Channel creation, ID and importance	Notification appears in the intended category
iOS development and production builds	APNs environment and credentials	Valid token and provider response for each build
Foreground, background and terminated app	Client display and message handling	Documented behaviour in every app state
Fresh install and upgraded install	Permission onboarding and token refresh	Backend stores the current registration

Run the matrix on real devices; one developer phone is not production-ready evidence.

A practical example: appointment reminders arrive only on iPhone

Suppose a booking app sends appointment reminders to iPhone users, but Android 13 users receive nothing. The backend reports successful FCM requests.

The team should first confirm notification permission on an affected Android device. Next, verify that the reminder channel exists and that the payload uses its exact ID. Then check the device’s current FCM token, the provider response for that token, and behaviour in each app state. If the app never requested Android’s runtime notification permission after an update, changing message copy or sending more retries will not fix delivery.

When should you involve a mobile app developer?

Developer help is appropriate when permissions are handled correctly but failures remain platform-specific, tokens are not refreshing, provider credentials are invalid, app-state behaviour is inconsistent, or a release changed notification handling. Bring the failing payload, provider response, anonymized token reference, test-device details, app version, notification settings, and exact timestamps.

Ishu Technology provides mobile app development services covering Android, iOS and cross-platform applications, API and backend integration, testing, deployment, and ongoing support according to project requirements. To discuss a notification issue, share the affected platforms, app version, provider and reproducible test through the verified Ishu Technology contact page.

Frequently asked questions

Why do notifications work on one phone but not another?

The devices may have different permission settings, notification-channel choices, app versions, operating-system versions, tokens, battery policies, or network conditions. Compare those variables with the same test payload.

Does a successful FCM or APNs response guarantee delivery?

No. It confirms a particular provider-side stage, not necessarily display or user action. Interpret the exact response and combine it with available delivery and client evidence.

Why do notifications work in the background but not while the app is open?

The operating system may display some background notifications automatically, while the foreground app is expected to handle the message and decide what interface to show.

Should the app ask for notification permission at first launch?

Not automatically in every case. Ask when users understand the value—for example, after enabling order updates or appointment reminders—and explain what they will receive.

Android, Firebase and Apple documentation reviewed on 27 October 2026. Platform behaviour and console interfaces can change, so confirm current requirements for the app’s target OS versions and messaging SDKs.