In this guide
A permission prompt is a one-shot question in front of a stranger. Ask too early and many people decline without knowing what they decline. Platform behavior differs. On Android 13 (API 33) and higher, notifications need the runtime permission POST_NOTIFICATIONS. If your app targets Android 13 or higher, it controls when the dialog appears, and Android's documentation advises letting users get familiar with the app first. If the user taps "Don't allow", the app cannot send notifications (with few exceptions). Apps targeting Android 12L or lower are not prompted again after one "Don't allow" until reinstall. For iOS, check Apple's current developer documentation before you design the flow.
The principle: value first, then ask
Ask when the user has just seen why notifications help them. Not at first launch.
Good moments: - After the user completes something that naturally has a follow-up (placed an order, booked a slot, saved a reminder). - When the user taps a control such as "Remind me" or "Notify me when it arrives". - After a second or third session, when the app has proven useful.
Weak moments: - The very first screen. - Before the user can know what the app does. - Together with several other permission requests.
Use a pre-prompt (soft ask)
Show your own screen first, then trigger the system dialog only if the user agrees.
- One line on the benefit in the user's terms: "Get a message when your order ships."
- Two clear choices, for example "Turn on" and "Not now".
- On "Not now", do not trigger the system dialog. You keep the chance to ask again later, and the user never hit a permanent "no".
Keep the pre-prompt honest. It must describe what you really send.
Explain why, in one sentence
Name the concrete benefit and, where relevant, the frequency. Compare:
- Weak (example): "Allow notifications to stay up to date."
- Better (example): "We'll tell you when your delivery is 10 minutes away. Nothing else."
If the user says no
- Do not nag. Re-asking on every launch annoys users.
- Keep the feature working without push where possible, with in-app cues instead.
- Offer a calm path later: a settings entry that explains how to turn notifications on.
- Retry only in a new context, such as when the user uses a feature that clearly benefits.
Test the wording and timing
Run one change at a time and compare the opt-in share between cohorts. Variables to try: the moment, the pre-prompt text, the number of choices. With small user numbers, treat differences as direction. Do not compare against external averages; your audience and app type decide what is normal.
Also watch the effect after opt-in: if users who allowed notifications turn them off a week later, the problem is the messages, not the prompt. See writing push notification text.
If children may use your app
Rules for apps aimed at children are stricter. See apps for children: store categories and policies.
Checklist
- [ ] Prompt appears after value is visible
- [ ] One benefit sentence, true to what you send
- [ ] Soft ask before the system dialog
- [ ] "Not now" does not burn the system prompt
- [ ] App works without push
- [ ] Settings path to enable later
- [ ] Wording and timing tested
Testers can tell you in a few minutes whether your prompt feels fair. Ask for private, structured feedback.
Related: ASO and launch hub, Writing push notification text, Apps for children.