Both Android and iOS now make your app ask before it can send most push notifications, and both give you very few chances to ask. On iOS the system prompt can appear only once. On Android it can appear twice. When you ask and how you explain the request matter more than the request itself.
This guide covers how each platform handles the permission and which parts you can control. It also covers a few edge cases that can keep notifications from reaching people who already said yes.
What changed in Android 13
Before Android 13, apps were opted in to notifications automatically. A user who did not want them had to go into settings and turn them off. Android 13 reversed this. Notifications are now opt-in, and apps must request the POST_NOTIFICATIONS runtime permission before they can send non-exempt notifications.
Not every notification falls under the new rule. Media notifications tied to ongoing playback are exempt. On Android 12 and below, the permission is always granted, and requesting it does not show the user anything.
Who sees the prompt, and when
The behavior depends on which Android version your app targets. If it targets Android 13 or higher, a new install on an Android 13 device cannot send notifications until the app prompts the user. Your app decides when that happens. To get that control, your app must target Android 13, which is API 33.
Apps that target a lower version do not get that choice. The operating system shows the prompt itself the first time the app runs on an Android 13 device. You lose the chance to pick a better moment.
People who upgrade their phone are handled more gently. If your app was already installed before the device moved to Android 13, it can keep sending notifications on a temporary grant until the first qualifying app launch. Users who had already granted permission are not affected.
How many chances you get
This is the part that catches most teams off guard. The limits differ by platform, but on both they are strict.
| Situation | Android | iOS |
|---|---|---|
| Times the system prompt can appear | Two | One |
| After the limit is reached | Further requests are denied automatically, with no dialog | The prompt cannot be shown again |
| Prompt dismissed by tapping outside it | Shown again the next time the user opens the app | Not applicable |
Once a user denies the permission, your app cannot prompt again. The only path back is for that person to turn notifications on in system settings. On Android, there is a second way to lose access too: Play Protect automatically revokes push permission for users who have been dormant for a long time.
What you can and cannot control
You cannot change the wording of the system prompts on either platform. You can choose when to trigger them. That timing is the main lever you have, so treat each prompt as a scarce resource.
On iOS, your app requests permission through UNUserNotificationCenter's requestAuthorization(options:) method, passing options such as alert and badge. The system then shows an alert where the user can allow or deny.
Building a better ask
Since the system prompt is fixed and limited, most of the work happens before it appears. These approaches can help:
- Show your own pre-permission screen or in-app message first. Explain what the user gets from your push notifications. This screen can be shown any number of times and often leads to higher opt-in rates.
- Trigger the system request after a meaningful action, such as a purchase or following a team. At that point the reason for notifications is intuitive.
- Offer an in-app notification preferences page so people can choose what they receive. Apps with one were observed to have better opt-in rates.
- Make thematic requests tied to a specific topic rather than one broad ask. These were also observed to improve opt-in rates.
Your own screen does not use up a system prompt, so it lets you test the user's interest first. If someone says no to your screen, you can ask again later. If they say no to the system prompt, you may not get another chance.
Provisional authorization on iOS
iOS offers a quieter route. Since iOS 12, provisional authorization lets an app send notifications quietly to the Notification Center without showing the permission prompt at all. Each of those notifications includes a prompt asking whether the user wants to keep receiving them.
This lets people see real examples of your notifications before deciding. They judge the actual content, not a promise about it.
Edge cases that can hide your notifications
A granted permission does not always mean a delivered notification. From Android 15, apps installed in the Private space do not show push notifications while that space is locked. Your app cannot detect whether it is installed there, so some silent gaps in delivery may have no visible cause on your end.
Putting it together
The rules on both platforms push in the same direction. You get one or two system prompts, you cannot reword them, and a denial sends the user to settings if they ever change their mind. On Android, you only control the timing if your app targets API 33.
So spend your effort on the moment and the message around the prompt. Explain the value on your own screen, wait for an action that makes the reason clear, and give people ways to choose what they receive. None of this promises a yes. It does give users a fair reason to agree before you spend a chance you cannot get back.