App permissions are the access controls a mobile operating system enforces to decide whether an installed app may use sensitive data, hardware or system features, such as the camera, microphone, location, contacts, photos, notifications or nearby devices. In mobile fundamentals, they are the main mechanism through which the user, rather than the app developer, controls what an app can see and do on a smartphone.
Permissions sit on top of app sandboxing: every app runs in an isolated environment and can reach protected resources only through system interfaces that check whether access has been granted. Modern Android and iOS versions ask for most sensitive permissions at runtime, in context, and let users change or revoke them later in the system settings.
How app permissions work
An app permission works as a declared capability plus a user or system grant. The developer declares in the app’s manifest or configuration which protected resources it may need, and the operating system checks the current grant every time the app calls a protected interface.
- The developer declares the permission in the app package, for example in the Android manifest or the iOS Info.plist with a usage description.
- When the app first needs the resource, it requests access at runtime, ideally right after a user action that explains the need.
- The operating system shows a system-controlled permission dialog that the app cannot alter or fake.
- The user allows, limits or denies access, and the system stores the decision per app.
- On every later use, the system enforces the stored grant; a denied request simply fails or returns no data.
- The user can change the decision at any time in settings, and the system may revoke unused grants automatically.
Because the dialog belongs to the operating system, the app cannot grant itself access. It can only ask, explain and adapt when the answer is no, which makes graceful handling of denial a core part of good app design.
Permission categories and protection levels
Mobile platforms divide permissions by how much risk they pose to privacy and system integrity. Android expresses this explicitly as protection levels; iOS uses a similar distinction between capabilities granted silently and those requiring user consent.
| Category | Examples | How access is granted |
|---|---|---|
| Install-time or normal | Internet access, vibration, network state | Granted automatically at installation |
| Runtime or dangerous | Camera, microphone, location, contacts | User consent through a system dialog |
| Special access | Display over other apps, exact alarms, accessibility | Manual enabling in system settings |
| Signature or system | Low-level device and system functions | Only apps signed by the platform or maker |
Recent platform versions also offer granular and temporary grants. These reduce how much data an app receives even when the user agrees to share something.
| Option | What it limits | Typical use |
|---|---|---|
| Allow only while using the app | Access only when the app is in the foreground | Navigation and camera apps |
| Allow once | A single session; the grant expires afterward | Occasional location or microphone use |
| Approximate location | Location within a wider area instead of a precise point | Weather and local content |
| Limited photo access | Only photos the user selects | Uploading a profile picture |
| Background location | Access while the app is not visible | Fitness tracking and geofencing, with extra review |
Android and iOS permission models compared
Both major mobile operating systems follow the same principle of runtime consent and sandboxing, but they differ in details that affect developers and users. The table summarizes the main differences.
| Aspect | Android | iOS |
|---|---|---|
| Declaration | Permissions listed in the manifest | Usage description strings in Info.plist |
| Runtime prompts | Required for dangerous permissions since Android 6.0 | Required for privacy-sensitive resources |
| Repeated requests | Further prompts blocked after repeated denials | Prompt shown once; later changes only in settings |
| Automatic revocation | Grants removed from long-unused apps | Reminders and summaries for background location |
| Usage indicators | Status bar indicator for camera and microphone | Colored indicator dots for camera and microphone |
The iOS one-time prompt makes timing especially important: if a user denies access in the first prompt, the app can only direct them to settings. On Android, repeated denials have a similar effect, so both platforms reward apps that ask only when the benefit is obvious.
Requesting permissions well
Good permission design follows the principle of least privilege: request the smallest set of permissions, at the narrowest scope, at the moment the user can see why. This improves grant rates, reduces privacy risk and eases app store review.
| Situation | Recommended approach | Reason |
|---|---|---|
| Feature used by a minority of users | Ask when the feature is opened | Avoids prompts most users never need |
| Purpose not obvious from context | Show a short explanation screen first | Raises understanding before the system dialog |
| Only one file or photo needed | Use the system picker instead | No broad storage or photo permission required |
| Coarse location is enough | Request approximate location | Respects privacy and passes review more easily |
| User denied access | Keep the app usable and offer a settings link | Avoids blocking or nagging |
Requesting many permissions at first launch is a common anti-pattern. Users have no context, often deny everything, and may uninstall the app before it has delivered any value.
Limitations and common misconceptions
Permissions control access to resources, not what an app does with the data afterward. Once a user grants contact access, the app technically can read all contacts, so policy enforcement depends on app store rules, privacy laws and the developer’s own conduct.
- Third-party SDKs inherit the app’s permissions, so an analytics or advertising library can use location the app was granted.
- Denying a permission does not always stop data inference; network information and sensors can still reveal some context.
- Special access permissions, such as accessibility services, are powerful and frequently abused by malicious apps.
- Granted is not permanent: apps must check permissions on every use because users and the system can revoke them.
- Permission lists in app stores describe capability, not actual behavior, and are only a partial view of privacy.
For developers, the key takeaway is that every protected call can fail. Code must handle denial, revocation and limited grants as normal states rather than as rare errors.
A plain-language summary
App permissions are the questions your phone asks before an app can use something private, such as your camera, location or photos. You decide whether to say yes, no or only this time.
It is like giving a house key to a visitor: a delivery person may get access to the front porch, not the whole house. You stay in charge of what each app can reach, and you can take the key back at any time in the phone’s settings.
An example from practice
A small team built a mobile app for a local food delivery service. The first version asked for location, camera, contacts and notifications immediately after installation, and many new users denied all of them, which left the app unable to suggest nearby restaurants.
In the next release, the app requested approximate location only after the user tapped “find restaurants near me”, used the system photo picker for profile pictures instead of camera and storage access, dropped the contacts permission entirely and asked about notifications after the first order.
More users granted location in context, the app passed store review with fewer questions about data use, and support requests about “the app not working” declined. Asking less, and at the right moment, made the app both more private and more useful.