Permission and notification screens: when and how to ask?

In short

In a mobile app, location, camera, microphone or notifications need a permission. The phone’s operating system opens the permission dialog. The Android developer documentation says it clearly: the app can’t customise this dialog.

The same documentation points to a gap. The system dialog says which permission is being requested, but not why. Two things close this gap: the right moment and, if needed, a short explanation before the system dialog.

This is called permission priming. Here I describe where that screen sits in the flow. The copy for the screen is in the permissions section of the microcopy examples.

What iOS and Android say about the notification permission

On both platforms you can’t send notifications without the user’s consent. The difference lies in how often and when the dialog appears. The points below come from Apple’s and Android’s developer documentation.

• iOS

  • Before the first notification, the user’s consent is needed. The system shows the dialog.
  • On the first request, the system asks the user and stores the answer. Later requests don’t open a dialog.
  • You can request provisional authorisation. Notifications then arrive quietly and only in Notification Center. There the user decides whether to keep them or turn them off.
  • The user can change the app’s permissions at any time.

• Android

  • With Android 13 (API 33), the notification permission became the runtime permission POST_NOTIFICATIONS.
  • In newly installed apps, notifications are off by default.
  • If your app targets Android 13 or higher, you choose when the dialog appears. If it targets 12L (API 32) or lower, the system usually asks at launch.
  • If the user swipes the dialog away, the permission state doesn’t change. A permission declined twice counts as permanently declined.

Android has one more trap. If your app targets 12L or lower and the user says “Don’t allow” once, the system doesn’t ask again. That holds until the app is deleted and reinstalled or an update comes that targets Android 13.

On phones updated to Android 13, eligible older apps get the permission automatically. If the user had turned notifications off before, that decline still applies after the update. For differences in navigation and dialogs, see the guide differences between iOS and Android.

Ask in context

Apple’s privacy page says to avoid asking for permissions at launch. The only exception: the app doesn’t work without the permission. Its example is a navigation app that is useless without location.

For notifications, Apple’s developer documentation gives a task app as an example. The permission is requested after the user has scheduled their first task. According to the documentation, the user then sees what the notifications are for.

Android’s page on the notification permission also recommends giving users time to get to know the app first. As good moments it names: the user taps a bell, follows an account or orders food. Waiting until the third or fourth launch of the app is named as an option too.

In a package tracking app, this moment is clear. When the user opens a shipment and looks at its status, the question “Should we let you know when it is out for delivery?” makes immediate sense. At launch, on the other hand, it is unclear what they would be notified about.

The Android documentation also describes the transparency side. Its example is an email app: there you choose whether you want a notification for every new email or only for emails where you are the only recipient. Saying what you send notifications for raises the chance that the user agrees.

The priming screen

In most cases you don’t need a separate priming screen. According to Apple, ideally the current context explains the permission by itself. If the user has pressed “Notify me” on the shipment screen, it is clear what they want.

If a separate screen is needed, different rules apply on the two platforms:

• iOS: the HIG ask for a single button that opens the system dialog. Its label should be something like “Continue”, not “Allow”. The HIG say not to offer an additional action such as Close or Cancel. The only exception: it is needed to collect legal consent.
• Android: the documentation always asks for a way to cancel in the rationale flow. In the sample code, this rationale screen only appears when shouldShowRequestPermissionRationale() returns true.

With this rule, Apple wants to keep users from being misled. If the button on the priming screen looks like the Allow button in the system dialog, the user may press it without noticing. With the tracking permission, Apple is even clearer. Showing an image of the system dialog or pointing to the Allow button counts among the designs that lead to rejection. I collect such tricks in the dark patterns guide.

If you show the priming screen on both platforms with the same code, split the buttons by platform. For the order in the flow, see also the onboarding pattern. Don’t tie the permission to onboarding steps but to the user’s first real task.

Try it: ask at launch, ask in context

Open the same parcel app with two different timings. First decline with “Ask at launch”, then open the shipment and press the bell. Then do the same with “Ask in context”.

At launch or in context?

This example runs with JavaScript. Without JavaScript, read the difference between the two flows in the text above and below.

The Example Parcel app, its copy and the plain rendering of the system dialog are mine. The dialog copies neither Apple’s nor Google’s interface. The demo asks only once. On iOS a second request opens no dialog; on Android a permission declined twice counts as permanent.

Someone who declines at launch has used up your only chance without seeing what the bell is for. Someone who declines in context knows what they are declining. The shipment status stays on the screen in both flows.

What happens when the user declines?

The short answer: the app keeps working; only this feature is missing. The Android documentation names five principles after a decline. I apply them to the screen like this:

1. Keep losses small. Without notifications, the shipment status still stays up to date in the app.
2. Direct attention to the right place. Show the message where the feature’s result would appear. In the parcel example, that is the box with the bell.
3. Be specific. Instead of “Some features may not work”, say which feature doesn’t work.
4. Don’t block the interface. Don’t stop the user with a full-screen warning.
5. Respect the decision. The documentation considers it disrespectful to keep reminding users to change their mind.

A note in the sample code matters too. The documentation says not to link to the system settings after a decline to persuade the user. That is why, in the demo, the way to settings doesn’t appear at the moment of decline, but only when the user presses the bell again.

At Apple the rule is shorter. According to the documentation, the system stores the answer on the first request, and later requests don’t ask the user. For someone who changes their mind, show the way to the Notifications section of Settings.

The way to settings

After a decline you may link to settings, but watch the timing. Show the way when the user asks for the same feature again themselves. Showing a banner “Turn on notifications” as soon as they enter the screen, on the other hand, is nagging.

Both platforms have a direct way to notification settings. On iOS, UIApplication.openNotificationSettingsURLString came with iOS 16 and opens the app’s notification settings. On Android, Settings.ACTION_APP_NOTIFICATION_SETTINGS came with API 26 and shows the notification settings of a single app.

Next to the link, say in one sentence what the user should do there. Check the permission again for users coming back from settings too. Apple’s and Android’s documentation remind you that the user can change the permission at any time. So check the state before each notification: on iOS with notificationSettings(), on Android with areNotificationsEnabled().

Once you have the permission

You get the permission once, but the user can withdraw it at any time. The Android documentation writes that the user can see how many notifications the app sends per day and revoke the permission at any time.

Apple’s page on notifications also recommends not sending multiple notifications for the same thing. The reason: Notification Center fills up, and the user can turn off all of the app’s notifications. If you promised two notifications for the shipment, “out for delivery” and “delivered”, don’t add promotions.

My note

The most common permission problem in audits of mobile apps is the launch screen. The app opens, and before the user even sees the logo, dialogs for notifications, location and tracking come one after another. The user closes all three with the same reflex.

In second place is silence after a decline. When the permission is declined, the feature quietly disappears, and no explanation stays on the screen. The user never finds out why they get no notification about the shipment.

Try this in your own product. Delete the app, reinstall it and decline every permission. Then note on each screen what doesn’t work and whether the screen tells you.

If you want to rebuild this flow in your product: the Design & Ship Sprint covers permission screens from design to code.

Checklist

• The permission is requested when the user starts the task that needs it.
• If it is requested at launch, the app really doesn’t work without this permission.
• If the context doesn’t explain the permission, there is a short explanation before the system dialog.
• The iOS priming screen has a single button labelled “Continue”.
• The Android rationale screen has a way to cancel.
• The priming screen doesn’t imitate the system dialog or point to the Allow button.
• After a decline the app works and names the missing feature.
• The link to settings only appears when the user asks for the feature again.
• The permission state is checked before each notification.
• No more than one notification is sent for the same event.