--- title: Why arent my apps push notifications being delivered description: Learn why your app push notifications are not being delivered, covering permissions, token expiry, OS blocks, server failures, and timing issues. image: https://weareaffective.com/hubfs/learning-centre-images/why-arent-my-apps-push-notifications-being-delivered.webp --- [Skip to content](https://weareaffective.com/learning-centre/why-arent-my-apps-push-notifications-being-delivered#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Why arent my apps push notifications being delivered Table of Contents Push notifications feel simple. The app sends a message, the phone shows it, the user taps it. That is the mental model teams typically carry into their first campaign, and it holds up right until the moment their delivery rate drops to something embarrassing and nobody can explain why. The technical pipeline is actually longer than it looks, and any single break in that chain means the notification never arrives, with no error message for the user and often no clear signal for the team either. > Push delivery fails at multiple points in the chain, not just the server sending the message. The question "why aren't my notifications being delivered?" has a dozen possible answers, and most of them are not server errors. Some live in the moment the user first sees the permissions prompt. Some live in the order of events during onboarding. Some live in the operating system, or in Apple's review process, or in the gap between when a message is sent and when it is actually useful. Getting a handle on delivery means understanding the whole chain, not just the sending end. This article walks through each of those points in order, including some of the less obvious ones that tend to surface only after a team has already spent time and money debugging the wrong layer. ## How Push Notifications Actually Reach a Device The default assumption is that push notifications are something a backend sends directly to a device. The actual route is longer. When a user installs an app and grants notification permissions, the operating system generates a [unique token for that device and app combination](https://weareaffective.com/learning-centre/what-app-developers-need-to-know-about-sending-alerts-notifications-to-users). The app's server stores that token. When you want to send a notification, your server passes the message to a platform notification service, either Apple Push Notification Service or Firebase Cloud Messaging on Android, and that service is responsible for delivering it to the device. That means your notification is only as reliable as two things you do not fully control: the platform service, and the token itself. Tokens expire, get rotated when a user reinstalls the app, or become invalid if a device is restored from a backup. A backend that sends to stale tokens will record a send event without ever reaching anyone. The device also has to be reachable. Poor network connectivity, battery optimisation settings, or an app that has been force-closed on certain Android manufacturers can all stop delivery at the last step. The message was technically sent. It was never received. The distinction matters because fixing a sending problem and fixing a delivery problem are entirely different things. ## Why Permissions Are Granted or Denied at the Point of Asking On iOS, users see the permission prompt once. If they tap deny, the only path back is through the Settings app, and most people do not go there. That single moment carries enormous weight, yet a lot of apps waste it entirely by asking at the wrong time or in the wrong way. The psychology behind the grant or deny decision is mostly about [perceived control and perceived value](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you). If a user already understands what the app does and why notifications would help them, they are far more likely to say yes. If the prompt appears before they have seen anything useful, they default to caution. According to [Delon Apps](https://delonapps.com/blog-detail/why-so-many-mobile-apps-fail-after-launch-and-how-to-avoid-it), apps that ask without priming the user first see acceptance rates below 15%. The framing of the ask matters too. There is a meaningful difference between demanding access and asking for it. Phrasing like "is it okay if we send you updates about your order?" puts the user in control in a way that a default system prompt does not. People who feel they chose to receive notifications treat them differently from people who feel they were opted in without consent. That difference shows up in open rates and in how quickly users turn notifications off inside settings after the fact. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Timing and Context of the Permissions Prompt One of the clearest patterns we see in poorly performing notification programmes is a permissions prompt that appears within the first few seconds of an app opening, before the user has seen a single screen of content. It is a genuine frustration, and it is also a predictable cause of low opt-in rates. A user who has not yet understood what they are signing up for has no reason to say yes, and plenty of instinct telling them to say no. The alternative is what we think of as [narrative onboarding: letting users experience enough](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one) of the product to understand its value before asking them for anything. On a concierge app we worked on, we designed the notification permission request to appear only after a user had completed a key action inside the product, so the ask arrived with obvious context. The user already knew what kind of updates would be coming, which made the decision feel sensible rather than arbitrary. > A permissions prompt that arrives before any value is shown is asking for trust without giving a reason. [Timing also interacts with emotional state](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl). A user who is mid-task and engaged is in a different frame of mind from a user who just opened an app for the first time and is still orienting. Asking during a moment of natural pause or task completion tends to outperform asking on entry. The permission prompt is a moment of relationship-building, and it repays being designed carefully. Use a custom pre-prompt screen before the system dialogue. Explain what kind of notifications users will receive and why those notifications benefit them. The system prompt comes second, with context already set. ## Early Registration and What It Does to Your Permission Rate Forced early registration is one of the most consistent causes of drop-off during onboarding, and it creates a specific problem for notification delivery that teams often miss. If a user abandons the onboarding flow before completing registration, they typically cannot be reached by push at all, because you have no valid token stored against a known account. Notifications require an identified user and a live token. An anonymous install with a dismissed registration screen gives you neither. Across our work, we see a [15 to 20% drop in uninstalls when registration is forced early](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) in the session. That is a pool of users who will never receive a single notification, regardless of how well the rest of the messaging stack is built. The notification system cannot compensate for losing those users before they reach it. On the anonymous messaging app we built that required upfront registration by necessity, the consequence was that all the value communication we would normally drip-feed through the in-app experience had to be front-loaded into the App Store listing instead. Screenshots, descriptions, and metadata had to do work that product onboarding usually handles. It was a workable solution, but it required significant effort and it confirmed the cost of early registration as a design constraint rather than just a preference. Where registration cannot be deferred, make the App Store listing carry the full value proposition. Users who do not yet know what the app offers will not complete registration, and no notification strategy recovers that loss. ## Device-Level and OS-Level Reasons Notifications Are Blocked Even when a user has granted permissions and you have a valid token, the device itself can still block delivery. The operating system applies its own rules, and those rules vary by version, manufacturer, and user configuration in ways that are not always visible to your team. On iOS, Focus modes introduced in iOS 15 let users silence apps selectively, and notifications sent during an active Focus session are held until it ends or dropped entirely depending on settings. Low Power Mode deprioritises background processes, which can delay time-sensitive notifications by minutes or hours. On Android, the fragmentation is wider because manufacturers apply their own battery management layers on top of the base OS, and some of these are aggressive enough to kill background processes that would otherwise receive messages. | Block type | Platform | Visible to user | Visible to team | | --- | --- | --- | --- | | Focus mode / Do Not Disturb | iOS, Android | Yes | No | | Low Power Mode | iOS | Yes | No | | Manufacturer battery management | Android | Sometimes | No | | App-level notification settings | iOS, Android | Yes | No | | Stale or invalid token | Both | No | Via error response | The last column of that table is the practical problem. Delivery failures at device level are largely invisible to the sending team. You see a send confirmation; the user sees nothing. The only reliable way to surface this is building delivery receipts into your analytics and tracking gaps between sent and confirmed-received rather than assuming a sent event equals a delivery event. ## Server-Side Failures, Token Expiry, and Network Instability Token management is the backend problem that teams most often underestimate. A push token is not permanent. It becomes invalid when a user reinstalls the app, restores a device, or on iOS, when the system rotates it. If your backend continues sending to an old token, APNS will return an error and eventually blacklist it, but teams that do not actively process those error responses end up with token registries full of dead entries and delivery rates that erode silently over time. Network instability adds a further layer. Notifications sent to a device that is temporarily offline are queued by the platform service for a limited window, typically a few hours on APNS. If the device does not come online within that window, the message is dropped. For time-sensitive notifications, this means a message about a flash sale or a short availability window can arrive hours after it is relevant, which is arguably worse than not arriving at all. Server-side delivery failures, rate limiting, malformed payloads, authentication errors with the platform service, are easier to detect but still require active monitoring. A push campaign that sends successfully to 80% of tokens and silently fails on the rest looks like a partial success in aggregate data and a total failure for the users who received nothing. Build active token hygiene into the backend from the start. Process APNS and FCM error responses in real time, mark invalid tokens immediately, and prompt users to re-register when a token rotates rather than continuing to send into the void. ## App Store Review as an Upstream Delivery Problem Push notification delivery does not start at the send event. It starts at the moment the app ships, and if the [app cannot ship, the whole stack is moot](https://weareaffective.com/app-architecture-design-we-are-affective). App Store review is an upstream constraint that most product teams treat as a formality, right up until it delays or kills a launch. We experienced this directly on a currency exchange app where the client's product was rejected by Apple repeatedly, despite meeting every stated compliance requirement. Each time we addressed Apple's stated objection, a new one appeared. The final rejection cited potential use for money laundering; we responded by capping transactions at €150, which should have removed the concern. Apple rejected the app again anyway. The client ran out of budget and abandoned the product. It later became apparent that the rejections coincided with the build-up to Apple Pay's launch, which suggests the rejections served a competitive purpose rather than a genuine compliance one. That experience makes a point that extends beyond one product. If your app sits in review for three weeks, your notification strategy is paused for three weeks. If it is rejected, every user who would have received those notifications is unreachable until the issue resolves. For apps in regulated categories, payments, health, supplements, certain travel products, review timelines and rejection risks are part of the delivery planning, and ignoring them is a planning failure. ## How Notification Timing Kills Delivery Even When Everything Else Works A notification can reach the device, display correctly, and still fail to do anything useful if it arrives at the wrong moment. Timing is a core part of whether the notification lands with the user or gets swiped away without engagement. On the concierge app we designed for new homeowners, the default approach would have been a fixed delay: send the first notification two days after move-in. We pushed back on that because the reality of moving day varies significantly. Someone who arrives at a property in the morning will start unpacking that day. Someone who arrives in the evening probably will not unpack until the next morning. We [ran focus groups and scenario research](https://weareaffective.com/learning-centre/how-to-pressure-test-a-product-concept-with-people-who-arent-your-target-users-y) to understand those patterns, then built a dynamic timing system that factored in both the time of arrival and the number of people in the household, reasoning that a single occupant unpacks more slowly than a household of two or three. The result of that design decision was measurable. A/B testing with real users showed significantly lower stress levels among people who received delayed, context-sensitive notifications compared to those who received everything upfront. The notifications were perceived not as alerts demanding action but as timely, helpful prompts. Timing was the variable that made the difference, and it was a design choice, not a technical one. ## What a Genuine Audit of Failed Delivery Actually Looks Like When a team comes to us because their notifications are underperforming, the answer is almost never in one place. A genuine audit works through the full chain, not just the layer that looks most suspicious. 1. Check the opt-in rate first, split by platform. A rate below 40% on iOS points to a permissions timing or framing problem, not a sending problem. According to [Mobiloud](https://www.mobiloud.com/blog/push-notification-statistics), the average iOS opt-in rate sits at 43.9%, compared to 91.1% on Android, so a gap between your platforms is expected, but a dramatic underperformance on one signals a structural issue. 2. Audit the token registry. What percentage of stored tokens are less than 30 days old? What is the error rate on recent sends? Are error responses being processed and acted on? 3. Review the timing of the permissions prompt in the onboarding flow. Did the user see any product value before the ask arrived? 4. Check device-level delivery logs against sent events. If your platform shows sends but not receipts, the block is downstream of your server. 5. Review message timing. Are notifications going out at times when they are likely to coincide with sleep hours or commute patterns in your key markets? 6. Check notification cadence against user preference settings. A useful diagnostic question: could a user reduce the frequency of notifications without losing anything they actually want? If the answer is yes, the cadence is serving the platform's retention targets rather than the user's needs, and users will opt out or ignore. An audit that finds one problem usually finds more. These failures tend to cluster because they share a root cause: [notification design was treated as a feature to add rather than a system to design](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) from the start. ## Why These Problems Are Harder to Fix After Launch The permissions prompt can only be shown once on iOS. A user who said no at launch is effectively unreachable by push for the lifetime of their install, unless they choose to re-enable notifications in Settings, which a small fraction of users do. That means the opt-in rate at launch is largely fixed. Getting it wrong at the start has a permanent cost. Token hygiene and backend architecture are also considerably cheaper to build correctly the first time than to retrofit. A backend that was not designed to process delivery error responses from APNS and FCM requires meaningful rework to add that capability. The data needed to audit those failures is often not being captured at all, which means the team cannot even measure the problem before deciding whether to fix it. On the map-based fitness social network we worked on, users were dropping off at the point where they were asked to share their location with a potential match. The drop-off happened because the location request arrived before users had any chance to have a conversation with or learn about the other person, so a high-trust action was being asked for before trust existed. Moving that request later in the flow required restructuring the product sequence, not just changing a prompt. The later the problem is found, the larger the fix. Building notification design into the product brief from the first sprint costs almost nothing. Diagnosing and reworking it six months after launch, with a live token registry full of denied permissions and stale tokens, costs substantially more. ## Conclusion Push notification delivery is a chain, and it fails at each link in its own way. The permissions prompt that fires too early, the token registry that nobody is maintaining, the timing logic that sends at 2am, the App Store review that blocks the app from shipping at all, none of these announce themselves with an obvious error. They degrade silently, and teams often mistake the absence of complaints for evidence that everything is working. The diagnostic question that cuts through a lot of this is simple: can a user reduce the frequency of your notifications without losing anything they actually value? If they can, the notification system is working for retention targets rather than for the user, and users eventually respond to that by opting out entirely. Good notification design starts before the first line of code is written. The permissions moment, the onboarding sequence, the token architecture, the timing logic, these are design decisions with delivery consequences, and they are far easier to get right at the start than to correct afterwards. The teams with strong delivery rates tend to have treated notifications as a relationship rather than a broadcast, asking permission, delivering genuine value, and timing messages to the user's actual context rather than their own sending schedule. If your notification delivery is underperforming and you want to understand where the chain is breaking, [let's talk about your notification strategy](https://weareaffective.com/get-started). ## Frequently Asked Questions Why do push notifications sometimes fail to arrive even when the server shows they were sent? The delivery pipeline is longer than most people assume. Your server passes the message to a platform service such as Apple Push Notification Service or Firebase Cloud Messaging, and that service is responsible for the final delivery to the device. A failure at any point in that chain, including poor network connectivity or battery optimisation settings on the device, means the notification never arrives even though a send event was recorded. What causes push notification tokens to become invalid? Tokens expire, get rotated when a user reinstalls the app, or become invalid if a device is restored from a backup. If your backend is sending to stale tokens, it will register a send event without the message ever reaching a real person. Keeping your token store up to date is essential for accurate delivery rates. Why does the timing of the permissions prompt matter so much on iOS? On iOS, users are shown the permission prompt only once, and if they tap deny the only way back is through the Settings app, which most people never visit. Asking too early, before the user has seen any value from the app, leads to a default response of caution. Research suggests apps that ask without priming the user first see acceptance rates below 15%. How can I improve the chances of a user accepting the notification permissions prompt? Users are more likely to grant permission when they already understand what the app does and why notifications would benefit them. Showing value first, before triggering the prompt, significantly improves acceptance rates. The framing of the request also matters, as explaining the benefit rather than simply demanding access makes a practical difference. Do Android and iOS handle push notification delivery differently? Yes, there are meaningful differences between the two platforms. Android uses Firebase Cloud Messaging, while iOS relies on Apple Push Notification Service, and each has its own rules around token management and delivery behaviour. Certain Android manufacturers also apply aggressive battery optimisation that can block delivery at the device level, even when the message has been successfully sent. Why might a team struggle to diagnose push notification delivery failures? When a notification fails to arrive, there is typically no error message shown to the user and often no clear signal returned to the sending team either. This makes it easy to assume the problem sits at the server level when it may actually be a permissions issue, a stale token, or a device-side delivery problem. Understanding the full chain, not just the sending end, is necessary before debugging can be effective. What is the difference between a sending problem and a delivery problem? A sending problem means the message did not leave your server or was rejected by the platform notification service. A delivery problem means the message was accepted by the platform service but never reached the device, often due to network issues, device settings, or an app that has been force-closed. The distinction matters because the fixes for each are completely different. Can the order of events during onboarding affect push notification delivery rates? Yes, the sequence in which users move through onboarding can have a significant impact on whether they grant notification permissions. If the prompt appears before users have experienced anything useful, they are far more likely to decline. Building in context and demonstrated value before asking for permissions is a practical step that affects long-term delivery rates. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.