Asking For Notification Permission: The Second Time Is the Wrong Time

2026-07-14T11:00:00+02:00

I work on a B2C health app where notifications aren't a growth channel, they're half the product. The user sets a sleep goal, the app reminds them to wind down before bedtime. They pick a protocol with a daily action, the app nudges them to do it. Without notification permission all of that just doesn't exist for the user, they set goals in onboarding and then nothing ever follows up on them.

Our first onboarding didn't treat the permission with that much respect. We did it the way most apps do, at some point in the flow we called the API, the iOS dialog popped up with no context, and the user had to decide on the spot why an app they installed five minutes ago wants to send them things. Predictably, a lot of them tapped "Don't Allow".

We assumed we could ask again later, once the user had seen enough of the app to change their mind. That assumption was wrong, and it's the reason this post exists. On iOS the native prompt is a one-shot, once the user says no, calling requestPermissionsAsync() again just returns "denied" without showing anything. The only recovery is the user going to Settings, Notifications, Your App and flipping the switch by hand, and very few people who decline ever do that.

So every "Don't Allow" was a permanent opt-out from a core part of the product, which made the decline rate the most expensive metric in the whole onboarding.

Let me show you what we did instead, the screen we put in front of the prompt, the hook that guards the request, and what we're still measuring.

What the iOS docs don't tell you

The native prompt is a one-shot, that part is documented. What isn't documented as prominently is when it becomes a one-shot. It's not the first time you call requestPermissionsAsync(), it's the first time the user sees it. Once they've seen the prompt and declined, you can't show it again from your app code.

You can detect the state with getPermissionsAsync():

import * as Notifications from "expo-notifications";

const { status } = await Notifications.getPermissionsAsync();
// "granted" | "denied" | "undetermined"

"undetermined" is the only state where calling requestPermissionsAsync() will actually show the system prompt. "denied" means the user already saw it and said no, and your only recovery is the Settings deep link. "granted" means you're clear to send notifications.

The whole pattern in this post is built on one rule: never call request while the status is undetermined unless you're confident the user will say yes.

Timing: a lesson from game design

Mobile games solved this years ago. A well-designed game never asks for notification permission on first launch, it waits until you've finished the first level, earned your first reward, or started a building that takes an hour to complete. At that moment the notification has an obvious job, "we'll tell you when it's done", and the player has already felt the value, so the ask answers a question they actually have.

The worst time to ask is before the user has experienced anything, at that point the permission prompt is a cost with no visible benefit and "Don't Allow" is the rational answer. The best time is right after a moment of value, when the notification is clearly in service of something the user just chose.

That's why our screen sits where it does in the onboarding. The user has already entered their name, picked their goals and invested a few minutes in the flow, so the notification ask is framed as the thing that makes those goals happen. Same principle as the game asking after the first level, earn the moment first, then ask.

The screen we show before the prompt

The screen we shipped is one step in the onboarding flow, right after the user has entered their name, picked their goals and invested a few minutes in the flow. It's deliberately simple, a title, a short description and two buttons:

<NotificationExplainerScreen
  title="Stay on track"
  description="We'll send you gentle reminders for your daily habits, lab result updates the moment they're ready, and progress milestones worth celebrating. One nudge at the right time, never spam. You're in control, turn off or customize every notification type anytime in Settings."
  primaryAction={{
    label: "Turn on notifications",
    onPress: requestNotificationPermission,
  }}
  secondaryAction={{ label: "Skip for now", onPress: advanceOnboarding }}
/>

Every line of that copy is doing a job, and most of the jobs come straight from game design.

"Gentle reminders for your daily habits" names the concrete thing the user just set up, the goals from two screens ago, so the notification is in service of something they chose. "Progress milestones worth celebrating" is the reward loop, games learned a long time ago that people say yes to notifications about wins, a level completed, a streak kept, much more readily than to notifications about obligations. "Lab result updates the moment they're ready" gives the notification an obvious job, the same way a game asks for permission when your building has an hour left, we'll tell you when it's done.

And "you're in control, turn off or customize anytime in Settings" lowers the perceived cost of saying yes. Good games always let you toggle notification types individually, and telling the user up front that they keep that control makes "Turn on notifications" feel reversible instead of a commitment.

Then there's "Skip for now", and this one needs explaining because it looks like a mistake. It isn't. Skipping our screen costs nothing, the permission status stays undetermined, so we can ask again later at a better moment, after the user's first completed habit or their first lab result. Declining the OS prompt costs everything, it burns the one-shot permanently. So the skip button is there on purpose, we'd much rather collect a cheap "not now" on our own screen than push an unsure user into an expensive, irreversible "Don't Allow" on Apple's.

The hook

The screen calls a single hook on continue:

// hooks/useNotificationSetup.ts — abridged
import * as Notifications from "expo-notifications";

export function useNotificationSetup() {
  const requestNotificationPermission = useCallback(async () => {
    const current = await Notifications.getPermissionsAsync();

    if (current.status === "granted") {
      // Already on. Skip the prompt; advance the onboarding.
      return "granted";
    }

    if (current.status === "denied") {
      // Already declined. Show the "open Settings" sheet instead of the prompt.
      showSettingsSheet();
      return "denied";
    }

    // status === "undetermined" — the one case where the prompt will actually fire.
    const result = await Notifications.requestPermissionsAsync({
      ios: {
        allowAlert: true,
        allowBadge: true,
        allowSound: true,
        allowAnnouncements: false,
      },
    });

    if (result.status === "granted") {
      await registerForPushToken();
    }

    return result.status;
  }, []);

  return { requestNotificationPermission };
}

Three guards in three lines. "Granted" skips the prompt entirely, "denied" opens the Settings deep-link sheet so the user can recover, and "undetermined" is the only path that calls the OS request.

Asking for the four iOS flags explicitly is worth doing. We didn't enable allowAnnouncements, that's the Siri "read this aloud through AirPods" permission and the product doesn't need it. Asking for permissions you don't need just nudges the user toward decline.

The Settings sheet, for the users who already said no

We show a separate small sheet for users whose status is already "denied":

<BottomSheet
  title="Notifications are off"
  body="You said no the first time, which is fine. The only way to turn them on now is in your phone's Settings."
  primaryAction={{
    label: "Open Settings",
    onPress: () => Linking.openSettings(),
  }}
  secondaryAction={{ label: "Maybe later", onPress: dismiss }}
/>

The copy matters here. "You said no the first time, which is fine" respects the user's earlier choice, and "the only way to turn them on now is in your phone's Settings" is the honest mechanic, not a sales pitch. The share of declined users who open Settings from this sheet is meaningfully higher than the share who responded to the previous "Notifications are off, enable them" banner inside the app shell.

The measurement

We're tracking three numbers, weekly.

Our screen's tap rate. What share of users who land on our screen tap "Turn on notifications".

Permission grant rate after the CTA. Of the users who tap our CTA, how many then tap "Allow" on the system prompt that follows.

Net grant rate. Our screen's tap rate times the system-prompt grant rate. The lift over the bare system-prompt baseline is the metric the product team watches, and on this product it's meaningful, meaningful enough that showing our own screen first is now the model for every new permission ask, not just notifications.

What I would tell another engineer setting this up

Never call requestPermissionsAsync without checking the status first. The one-shot rule on iOS is unforgiving, the three-branch guard is one of those patterns where the lines you don't call matter more than the ones you do.
Write the screen copy around concrete, positive jobs. Habit reminders the user just set up, lab results the moment they're ready, milestones worth celebrating. Specific and rewarding beats "stay engaged with the app", the same reason game notifications lead with wins, not obligations.
Let users skip your screen, never let them skip into the OS prompt. A "Skip for now" on your own screen is cheap, the status stays undetermined and you can ask again at a better moment. A "Don't Allow" on the system prompt is permanent. Design the screen so the unsure user takes the cheap no.
Settings deep link for the declined cohort. Most users who declined the first time won't come back, some will, so make the recovery a one-tap path.
Ask for the iOS flags you actually need. allowAnnouncements isn't free, every permission you ask for raises the bar to "yes".

Amar Spahic · Remote Since Forever