The one rule that matters: never fire the system permission prompt cold. Show your own screen first, tied to something the user just did, explaining exactly what notifications they will get and why those are worth having. Then, and only for users who said yes to your screen, trigger the system prompt. Everything else in this guide is refinement of that pattern.
Why the prompt is so expensive to waste
On iOS, the system notification prompt is effectively one-shot: once a user declines, you cannot show it again, and recovering them means convincing them to dig through the Settings app, which almost nobody does. Since Android 13, Android works the same way, with a runtime prompt that stops showing after repeated denials. A cold prompt on first launch converts your single attempt at the moment the user has the least reason to trust you.
And the stakes are real: opt-in is far from universal. Batch's 2025 push notification benchmark put average opt-in around 56% on iOS and 67% on Android, with Android falling fast as the runtime-permission change rolls through the installed base. Published figures vary by vendor and vertical, but every source agrees on the shape: roughly half of iOS users say no, and the gap between well-asked and badly-asked apps is enormous.
The pre-permission pattern
A pre-permission screen (sometimes called a soft ask or primer) is your own native screen shown before the system prompt. It works for three reasons:
- It preserves your one shot. Users who decline your screen never see the system prompt, so the OS-level permission is still winnable later at a better moment.
- It lets you make an argument. The system prompt is fixed text; your screen can say "we will remind you 10 minutes before your workout" instead of "App would like to send you notifications."
- It filters for intent. Users who tap yes on your screen accept the system prompt at very high rates, because they already decided.
When to ask
Ask at the moment the user creates something worth being notified about, because that is when the value of notifications is self-evident:
- Right after a goal, plan, or streak is set up: "want reminders that keep this on track?"
- After a first meaningful action: an order placed, a listing saved, a message sent.
- When enabling a feature that only works with notifications: price alerts, delivery updates, mentions.
- Never on first launch, never stacked with other permission prompts, and never as a blocking wall the user must answer to continue.
For most apps this lands somewhere in the second half of onboarding, after the personalization questions have produced something concrete to be reminded about. If a user declines the primer, let it go and re-ask weeks later at a different trigger moment, with different framing.
What the primer screen should say
- Name the specific notifications, not the category. "Your daily lesson reminder at 8pm" beats "stay up to date."
- Tie it to the user's own stated goal. You asked personalization questions; use the answers.
- Offer an honest decline. A visible "not now" keeps trust and keeps the system prompt in reserve.
- One screen, one decision. No bundling with location, camera, or tracking prompts.
Measure it like a funnel
Track primer views, primer accepts, system-prompt accepts, and opt-in rate by cohort. Then iterate on timing and copy like any other conversion surface. This is exactly the kind of change that should not wait for an app release: with Setgreet, permission primer flows are native screens you can retime, reword, and A/B test live, and the funnel for each variant is in the analytics out of the box.
Primer copy patterns that keep working
- The commitment callback. "You set a goal of 3 workouts a week. Want a nudge on workout days?" The user is agreeing with their own plan, not with your marketing.
- The concrete preview. Show the actual notification, styled like the real thing, on the primer screen. Users say yes to a specific message and no to an abstraction.
- The control offer. "Choose what we send" with two or three toggles (reminders yes, news no). Granting control raises accepts and lowers later revocations.
- The loss frame, used honestly. "Price alerts only work with notifications on." True for alert-type features; manipulative anywhere else. Do not borrow it where it does not apply.
And a pattern to retire: the double-negative guilt screen ("No thanks, I do not want to reach my goals"). It converts a point or two better in the short term and shows up in one-star reviews forever. Notification permission is the beginning of a channel relationship; opening it with a shove sets the tone for every message after.
For users who declined the primer, keep a re-ask path alive: wait for a genuinely new trigger (a new goal, a first order, a feature that needs alerts), not a calendar interval. A re-ask that arrives with new context reads as helpful; the same screen on a timer reads as nagging. Two or three well-spaced attempts is the practical ceiling before you are farming resentment.
Frequently asked questions
What is a good push notification opt-in rate?
Vendor benchmarks put averages around the mid-50s percent on iOS and 60s to 90s on Android depending on the source and year measured, with wide category spread. More useful than the absolute number: your primer-accept rate should be well above your cold-prompt baseline, and trending up as you refine timing.
Can I show the iOS notification prompt twice?
No. Once declined, the system prompt cannot be re-shown; the user must enable notifications manually in Settings. This is exactly why the pre-permission screen exists: your own screen can be shown again, the system prompt cannot.
Does Android need a primer screen too?
Since Android 13, yes. Notifications require a runtime permission with deny behavior similar to iOS, and opt-in rates on new Android versions have dropped accordingly. The same primer pattern applies on both platforms.