iOS & Android App Permissions Reference
Search and browse every iOS and Android permission in one place. Find the exact Info.plist key, Android manifest permission, protection level, usage description string, and best-practice timing for requesting each permission. Filter by platform and category to quickly find what you need for your mobile app.
How iOS & Android App Permissions Reference Works
Complete searchable reference for iOS and Android app permissions. Find permission names, descriptions, usage strings, and code snippets. tool. Use the tool above to get your results instantly — everything runs in your browser with no data sent to any server.
Understanding Mobile App Permissions
Mobile app permissions are the gatekeepers between your application and a user's private data and device capabilities. Both iOS and Android require developers to explicitly declare which permissions their app needs, and users must grant those permissions before the app can access protected resources. Getting permissions right is critical for app approval, user trust, and privacy compliance.
iOS Permissions: Info.plist Keys
On iOS, every permission request requires a corresponding usage description key in your app's Info.plist file. Apple mandates that each key include a human-readable string explaining why the app needs access. If the usage description is missing or vague, Apple will reject the app during App Store review. Common keys include NSCameraUsageDescription for camera access, NSLocationWhenInUseUsageDescription for location while the app is in the foreground, and NSPhotoLibraryUsageDescription for reading photos. Starting with iOS 14 and later, Apple introduced more granular controls such as approximate location and limited photo library access, giving users finer control over what they share.
Android Permissions: Manifest Declarations and Runtime Requests
Android divides permissions into normal permissions (granted automatically at install) and dangerous permissions (requiring explicit user approval at runtime). Since Android 6.0 (API 23), dangerous permissions must be requested at runtime using the ActivityCompat.requestPermissions API. Android 13 introduced granular media permissions (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO) replacing the older READ_EXTERNAL_STORAGE permission. Developers must declare all required permissions in the AndroidManifest.xml file and handle both the grant and denial cases gracefully in their code.
Best Practices for Requesting Permissions
Request permissions only when the user performs an action that requires them, not at app launch. Provide clear context explaining why the permission is needed before showing the system dialog. If a user denies a permission, degrade gracefully and offer alternative functionality where possible. Never request permissions your app does not actively use, as both Apple and Google audit permission usage during review. On iOS, a rejected permission prompt cannot be shown again; users must enable it manually in Settings. On Android, after two denials the system adds a "Don't ask again" option, so timing and context are essential.
Privacy and Compliance Considerations
Both platforms are moving toward stricter privacy controls. Apple's App Tracking Transparency framework requires explicit consent for cross-app tracking. Google's Privacy Sandbox initiative is reshaping how Android apps access advertising identifiers. For apps targeting the European Union, GDPR requires that permission requests align with lawful bases for data processing. Always document which permissions your app uses and why in your privacy policy, and ensure your permission usage aligns with the functionality described in your app store listing.
Frequently Asked Questions
What is the difference between normal and dangerous permissions on Android?
Normal permissions (like INTERNET or VIBRATE) are granted automatically at install time because they pose minimal risk to user privacy. Dangerous permissions (like CAMERA, LOCATION, or CONTACTS) can access sensitive user data and must be explicitly approved by the user at runtime. Dangerous permissions are grouped into permission groups, and granting one permission in a group may automatically grant others in the same group.
Why does Apple require usage description strings in Info.plist?
Apple requires a human-readable usage description for every permission so users understand exactly why an app needs access to their data or hardware. If you request camera access, for example, you must include NSCameraUsageDescription with a string like "This app uses the camera to scan QR codes." Apps submitted without these strings are rejected during App Store review.
Can I request all permissions at app launch?
Technically yes, but it is strongly discouraged by both Apple and Google. Requesting all permissions upfront overwhelms users and leads to higher denial rates. Best practice is to request each permission in context, right when the user performs an action that requires it. This approach results in significantly higher grant rates and better user trust.
What happens if a user denies a permission on iOS?
On iOS, once a user denies a permission, the system dialog will not appear again for that permission. The user must manually navigate to Settings > Privacy to re-enable it. Your app should detect the denied state and show a helpful message directing users to Settings if they want to enable the permission later.
How do Android 13 media permissions differ from older versions?
Android 13 (API 33) replaced the broad READ_EXTERNAL_STORAGE permission with three granular permissions: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, and READ_MEDIA_AUDIO. This gives users finer control over which types of media an app can access. Apps targeting Android 13 must request these specific permissions instead of the legacy storage permission.