Push Notifications in Mobile Apps: Permission and Good Practice

Permission comes first, on both platforms

Apple's Human Interface Guidelines on notifications say that before you can send any notifications to people, "you have to get their consent". On Android, the notification runtime permission page says that when someone installs an app on a device running Android 13 or higher, its notifications are off by default, and the app must wait until the person grants the POST_NOTIFICATIONS permission.

On both platforms the system shows the permission prompt, not your app, and people can change their minds later in the device settings. So the design question is not whether to ask but when and how, and how to keep people from switching notifications off again.

Asking on iPhone and iPad

Apple's article Asking permission to use notifications explains that an app requests permission for the kinds of interaction it uses, such as alerts, sounds and badges on the app icon. Key points:

• You effectively get one prompt. The first time the app asks, the system prompts the person and records the answer. "Subsequent authorization requests don't prompt the person." After a refusal, they can only turn notifications on in Settings.
• Ask in context. Apple suggests that a task-tracking app might ask after the person schedules a first task, and says this "provides a better experience than automatically requesting authorization on first launch".
• Provisional authorization lets an app send notifications on a trial basis without asking first. They are delivered quietly: no sound or banner, not on the lock screen, only in Notification Center's history, with buttons to keep or turn off notifications from the app. It suits apps whose value is easier to show than to explain.
• Check before sending. Apple says to check the app's authorization status before scheduling local notifications, because people can change it at any time.

Asking on Android

From Android 13 (API level 33), POST_NOTIFICATIONS is a runtime permission. Android's documentation describes three outcomes of the prompt:

• Allow: the app can send notifications, and all its notification channels are allowed.
• Don't allow: the app cannot send notifications unless it qualifies for one of a few exemptions, much as if the person had turned off all its notifications in settings.
• Swiping the dialog away: the permission does not change.

When the prompt appears depends on the app's target SDK version. If the app targets Android 13 or higher, it has "complete control over when the permission dialog is displayed". If it targets Android 12L or lower, the system shows the dialog itself, usually at app start, and Android warns that if the person taps "Don't allow" even once, they are not asked again until they reinstall the app or it is updated to target Android 13 or higher. That is one more reason to keep an app's target SDK current; see our guide to mobile app maintenance.

Before sending, the app should check that notifications are still enabled. Android also reminds developers that people "can see the number of daily notifications that your app sends, and they can revoke the permission at any time".

When to ask

Both platforms give the same advice: let people see the value of the app first, then ask at a moment that makes the reason obvious. Android's examples of good moments include when someone taps an "alert bell" button, follows an account, or submits a food delivery order, and it suggests explaining "why the user should opt in". Some apps wait until people have used them a few times. The same timing applies to other permissions; our app onboarding guide covers the first run as a whole.

• Do not ask on the very first screen, before the person knows what the app does.
• Tie the request to something the person just did or asked for, such as tracking an order or a reminder.
• If you show your own explanation screen first, keep it short and honest about what you will send.
• Keep the app fully usable for people who say no.

Let people choose what they get

Most apps send more than one kind of notification: order updates, messages, reminders, offers. People are more likely to keep notifications on if they can switch off the kinds they do not want rather than all of them.

On Android this is built in. The notification channels documentation says that since Android 8.0 (API level 26) "all notifications must be assigned to a channel", and that people can change the settings of each channel, which the system calls "categories". Once a channel is created, the app cannot change its notification behaviour; "the user has complete control at that point". Android recommends a channel for each type of notification, so a "Promotions" channel kept separate from "Order updates" lets people turn off offers without missing deliveries.

On iPhone, Apple notes that after agreeing, people generally use settings to choose notification styles and delivery times. A settings screen inside the app, with simple switches for each type, works on both platforms and is a good place to put the marketing opt-in described below.

What a good notification looks like

Apple's Human Interface Guidelines describe a notification as "timely, high-value information" people can understand at a glance. Their best practices include:

• Keep it concise and informative.
• Avoid sending several notifications about the same thing, even if someone has not responded; it fills up Notification Center and "people may turn off all notifications from your app".
• Do not use a notification to show an error; use an alert in the app.
• When the app is open, show new information quietly, for example with a badge, instead of a notification.
• Avoid sensitive, personal or confidential information, because others may see the screen.

Open the notification at the right place: tapping an order update should go to that order, not the home screen. Send at sensible times for the person's time zone, and measure what happens after a notification is opened; our guide to Google Analytics 4 covers events and measurement on the web side.

Marketing and promotional pushes

Apple's App Review Guidelines, section 4.5.4, are explicit:

• Push notifications must not be required for the app to work.
• They should not be used to send sensitive personal or confidential information.
• They should not be used for promotions or direct marketing unless customers have "explicitly opted in to receive them via consent language displayed in your app's UI", and the app provides a way to opt out.
• Abuse "may result in revocation of your privileges".

Agreeing to the system prompt is not, on its own, the opt-in to marketing that Apple describes; it needs its own consent wording in the app. On Android, a separate promotions channel and an in-app switch give people the same control. Check Google Play's current developer policies before you launch as well; our guide to publishing to the App Store and Google Play covers store review. Data protection and marketing laws can apply as well, as they do for email; see our email marketing rules guide.

Checklist

• A written list of the notification types the app will send, and why each is useful.
• The permission is requested in context, after a relevant action, not on first launch.
• The app works fully without notifications.
• Android: targets a current SDK, declares POST_NOTIFICATIONS and uses one channel per notification type.
• iPhone: considered provisional authorization; checks authorization status before sending.
• Marketing pushes only after a separate, explicit in-app opt-in, with an easy opt-out.
• No sensitive information in notification text; each notification opens the right screen.
• Frequency limits, sensible sending times, and tracking of opens and opt-outs.

If your product is a website rather than an app, web push is also possible; our guide to progressive web apps explains what installable web apps can do.

Frequently asked questions

When should an app ask for notification permission?

After the person has seen what the app does, and at a moment that makes the reason clear, such as after they place an order or set a reminder. Apple says asking in context provides a better experience than asking on first launch, and Android gives similar advice.

Can I ask again if someone says no?

Not with the system prompt on iPhone: Apple says later authorization requests don't prompt the person, so they have to turn notifications on in Settings. On Android, an app targeting Android 12L or lower is not asked again after a refusal until it is reinstalled or updated to target Android 13 or higher.

What is provisional authorization on iOS?

An option that lets an app send notifications on a trial basis without asking first. They arrive quietly in Notification Center, with no sound, banner or lock screen alert, and include buttons for the person to keep or turn off the app's notifications.

Can I send marketing push notifications?

On the App Store, only if customers have explicitly opted in through consent language shown in your app, and the app offers a way to opt out, under App Review Guideline 4.5.4. Accepting the system permission prompt is not that opt-in on its own.

What are Android notification channels?

Since Android 8.0, every notification must belong to a channel, and people can change the settings for each channel separately. Use one channel per type of notification, such as order updates and promotions, so people can switch off one without losing the other.

Planning an app and want notifications people keep switched on? See how we approach mobile app development, see all our services, or email info@creahive.com.