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.
The default approach (and why it fails)
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.
Context turns a permission into a favor
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.
The “yes mode” effect
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.
Build a pre-permission screen
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.
What to avoid
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.
The numbers that matter
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.