Permissions requested at point-of-use, not on app launch
Why it matters
Requesting all permissions on app launch is one of the most reliable ways to tank user retention. Apple's Human Interface Guidelines and GDPR Art. 5(1)(c) both require that data access be tied to a specific user action and purpose — not collected speculatively. When a user sees a camera permission request before they have navigated anywhere near a camera feature, they have no frame of reference for why the app needs it, so they deny. On Android, Google Play reviews flag apps that request permissions at launch without clear justification, and repeated violations result in policy strikes. Any permission requested in a root-level useEffect(() => {}, []) is a request that was never triggered by user intent.
Severity rationale
High because launch-time permission requests eliminate the user's ability to understand the purpose of the request, directly reducing grant rates and creating GDPR Art. 5(1)(c) data-minimisation violations.
Remediation
Move every permission request inside the component or handler for the feature that needs it. Remove all permission calls from root-level useEffect hooks and app bootstrap sequences.
// Remove this pattern from app entry points:
// useEffect(() => { requestCameraPermission() }, [])
// Add this pattern inside the feature component:
function VideoCallScreen() {
const handleStartCall = async () => {
const result = await request(
Platform.OS === 'ios' ? PERMISSIONS.IOS.CAMERA : PERMISSIONS.ANDROID.CAMERA
)
if (result === RESULTS.GRANTED) {
startCall()
}
}
return <Button onPress={handleStartCall} title="Start Video Call" />
}
For onboarding flows: only request a permission when the user explicitly enables the feature that requires it, not as a bulk step at the end of account setup.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Mobile Permissions & Privacy Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- gdpr · Art. 5(1)(c) — Data minimisation
- external · apple-permission-usage-descriptions — Apple: Requesting Access to Protected Resources
Taxons
History
- 2026-04-18·v1.0.0·Initial import from mobile-permissions-privacy·automated