After a denial, whether the app may prompt again is platform-specific

What it is

After someone taps Don't Allow, whether the app may show the system permission dialog again is an OS rule, not a retention policy the product chooses. Some systems allow another system prompt until "Don't ask again" is checked. Others never show that dialog for the app again after a denial; the person has to flip the switch in Settings. Copying "ask once more" from one end to the other either nags someone who already said no, or wires a button that summons no system dialog at all. This entry is the re-request rule after denial. It is not whether the first ask happens at install or at use, and not which capabilities a same-named permission covers.

Why it happens

The OS keeps a per-app, per-permission state machine: not determined, allowed, denied, denied-and-don't-ask, restricted by a parent or a profile. A later request API call is dispatched against that state: show the system dialog, return denied silently, or no-op. On platforms such as iOS, a later request after denial is a no-op; if the app still calls it, the person sees a button that does nothing. On platforms such as Android, a limited number of further system dialogs are allowed until Don't ask again, after which Settings is the only path. OEM layers add their own intercepts. An in-app "try again" that only re-calls the same API is a dead control on a no-op platform. The real next step is the Settings page for that permission—and the depth and names of that page also differ by OS. Repeated calls on a platform that still allows prompts train habitual denial, unread, the next time the capability is actually needed.

Studying it

Treat the second and third asks after denial as conditions, not only the first dialog.

Independent variables: platform re-request rule, delay after denial (immediate / next task / next day), whether the second beat is a system dialog or a "go to Settings" guide. Dependent variables: whether a system dialog actually appears the second time, how many people reverse, how many treat later prompts as harassment, success rate of reaching the Settings row.

A lab instruction to "deny, then allow" overestimates reversal. In the field, split reasons: mis-tap, not using the feature right now, never. A mis-tap can be caught by a second dialog on a platform that still allows it; a permanent no, re-prompted, worsens ratings. Clicks on "Open Settings" are not grants—many people tap and get lost in the Settings hierarchy.

Where it stops holding

Restricted (parental controls, enterprise profiles) is not denied: neither a re-prompt nor Settings will open it. The UI should name a device policy, not offer another post-denial button. After the person turns the switch on in Settings, the next API call sees the new state; the app must not show another system dialog "to confirm." Notification permission has its own re-request quotas on some systems; camera rules do not copy over. A desktop browser can reset a site in site settings; a mobile app has no equivalent "reset this site," only system Settings.

Applying it

• After a denial, read the platform status first. Prompt the system dialog only if the platform still allows it. If the state is permanent denial or a no-op, switch to a one-step path into that permission's Settings row, naming which item to enable.
• Do not fake a system permission dialog with a custom alert to dodge "cannot prompt again." People will think they are answering the OS.
• Verify by denying the same capability on two systems, then immediately tapping Retry in the product. One end should show a system dialog or a clear Don't-ask-again path; the other should show a guide that reaches the correct Settings row and no system dialog. If both ends share one button logic, the re-request rule was not split by platform.

Related

• Within the group: K1.12.1 Permissions may be granted at install or asked at the moment of use · K1.12.2 A permission with the same name does not grant the same capabilities on every OS · K1.12.4 A cross-platform app cannot treat one permission model as universal
• Adjacent: O2.01 Information design of permission prompts · O1.10 Granularity and withdrawal of consent
• Search terms: permission denial · Don't Ask Again · open settings