15 Mobile App Permissions and When an App Should Request Them
When to ask for notifications, location, camera, photos, contacts, tracking and other iOS and Android permissions, and how to handle a user saying no.
When should an app request each permission?
Request a permission at the moment the user starts a feature that needs it, explain why in your own words first, ask for the least access that works (approximate rather than precise location, a photo picker rather than the whole library), and keep the app usable if the answer is no. Some permissions need extra care: background location, tracking, health data and SMS or call logs are tightly controlled by Apple and Google.
This list is for founders, designers and developers planning an app. Platform rules were checked against Android Developers and Apple's App Review Guidelines on 28 October 2026. Exact behaviour varies by OS version, so test on the versions your users run.
Principles that apply to every permission
- Ask in context. Android says to ask "when the user starts to interact with the feature that requires it".
- Explain first, briefly. The system dialog does not say why. Show a short explanation with a "Not now" option before the prompt.
- Write clear purpose strings. On iOS, Apple requires purpose strings that "clearly and completely describe" how the data is used.
- Ask for the minimum. Apple's data minimisation guideline says to use pickers or share sheets instead of full access where possible.
- Respect a no. On Android, two denials are permanent. Android advises against nagging or pushing users to settings to change their mind.
- Offer alternatives. Apple's example: if a user declines location, let them enter an address manually.
Communication permissions
1. Notifications. On Android 13 and later, and on iOS, apps must ask before sending notifications. Ask after the user has done something that makes notifications useful, such as placing an order they will want updates on. Apple's guidelines say apps may not require notifications to be enabled to use the app. See push notifications in mobile apps.
2. Contacts. Ask only for a feature that clearly needs them, such as inviting friends, and consider a contact picker or share sheet instead of full access. Never upload a user's whole address book without a clear, specific reason they agreed to.
3. SMS and call logs (Android). Google Play restricts these permissions to apps whose core function needs them, such as default SMS or dialler apps, and requires a declaration. Most apps should use one-time-code autofill or other APIs instead.
Location permissions
4. Approximate location. Enough for local weather, nearby stores or regional content. Both platforms let users share approximate rather than precise location; design features to work with it.
5. Precise location. Needed for navigation, deliveries or finding a specific place. Ask when the user starts that task, and explain why approximate is not enough.
6. Background location. Location while the app is not in use, for example for a delivery driver's trip or geofenced reminders. It is requested separately from foreground access, attracts extra review on Google Play and should be avoided unless the core feature needs it. On Android 11 and later, users also see an "Only this time" option for foreground location, camera and microphone.
Camera, microphone and media
7. Camera. Ask when the user taps "Scan" or "Take photo". If camera access is denied, offer an upload or manual entry where possible.
8. Microphone. Ask when the user starts a voice note, call or voice search. Apple's guidelines give the example that an app for posting photos must not require microphone access to do so.
9. Photos and media. Prefer the system photo picker, which on Android grants access only to the items the user selects, and on iOS avoids full library access. Request full library access only for apps such as gallery or backup tools.
10. Files and documents. Use the system document picker to open specific files rather than requesting broad storage access.
Devices, health and identity
11. Bluetooth and nearby devices. Needed to connect to wearables, printers or hardware. Ask when the user starts pairing, and explain which device and why.
12. Health and fitness data. Access through Apple HealthKit and Android Health Connect is granted per data type and comes with strict rules on how the data may be used. Ask only for the types the feature uses. See mobile app data privacy.
13. Biometrics (Face ID and fingerprint). Used to unlock the app or approve actions. iOS needs a purpose string for Face ID. Always offer a passcode or password fallback.
14. Local network (iOS). Apps that find devices on the local network, such as smart-home or casting apps, trigger a local network prompt. Ask when the user starts device discovery.
Tracking
15. App Tracking Transparency (iOS). Apple requires explicit permission through the App Tracking Transparency framework before tracking users across other companies' apps and websites, for example for targeted advertising. Apps may not require tracking permission to use the app or offer rewards for granting it. If you do not track, do not show the prompt.
Planning permissions for a new app?
ZSpace Labs designs and builds iOS and Android apps with permission flows, privacy disclosures and fallbacks planned from the start. See our mobile app development service.
Permission timing table
| Permission | Ask when | If declined |
|---|---|---|
| Notifications | After an action that makes updates useful | Show updates in-app; email if agreed |
| Contacts | User chooses to invite or find people | Share link or manual entry |
| SMS / call logs | Only for core SMS or dialler apps | One-time-code autofill |
| Approximate location | User opens a location-based feature | Manual city or postcode |
| Precise location | User starts navigation or delivery tracking | Approximate location or address |
| Background location | Only for features that need it while closed | Foreground-only mode |
| Camera | User taps scan or take photo | Upload or manual entry |
| Microphone | User starts voice feature | Text input |
| Photos | Use the picker instead | Picker needs no broad permission |
| Files | Use the document picker | Not applicable |
| Bluetooth | User starts pairing | Explain feature unavailable |
| Health data | User enables a health feature | Manual logging |
| Biometrics | User turns on biometric unlock | Passcode or password |
| Local network (iOS) | User starts device discovery | Manual device setup |
| Tracking (iOS) | Only if you track across apps | Non-personalised experience |
Conclusion
Good permission design is mostly about timing and restraint: ask when the user can see why, ask for the least you need, and make sure the app still works if they say no. Both stores enforce these principles, and users reward them. Permission prompts are part of the first-run experience, so plan them with your onboarding and with the features your first release needs.
Sources
Android Developers: request runtime permissions; one-time permissions; notification runtime permission (Android 13); photo picker. Apple App Review Guidelines 5.1.1 (data collection and storage) and 5.1.2 (data use and sharing). Google Play policy on SMS and call log permissions and background location. Accessed 28 October 2026.
Common questions.
When the user starts to use the feature that needs it. Android's documentation says to ask in context, and Apple's guidelines say to request only data relevant to the app's core functionality. Asking for everything on first launch invites refusals that are hard to reverse.