The average opt-in rate for push notifications on iOS is around 51%. That means half the people who download your app will never hear from you again after they close it, unless you change how you ask.
The problem isn’t that users hate notifications. It’s that most apps ask for permission at the worst possible moment, with zero context.
Most apps fire the system notification prompt during onboarding, right after the user opens the app for the first time. The user hasn’t done anything yet. They don’t know what the app does. They don’t trust it. And now it’s asking to send them alerts.
The result: they tap “Don’t Allow” and you’ve lost that channel permanently. iOS doesn’t let you ask again. The only way back is sending the user to their phone settings, and nobody does that.
The fix is simple: give the user a reason before you ask.
Instead of a generic “We’d like to send you notifications,” create a moment where the notification makes sense. A bedtime story app doesn’t ask for notification permission. It asks “What time does your kid go to sleep?” The user picks a time. The app says “We’ll remind you when it’s story time.” Then the system prompt appears.
Now the user isn’t granting a permission. They’re activating a feature they just set up.
During onboarding, users are in what behavioral researchers call a compliance momentum state, or more simply, “yes mode.” They’re tapping through screens, answering questions, making choices. Each small “yes” makes the next one easier.
Smart apps exploit this by placing the notification request inside that flow of yeses. After the user has picked their preferences, chosen their goals, and customized their experience, a notification request feels like one more natural step. Not an interruption.
Asking outside of this flow, like in a settings screen or a random popup three days later, breaks the momentum and drops acceptance rates significantly.
Apple lets you show your own custom screen before triggering the system prompt. Use it.
A pre-permission screen explains what notifications you’ll send and why they matter. “Get a reminder at bedtime so you never miss story time.” “We’ll let you know when your weekly report is ready.”
If the user taps “Not now” on your custom screen, you haven’t burned the system prompt. You can try again later with better timing. If they tap “Yes,” then you trigger the real iOS prompt, and they’re almost guaranteed to accept because they already said yes once.
Don’t ask on the first screen. The user doesn’t know you yet.
Don’t be vague. “Stay updated with the latest news” tells the user nothing. What news? How often? Why should they care?
Don’t ask for everything at once. If your app also wants location, camera, and health data, spreading those requests across the experience (each in context) converts far better than a wall of permission prompts.
Don’t send garbage after they accept. The fastest way to get notifications turned off is sending irrelevant or too-frequent alerts. One daily notification tied to a habit is valuable. Five promotional pushes a week is spam.
Opt-in rate: What percentage of users accept notifications? Track this against your pre-permission screen acceptance rate to see where you’re losing people.
Notification-driven retention: Do users who accept notifications retain better at D7 and D30? They almost always do, apps with push notifications enabled see retention rates 3-10x higher than those without.
Disable rate: Are users turning notifications off after accepting? If so, you’re sending the wrong content or too much of it.
I went through every permission ask I could find in a set of onboarding flows. Not one went straight to the raw iOS dialog. Priming is now the default rather than the clever move, so the question is no longer whether to prime but what your primer does in the half-second after the tap.
Whatnot · showing the notification instead of describing it
Rather than describing what the alerts will be, the primer renders two real notifications on a mock lock screen. The user approves a specific thing they can see, not a category.
Works when the mocked notifications are the ones you will actually send. That screen is a sample, and it sets the expectation you get judged against.
Backfires when the mock shows the best-case notification and the real stream turns out to be promotional. The first off-promise push is when the permission gets revoked.
Vocabulary · settling frequency before asking
The primer lets the user set how often and during which hours, before the system prompt appears at all.
Works when the objection is volume rather than the notifications themselves, which for most productivity and learning apps it is. You are answering the real fear instead of the stated one.
Jira Cloud · offering less than iOS can give
The primer offers mentions-only versus everything. iOS itself grants all or nothing, so the narrower choice has to be honoured on your own server.
Works when you genuinely respect the narrower setting. Offering less is a strong reason to say yes.
Backfires when the granular promise exists only on your screen and the user gets everything anyway.
Attio and Pillow · the half-second nobody designs
Both were captured at the instant iOS takes over, and in both the system alert lands on top of the primer's own text. The user ends up reading Apple's wording, not yours, at the exact moment they decide.
Works when the persuasion has already happened above the fold, so the alert is a confirmation rather than the first ask.
Backfires when the alert fires automatically on load. Nothing has been read yet, and the reflex on an unexplained system dialog is Don't Allow.
The thing to take from all four: iOS gives you one prompt per permission, and once it is spent the only route back is Settings, which almost nobody takes. A reluctant yes is worth barely more than a no, so the screen before it is doing all the work.
Reading about it is one thing. Knowing which change is worth making on your funnel, and what it is costing you today, takes a look at your numbers. I’ll do that and tell you what I’d fix first.
See App OptimizationConversion design for app creators. Screenshots, paywalls, onboarding — one funnel, not three projects.