- Ask for notification permission at a moment tied to something the user just did, not on first launch with no context.
- On iOS the system prompt appears once; on Android 13 and later notifications are off by default until the user grants permission.
- Provisional authorisation on iOS lets you deliver quietly first and let people decide after they see a real notification.
- Marketing pushes need explicit opt-in and an opt-out inside the app under Apple's App Review Guidelines.
- Separate notification types, so people can turn off promotions without losing order updates.
When should a mobile app ask for push notification permission?
Ask at a moment that is tied to something the user just did, so the value of the notification is obvious: after they place an order, book an appointment, follow someone or set a reminder. Asking on first launch, before people have seen what your app does, spends your best chance on a likely "no". Both Apple and Google say this in their own developer guidance, and on iOS you can also start with provisional notifications that arrive quietly until the user decides.
The plumbing of push, meaning device tokens, the sending service and the server logic, is covered in our mobile app back-end checklist. This guide is about the part users see: the request, the messages and the settings that decide whether your notifications keep getting through.
Why does the first request matter so much?
On iOS, the first time an app asks, the system prompts the person and records the answer; Apple's documentation says subsequent authorization requests don't prompt the person. After a refusal, the only way back is the Settings app.
On Android 13 and higher, a newly installed app's notifications are off by default until the user grants the POST_NOTIFICATIONS permission. Android's general permission rules add that if the user taps Deny for the same permission more than once, the dialog stops appearing and the denial is treated as permanent. Older apps that still target Android 12L or lower have even less control over when the prompt appears, which is one more reason to keep your target version current.
Permission is also not a one-time fact. People can change it in Settings whenever they like, so Apple advises apps to check the authorization status before scheduling notifications. Your app and your server should both treat "notifications off" as a normal state and fall back to email or an in-app inbox for anything that matters.
When is the right moment to ask?
Google's Android guidance lists examples such as the user tapping an alert bell, choosing to follow an account or submitting an order for food delivery. Apple gives a task app as its example: ask after the person schedules a first task, because they can then see the purpose your notifications serve.
| App | A good moment to ask | What the user gets |
|---|---|---|
| Ordering or delivery | Right after the first order is placed | Order and delivery updates |
| Bookings | When an appointment is confirmed | Reminders and changes |
| Community or social | When the user follows a person or topic | Replies and new posts |
| Productivity | When the user sets a first reminder or deadline | The reminder itself |
Many apps show their own short explanation screen first and only trigger the system prompt if the user taps to continue. That keeps the one-time system prompt for people who are likely to say yes.
What is provisional authorisation on iOS?
Provisional authorisation lets an iOS app send notifications on a trial basis without asking first. They are delivered quietly: no sound or banner and nothing on the lock screen, only in Notification Center, with buttons to keep or turn off future notifications. It suits apps whose value is easier to show than to explain, such as a news or price-alert app. The trade-off is that quiet notifications are easy to miss, so it works best when the first few are clearly useful.
Which notifications should you send, and which need extra consent?
- Transactional: order, booking, payment and account updates the user expects.
- Reminders: things the user asked to be reminded about.
- Activity: replies, mentions, messages and changes to things they follow.
- Marketing: offers, new products and re-engagement messages.
Apple's App Review Guidelines (section 4.5.4) say push notifications must not be required for the app to function, should not carry sensitive personal or confidential information, and should not be used for promotions unless customers have explicitly opted in through consent language in the app, with a way to opt out inside the app. Build that consent and the in-app setting before the first campaign, not after a rejection.
How do you avoid getting muted?
- Do not repeat yourself. Apple's Human Interface Guidelines warn that sending several notifications about the same thing fills Notification Center and that people may turn off all notifications from your app.
- Split notification types into channels. Since Android 8.0, every notification must be assigned to a channel, and users can change each channel's settings; separate channels let people silence promotions while keeping order updates.
- Offer your own settings screen with the same categories, quiet hours and a clear off switch per type.
- Write for the lock screen. Short, specific text with no private details, because others may see the screen.
- Open the right screen. A notification about an order should open that order, not the home screen.
What should you measure?
Track the share of users who grant permission on each platform, which screen they were on when asked, how many later turn notifications off, and what they do after opening one. Measure by notification type, because a drop after a marketing campaign tells you something different from a drop after a product change. Our mobile app development team plans these events with the permission flow, and the UI and UX design work covers the explanation screens and settings. If you are still choosing between an installable web app and a native one, our guide to PWA or native app explains how push differs on the iPhone.
Frequently asked questions
Can we ask again after a user says no?
Not with the system prompt in most cases. iOS does not show it again, and Android stops showing it after repeated refusals. What you can do is explain the benefit inside the app at a relevant moment and offer a button that opens the app's notification settings, where the user can turn notifications on themselves.
Should we show our own screen before the system prompt?
Often, yes. A short screen in your own design that says what you will send and why gives people the context the system prompt lacks. Let them choose "Not now" on your screen, which keeps the one-time system prompt available for a later, better moment instead of spending it on a likely refusal.
How often is too often?
There is no safe number that suits every app. A useful test is whether each notification would still be welcome if the user saw only that one today. Combine related updates into one message, respect quiet hours in the user's time zone, and watch how many people turn notifications off after each campaign.
Do web apps on iPhone get push notifications?
Yes, with a condition: the web app has to be added to the Home Screen, and the permission request has to follow a tap such as a subscribe button. Visitors who only use the site in Safari cannot receive them, so plan that step into onboarding if push matters to your product.
Should important messages go by push, SMS or email?
Push is the cheapest and fastest, but people can turn it off at any time and it never reaches users who refused it. For messages that must arrive, such as security alerts or booking changes, send push plus email, and use SMS where the customer has agreed to it and the message is urgent.
Last updated