Permission‑Request Playbook: 10 Acceptance‑Tested Permission Flows (Onboard, Re‑ask & Decline‑Recovery) with Exact Copy & Metrics

Ship permissions as feature scaffolding, not as a gate. Ask only when the user triggers the capability, show a short contextual pre‑prompt that explains the benefit, then present the OS dialog. If users decline, show a decline‑recovery screen that offers an alternative or an easy path back to settings.

Measure success with a small KPI set: pre‑prompt click‑through rate (CTR), OS prompt accept rate (system grant rate), re‑ask accept rate, and downstream retention lift (D7/D30 for feature users vs non‑permission users). Use event names like permission_pre_prompt_shown, permission_pre_prompt_clicked, permission_os_prompt_shown, permission_granted, permission_rejected, and permission_reask_shown. That event taxonomy keeps A/B tests and attribution clean.

Below are compact, production-ready flows. For each: (1) Trigger moment, (2) pre‑prompt copy (single screen/dialog), (3) OS prompt trigger, (4) immediate follow‑up on Deny (decline‑recovery UI), (5) re‑ask timing rule. Replace [AppName] with your app name and localize.

1) Location — Turn‑by‑turn / Map features: Trigger: user opens map or taps “Find nearby”. Pre‑prompt title: “Show your location to find nearby [items]” Body: “We’ll use your device location only while you use this feature to show nearby [stores/orders].” Primary button: “Allow while using [AppName]” Secondary: “Not now” Follow‑up if Denied: “Location is off — you can enter an address manually or enable location in Settings.” Buttons: “Enter address” / “Open Settings” Re‑ask rule: Re‑ask only when the user again taps a location action that would immediately show value (do not re‑ask automatically).

2) Camera — Capture or scan: Trigger: user taps camera capture. Pre‑prompt title: “Take photos to [save/scan/send]” Body: “Allow camera so you can capture [receipts/profile photos]. We won’t use it without you taking the picture.” Primary: “Use Camera” Secondary: “Upload instead” Follow‑up if Denied: “Camera access denied. Use photo upload or allow camera in Settings.” Buttons: “Upload photo” / “Open Settings” Re‑ask rule: One immediate in‑flow re‑ask after a short in‑app rationale; if denied again, wait 7+ days or the next clear need.

3) Notifications — Order updates, messages: Trigger: after the user completes an action that will generate ongoing updates. Pre‑prompt title: “Get real‑time updates” Body: “Enable notifications to receive order updates and important messages.” Primary: “Yes, keep me updated” Secondary: “Not now” Follow‑up if Denied: “Notifications are off. We’ll show updates inside the app; enable alerts in Settings to get them while away.” Buttons: “Show in‑app” / “Open Settings” Re‑ask rule: Re‑ask after a meaningful event related to the notification type (e.g., next order or next message) — not sooner than 3–14 days depending on frequency of meaningful events.

Decline is not a dead end. The right recovery screen reduces friction, explains concrete loss, and gives three clear actions: a low‑friction fallback, a Try Again path (that re‑explains benefit), and an Open Settings button. Keep copy short, show one small visual (e.g., map pin, camera icon, bell), and use a neutral tone.

Exact recovery microcopy (universal template): Title: “Permission needed for [feature name]” Body: “Without [permission], [feature] can’t [what it does]. You can continue using [alternative], or enable [permission] in Settings.” Buttons: “Use [alternative]” / “Try again” / “Open Settings” Behavior rules: If the user taps Try again and the OS will not show the prompt (iOS: .denied state), show instructions and an Open Settings path instead of repeatedly triggering the OS dialog. On Android, use shouldShowRequestPermissionRationale to decide whether to re‑explain or directly request.

Good re‑ask strategy is conservative and signal‑driven. Re‑ask only when (a) the user performs an explicit action that reveals motivation, (b) there’s a fresh value moment, or (c) enough time has passed so the user’s context changed. Avoid time-based spam; prefer event‑based triggers tied to user intent.

A/B test ideas: pre‑prompt copy variants (benefit‑first vs. technical reason), single vs. two‑step re‑asks, and immediate in‑flow re‑ask vs. deferred re‑ask after a feature completion. Track pre‑prompt CTR and OS accept rate as primary A/B outcomes. If you run experiments, segment by platform and user acquisition source—iOS and Android baseline behaviors differ enough to require separate experiments.