On iOS you get one notification permission prompt, and the moment you pick is the decision.
The push notification permission prompt is the system dialog that asks whether your app may send notifications. Apple is blunt about how many you get. The first time your app makes the authorization request, the system prompts the person and records the answer, and subsequent requests do not prompt at all. Android works differently and the rule arrived later. Android 13, API level 33, turned notifications into a runtime permission called POST_NOTIFICATIONS, so a new install starts with notifications switched off until you ask. Every screen name, flag and API name below comes from Apple's and Google's own documentation, read on 21 October 2026. Most people meet this step while publishing to the App Store.
What follows is when each platform lets you show the dialog, how many refusals it takes before the dialog stops appearing for good, what Apple offers instead of a dialog, and what is left to you once somebody has said no. The two platforms disagree on nearly all of it, and one of the differences depends on a single line in your Android build config.
Start hereThe short version
Ask late, ask once, and read the answer before every send.
On iOS you call requestAuthorization on the shared UNUserNotificationCenter, listing only the interaction types you actually use: alerts, sounds, badges. Apple tells you to call it before you schedule any local notifications and before you register with the Apple Push Notification service. The first call shows the dialog and the system stores the answer. Later calls change nothing a person can see. So the timing of that one call is the whole decision.
On Android you declare POST_NOTIFICATIONS in the manifest and request it like any other runtime permission. If your app targets Android 13 or higher, Google says your app has complete control over when the permission dialog is displayed. If it still targets 12L, API level 32, or lower, the system picks the moment for you, and it usually picks app startup. That is the line in your build config, and it costs you both the timing and the second ask.
When can iOS show the prompt, and can it be shown twice?
The answer to the second half is no, and Apple says it twice. The Asking permission to use notifications article says the first time your app makes this authorization request, the system prompts the person to grant or deny the request and records that response, and that subsequent authorization requests do not prompt the person. The reference page for requestAuthorization repeats it in its own words and adds that the system stores the response. Neither page describes any way to make the dialog appear a second time. Both read on 21 October 2026.
The first half is left to you, with advice rather than a rule. Apple says to make the request in a context that helps people understand why your app needs authorization, and gives its own worked example: in a task-tracking app that sends reminder notifications, ask after the person schedules a first task. It calls that a better experience than automatically requesting authorization on first launch, because people can see the purpose your notifications serve. There is no published quota, no waiting period and no second dialog. One call, whenever you decide.
The Boolean you get back is less useful than it looks. Apple's reference says the granted value is true when the person grants authorization for one or more of the options you asked for, and false when they deny authorization or when authorization is undetermined. A false does not tell you which of those two happened. Apple points you at getNotificationSettings to read the real authorization status, which is the call your code should be making anyway.
There is also a documented way to skip the dialog entirely. Add the provisional option to the request and the first call grants authorization automatically, with no prompt. Those notifications go out quietly: Apple says they do not interrupt with a sound or a banner and do not appear on the lock screen, and show up only in Notification Center history, carrying a Keep button and a Turn Off button. Press Keep and the system asks the person to choose between Deliver Immediately and Deliver in Scheduled Summary, and the summary option only appears if they have Scheduled Summary turned on in Settings. Deliver Immediately authorizes your app to send, but it does not give permission to show alerts, play sounds or badge the icon, so the notifications stay in the history until the person changes their settings. Press Turn Off and the system confirms the choice before denying your app authorization. Until they do one or the other, the status reads provisional.
Because provisional authorization never shows a dialog, Apple says you can request it when your app first launches. The person is only asked to keep or turn off notifications when they actually receive one, which is the trade: you give up the alert, the sound and the badge in exchange for letting your notifications argue for themselves. Apple's one-shot rule is not the only iOS deadline that catches a first release either. The ios sdk version deadline is the one that stops you uploading at all.
Apple, Asking permission to use notifications, read 21 October 2026
Work out where you stand
What you can still do, by what already happened
Pick the state your app is in. The answers come from the two platform pages linked on this page, read on 21 October 2026.
On iOS
Your one prompt is still in hand. Call requestAuthorization at the moment the person does something that implies they want to be told about it.
On Android
Notifications are off by default on a new install on Android 13 or higher. Declare POST_NOTIFICATIONS in the manifest, then launch the request at a moment you choose, as long as you target 13 or higher.
Read the live status in code before every send. Both platforms let people change their mind in system settings without telling your app.
What changed on Android 13 for notification permission?
Notifications stopped being free. Google's Notification runtime permission page, which prints its own last updated date of 16 October 2026, says Android 13, API level 33, and higher supports a runtime permission for sending notifications that are not exempt, including foreground service notifications, called POST_NOTIFICATIONS. You add it to the manifest as a uses-permission entry and request it the way you request any other runtime permission. For a new install on Android 13 or higher, the page says your app's notifications are off by default and your app must wait until you have requested the permission and the user has granted it.
Who chooses the moment depends on your target SDK, and this is the part teams get wrong. If your app targets Android 13 or higher, Google says your app has complete control over when the permission dialog is displayed. If your app targets 12L, API level 32, or lower, the system shows the dialog the first time your app starts an activity after you create a notification channel, or when your app starts an activity and then creates its first notification channel, which Google says is usually app startup. In single-activity apps, and most Compose apps are single-activity, that means the moment MainActivity starts. Google recommends targeting 13 or higher as soon as possible for exactly this reason, which is also why the android target sdk deadline is worth tracking.
The dialog has three outcomes, not two. Allow, and the app can send notifications with all channels allowed, and foreground service notifications appear in the notification drawer. Don't allow, and the app cannot send notifications unless it qualifies for an exemption, with all channels blocked except for a few specific roles, which Google compares to the user switching your notifications off in system settings. Or the person swipes the dialog away without pressing either button, and the state of the notification permission does not change. That third outcome is the one worth knowing, because a dismissal costs you nothing.
Apps that already existed got a pass. When a user upgrades a device to Android 13 or higher, Google says the system automatically pre-grants the permission to all eligible apps, and those users do not see a runtime permission prompt. Eligible has two conditions: the app has an existing notification channel, and the user has not explicitly disabled its notifications on a device running 12L or lower. A denial from the old device persists through the upgrade. An app restored onto a new Android 13 device through backup and restore still counts as an existing app, so it keeps the pre-grant too.
Two kinds of notification sit outside all of this. Notifications related to media sessions are exempt from the behaviour change. So are apps that configure themselves to self-manage phone calls, which Google defines as declaring MANAGE_OWN_CALLS, implementing the ConnectionService interface and registering with the device telecom provider by calling registerPhoneAccount, and which can then send CallStyle notifications without the permission. Separately, apps do not need POST_NOTIFICATIONS in order to launch a foreground service, but they must still include a notification when they start one. If the permission is denied, the user sees foreground service notices in the Task Manager and not in the notification drawer.
Google, Notification runtime permission, last updated 16 October 2026, read 21 October 2026
How many refusals does it take before the dialog stops appearing?
One on iOS. Two on Android if you are current. One on Android if you are behind. That is the whole budget, and nothing refills it except the person uninstalling your app.
Android's two-refusal rule is written down on Google's Request runtime permissions page, which also prints a last updated date of 16 October 2026. It says that if the user taps Deny for a specific permission more than once during your app's lifetime of installation on a device, the user will no longer see the system permissions dialog if your app requests that permission again. It reads the second Deny as do not ask again and calls it a permanent denial, then warns you to prompt only when somebody needs the feature, because otherwise you lose the ability to re-request at all.
The same page gives you the flag names, which is how you check a test device instead of guessing. A permission denied once by the user is flagged USER_SET. A permission denied permanently by selecting Deny twice is flagged USER_FIXED. Both show up in the runtime permissions section of adb shell dumpsys package, and you clear them with adb shell pm clear-permission-flags before a test run. The notification permission page lists the exact command sequences for simulating a fresh install and for simulating a device upgrade, so you never have to factory reset a phone to test this.
Now the trap for anyone on an old target SDK. The notification permission page carries a caution of its own: if your app targets 12L or lower and the user taps Don't allow, even just once, they are not prompted again until they uninstall and reinstall your app, or you update your app to target Android 13 or higher. So an old target SDK does not only hand the timing to the system. It also spends your second ask on a dialog you did not choose to show.
Which makes the moment worth planning. Google's own list of good moments: the user taps an alert bell button, the user chooses to follow someone's social media account, the user submits an order for food delivery. It also suggests simply waiting until the third or fourth time somebody launches your app. And it is strict about the explanatory screen that teams like to add in front of the dialog. Google says your app does not need that middle screen unless shouldShowRequestPermissionRationale returns true, and its runtime permissions guidance has you check it only after checkSelfPermission has already come back denied.
Google, Notification runtime permission, last updated 16 October 2026, read 21 October 2026
What can you do once somebody has said no?
Read the state, drop the feature quietly, and offer Settings. Apple says to always check your app's authorization status before scheduling local notifications, because people can change the settings at any time and can also change which interaction types they allow, which may change the number or type of notifications you should send. The call is getNotificationSettings, and Apple's own example guards on a status of authorized or provisional, then branches on whether the alert setting is enabled: an alert when alerts are allowed, a badge and a sound when they are not.
One detail in that page saves a feature. Apple says you might want to configure your notification with alert, sound and badge information even when your app is not authorized for some of those interactions, because the system still displays alerts in Notification Center when the notification center setting is enabled, and your delegate still receives notifications while the app is in the foreground and can still reach the alert, sound and badge information. A partial no is not silence.
For the route into Settings, UIKit documents openSettingsURLString as the URL string you use to deep link to your app's custom settings in the Settings app. You build a URL from it and open it. That is the honest answer to a refusal: a line of your own text saying what the person is missing, and a button that takes them to the switch. Not a second dialog, because there is no second dialog to show.
Android gives you the same two moves with different names. Google says to confirm whether the user has enabled notifications before your app sends one, by calling areNotificationsEnabled. It also asks you to use the permission responsibly, noting that users can see the number of daily notifications your app sends and can revoke the permission at any time. The underlying principle from its runtime permissions guidance is the one to design around: if the user denies or revokes a permission a feature needs, degrade gracefully so they can carry on using the app, which usually means disabling the feature rather than nagging.
There is a paperwork consequence to all of this that people forget. A push token is an identifier that leaves the device, so turning notifications on turns a local-only app into one that collects something. That answer belongs on the google play data safety form and in the matching App Privacy answers, filled in before you submit rather than discovered during review.
Apple, Asking permission to use notifications, read 21 October 2026
One dialog, two rule sets
The two No answers below come from what the linked pages leave out, which is why each one names a page. Apple's two notification pages document no pre-grant and no second prompt. Google's notification permission page documents no trial mode like Apple's provisional option.
| The question | iOS | Android 13 and higher | Same on both |
|---|---|---|---|
| What the rule is called | Authorization requested through UNUserNotificationCenter | POST_NOTIFICATIONS, a runtime permission added in Android 13 | No |
| When the dialog appears | The first time you call requestAuthorization | When you launch the request, if you target Android 13 or higher | No |
| A second dialog after one refusal | No | One more, and a second Deny is permanent | No |
| A documented trial mode with no dialog | Yes, provisional authorization | No | No |
| Pre-granted without a dialog | No | Yes, for an eligible app when the device is upgraded | No |
| People can change the answer in system settings | Yes | Yes | Yes |
| You read the live state before sending | getNotificationSettings | areNotificationsEnabled | Yes |
Where this lands if a builder generated your app
Nothing in the rules changes because an AI wrote the code. The request is a function call, the manifest entry is one line, and the person deciding when to show the dialog is still you. The one piece of generated-app mechanics worth knowing is the Android channel. Expo's expo-notifications reference, read on 21 October 2026, says the Android 13 prompt will not appear until at least one notification channel has been created, and that setNotificationChannelAsync has to run before you call getDevicePushTokenAsync or getExpoPushTokenAsync to obtain a push token. Its wording describes the system-triggered prompt, which is the path Google says belongs to apps targeting 12L or lower. Either way, the channel comes first on Android.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, so the authorization call and the manifest entry are both files you can open and move. It runs the app on cloud iOS and Android simulators while it builds, uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, and keeps a two-way GitHub sync. It is $25 a month and there is no free tier.
Two honest limits. Newly does not submit to the App Store on your behalf, because Apple requires the owner of the app's content to submit it, so the review queue and the privacy answers stay with you. And no builder can pick the screen where somebody will say yes. Ask for notifications on the screen where a person has just set a reminder, followed an account or placed an order, and the one prompt you get is the one worth having.
Questions people ask about the notification permission prompt
No. Apple's documentation says the first time your app makes the authorization request the system prompts the person to grant or deny it and records that response, and that subsequent authorization requests do not prompt the person. Neither the Asking permission to use notifications article nor the requestAuthorization reference page describes a way to show the dialog again, both read on 21 October 2026. After a refusal your options are to read the real status with getNotificationSettings, explain in your own screen what the person is missing, and deep link to Settings using the openSettingsURLString constant UIKit documents.
Build the screen first, then ask from it
Decide which action in your app earns a notification, build that screen, and put the request behind it. Then the one prompt you are allowed arrives at the only moment it was ever likely to be accepted.
Start building