Request the permission when the feature is used, not at launch

What it is

A just-in-time (ask-on-use) permission request places the system dialog at the moment someone has already chosen to use a capability: tap Capture, route to a destination, unmute to speak. Stacking location, notifications, and photos on the launch screen, the welcome carousel, or the empty post-login view is not just-in-time. This entry is only about where the ask sits in the task flow. It is not about writing a purpose string before the dialog, degrading after a denial, or making the grant revocable later.

Why it happens

People judge a capability against the current task, not against an app's capability list. At launch there is no task, so the permission name is an abstract power ("Location", "Camera"). Refusal costs almost nothing; allowing looks like signing a blank cheque. Mid-task, the same "Allow camera access" is anchored to "I am photographing this receipt." Appropriateness comes from context, not from brand trust. Asking too early also spends first-open attention: before the product is understood, the person is asked for a hard-to-reverse privacy decision, and the default strategy becomes deny-all or allow-all—neither is informed choice.

Studying it

Compare "list every permission at install or first launch" with "show the system dialog only when the matching feature starts." Measure authorization and later understanding, not grant rate alone.

Independent variables: delay from first launch, whether the ask sits next to an observable feature action, how many permissions appear together. Dependent variables: allow/deny, ability to restate which feature the permission supports, first-session completion, later surprise ("it was using this the whole time").

Lab participants know they are in a permission study and read the dialog unusually carefully; in real install funnels, a launch-time dialog is often dismissed as an obstacle. Low grant rates at launch are not automatically evidence of weak copy—timing itself changes the reference frame used to judge necessity.

Where it stops holding

Some capabilities still have to be granted before a background start (enterprise device management that launches at boot, headless accessory pairing); just-in-time has nowhere to attach. A camera-only or recorder-only tool is its first screen, so launch and use coincide. On child or managed devices the grant is pre-set by a parent or administrator; the person at the handset is not making this decision.

Applying it

• Bind each permission to a tappable feature entry; do not fire the system dialog until that entry is activated.
• Strip permission asks from launch, registration, and empty states; if a demo needs a capability, fill the first screen with sample content that needs none.
• Request only the capability the current action needs; wait for the next action before the next ask.
• Verify by recording first sessions and tagging the user action immediately before each system permission dialog. If that action is not "use this capability," timing failed. Then compare grant rate and task completion for launch-time versus in-feature asks in the same traffic window.

Related

• Within the group: H4.01.2 A first denial costs more than waiting to ask · H4.01.3 Stacked permission requests lower overall grant rates
• Adjacent: H4.02 Purpose Explanation · O2.01 Permission-Prompt Information Design · O1.08 Contextual Integrity · H2.01 First-use Guidance
• Search terms: just-in-time permission · ask on use · contextual permission