Permission Request Flow Template

No. Requesting permissions during onboarding, before the user understands the product, results in the lowest opt-in rates. Each permission should be requested at the moment of relevance: location when the user taps "Find nearby," camera when they tap "Scan," notifications after they complete their first value-generating action. The only exception is a permission that is truly required to use the app at all (e.g., microphone for a voice recording app). Even then, a pre-permission screen explaining why is essential. For more on activation flow design, see the [PLG Handbook](/plg-guide).

Industry benchmarks vary by permission type. Notifications: 50-60% on iOS with pre-permission screens (vs. 35-40% without). Location: 60-75% when asked at the moment of need. Camera: 70-80% when triggered by user action. Contacts: 30-50% (the lowest because users are protective of contact data). These benchmarks assume pre-permission screens and contextual timing. If your rates are below these ranges, the issue is almost always timing or copy, not user resistance.

You cannot re-trigger the system prompt after a denial on iOS (Android allows re-prompting in some cases). Your options are: a periodic in-app prompt that explains the benefit and deep-links to the OS Settings page, or a redesigned fallback experience that delivers most of the value without the permission. Track re-ask conversion rates. If fewer than 2% of users re-enable through settings, invest more in the fallback experience instead.

Mild loss aversion ("You'll miss delivery updates if notifications are off") is acceptable when it is factually true and the user benefits from the feature. Aggressive loss aversion ("Your orders may be lost") or fake urgency is not. The ethical test: would a reasonable user feel informed and empowered by your copy, or pressured? If you are uncertain, default to positive framing ("Get real-time updates") over negative framing ("Miss important updates"). ---