When to ask for permissions during mobile onboarding

Connect the request to an intentional action

A permission request is easier to understand when it follows a feature the person chose. A reminder setup can explain notifications; taking a profile photo can explain camera access. A stack of unrelated dialogs at first launch gives little context for those decisions.

List the protected capabilities your first session truly needs. Defer requests for features that are not being used. Consult the current platform guidance for the specific resource; notification, tracking, camera and location requests have different rules and APIs. There is no single universal permission flow.

Explain before requesting, without imitating the system

An in-app explanation should identify the user benefit and the access required. It should not pretend that its button already grants system permission or imply that refusal is impossible. Keep the real system dialog and the custom explanation clearly distinct.

Use accurate purpose strings and localized copy. Avoid screenshots that present a fake system authorization as an interactive control. Follow Apple’s current guidance for custom views before permission alerts, including the requirements that apply to the particular protected resource.

• State the feature that requires access.
• Ask through the platform API at the appropriate moment.
• Handle authorized, denied and not-yet-determined states.
• Keep an accessible route that explains unavailable optional features.

Treat refusal as a supported path

A denied optional permission should not strand the onboarding flow. If reminders are unavailable, finish setup without reminders and show how the feature can be configured later. Avoid repeatedly asking as though the earlier choice did not happen.

Some resources cannot be requested again through the same dialog after refusal. Explain settings navigation only when relevant, and re-check the actual authorization state when the app returns. Do not use a locally saved “yes” flag as a replacement for platform state.

Measure more than the acceptance percentage

Permission acceptance is a diagnostic measure, not the entire product goal. Moving a request later can change who reaches it, so the acceptance percentage among prompted people may rise even when fewer total installations enable the feature.

Report prompt exposure and the outcome against a clear cohort. Distinguish the system authorization result from an in-app button tap. Evaluate useful feature adoption and onboarding completion alongside the request outcome, while respecting the data collection permissions and consent that apply to your app.

Test the states that screenshots cannot prove

Verify the flow on a fresh install, after refusal, after authorization and after changing access in Settings. Include restart, background/foreground transitions, large text and each shipped language. A design preview cannot establish that system permissions work.

Aplyna layouts can help author supported screens, but native platform permission handling belongs in the app integration. Keep permission actions and telemetry accurate; a screen named “Notifications enabled” must not appear solely because a person tapped an explanatory Continue button.