Notification permission timing: when to ask, not what to say

Notification permission is one of the highest-leverage moments in a mobile game's first session. The player either grants the permission and remains reachable for the entire relationship, or denies it and disappears from the studio's outbound channel forever. Once a player denies the system permission, the only way back is for them to navigate manually into device settings — a path almost no player takes.

Most studios still treat this moment as an onboarding step. The permission ask happens in the first few minutes, often before the player has done anything meaningful in the game. The reasoning is straightforward: ask early so you have the channel later. The reality is that asking early is the single biggest reason permission rates are as low as they are. iOS sits around 50 percent industry-wide; Android has tightened further with each platform release since 2023.

The studios with materially higher permission rates aren't asking better. They're asking later, at moments the player is in a state to say yes.

Why early asks fail

A player in the first few minutes of a new game is in a specific cognitive state. They installed the game out of mild curiosity or external prompt. They don't yet know whether the game is worth their time. They have no investment in the relationship, no completed actions, no sense that the game produces anything they'd want to be notified about.

Asking for permission in that state is asking them to make a commitment ("I want this game in my notification feed") at a moment when they have no basis for the commitment. The default rational response is no — they have nothing to lose by declining and everything to gain by avoiding another notification source. The permission rate at this moment is structurally low regardless of how good the ask wording is.

The studios trying harder on the ask copy — "Stay in the loop!" or "Get exclusive rewards!" — are optimising a variable that isn't the constraint. The constraint is the player's state, not their wording preference. No copy is going to convince a player to grant notification permission to an app they downloaded thirty seconds ago.

What raises the rate is delaying the ask until the player has reason to want the channel.

When to ask

A few specific moments produce dramatically better permission grant rates than the onboarding moment.

After the first meaningful achievement. A player who has just completed something — beaten a level, unlocked their first character, finished the tutorial — is in a state of momentary satisfaction. They've invested. They have a reason to want more. Asking for permission at that moment, framed as "Want us to let you know when [next thing they care about] is available?" catches them in receptive state.

After the first save or progress checkpoint. A player who has built something — even a small something — has investment they want to protect. The notification ask framed around "We'll let you know when your [structure / character / progress] needs attention" maps to the investment they just made.

At the first time-bound event the player encounters. If the game has limited-time content, asking for permission specifically to notify about future events works because the value of the channel is concrete and specific.

Before the player would otherwise miss something valuable. A player about to close the app after a session, who would benefit from knowing when their energy refills, who would want to come back for tomorrow's event — asking at that moment is asking when the value is most visible.

What none of these moments share with the onboarding moment is that they're asking with context. The player can answer the implicit question "what would I be notified about?" with a specific answer that relates to something they care about. The grant rate at these moments is several times what the onboarding moment produces.

The technical pattern for delayed asks

Implementing this requires deferring the OS permission prompt until the chosen moment. The simplest pattern:

The app does not call the notification permission API during onboarding. The permission state stays "not determined" — neither granted nor denied.

The app tracks a small set of trigger events: tutorial complete, first level clear, first achievement, first save action, first session that exceeds X minutes, whatever the game considers a meaningful milestone.

When a trigger event fires AND the permission state is still "not determined," the app shows a soft prompt — an in-game message explaining what the player would be notified about — followed by the OS permission prompt if they agree.

The soft prompt is important. The OS permission prompt is generic and gives the player no context. The soft prompt — "Want us to let you know when [specific thing] is ready?" — is the studio's chance to set the framing before the OS prompt appears. A player who taps "Yes" on the soft prompt is much more likely to tap "Allow" on the OS prompt that follows.

If the player declines the soft prompt, the OS prompt doesn't fire. The permission state stays "not determined," and another opportunity can be tried later. The crucial property: don't fire the OS prompt unless you have reasonable confidence the player will accept. A "Don't Allow" on the OS prompt is final on iOS until the player manually navigates to Settings.

What this costs and what it saves

The cost of the delayed-ask pattern is that some players never reach the trigger moments. A player who installs, plays for ten seconds, and uninstalls never sees the ask. The studio loses the opportunity to add them to the notification list.

The reasoning behind delaying anyway: that player wasn't going to grant permission in onboarding either. The onboarding ask would have produced a "Don't Allow" from this same player, which is worse than no ask — because a "Don't Allow" closes the door permanently, while "not determined" keeps it open if the player ever does engage more deeply.

The savings are substantial in the segment that matters. Players who do engage past the trigger moments grant permission at rates several times higher than they would have at onboarding. The notification channel ends up with a smaller but much higher-quality population. Open rates on subsequent notifications are higher because the population self-selected into the channel based on existing engagement.

The end state: fewer total notification subscribers, much better engagement per subscriber, no permanent denials from players who weren't going to be reached anyway.

What about Android's stricter posture

Android's notification permission model tightened with Android 13 (runtime opt-in required) and has continued to tighten through subsequent versions. The platform now expects apps to request permission explicitly rather than receiving it by install default.

This change actually helps the delayed-ask pattern. On older Android, notifications worked by default and the design tension was around whether to be polite about using them. On current Android, the ask is required, and the question of when to ask is the question that matters.

Studios still designing as if Android grants by default are losing notification reach without realizing it. The fix is the same as for iOS: defer the ask to a meaningful moment, use a soft prompt with context, fire the OS prompt only when likely to be accepted.

The Settings-recovery problem

The hardest part of the notification permission lifecycle is what happens after a denial. Once a player has tapped "Don't Allow," the only path to recovery is the player navigating to their device's notification settings for the app and toggling it on manually.

Almost no players do this. The studios trying to recover denied permissions through in-game prompts ("Open Settings to enable notifications!") see very low success rates. The recovery cost is much higher than the prevention cost, which is the main reason delaying the original ask matters so much.

The few cases where Settings recovery works tend to be highly motivated players — competitive players who want event notifications, social players who want guild notifications. For the broad player base, the assumption should be that denied is permanent.

See how we approach lifecycle measurement →

Notification permission is one of the few onboarding-era decisions whose consequences last the entire lifetime of the player relationship. Studios who ask early lock in low permission rates and high permanent-denial counts. Studios who ask at the right moments compound an outbound channel that keeps producing engagement for as long as the player is around. The pattern isn't complicated. It just requires holding back from asking at the moment the player is least likely to say yes.

Talk to us about engagement lifecycle measurement →