App Permissions on Android and iOS: What You're Actually Granting

What App Permissions Actually Control

When an app requests a permission, it is asking the operating system to expose a specific hardware resource or data store that would otherwise be inaccessible. The permission system exists precisely because apps run in isolated sandboxes — they cannot reach outside that sandbox without an explicit grant from you.

Both Android and iOS categorize permissions into two broad tiers. Normal permissions cover low-risk actions (setting an alarm, using the internet) and are granted automatically at install. Dangerous permissions — those touching personal data or device hardware — require a runtime prompt that you must accept or deny. The distinction matters because many users assume every dialog they see carries equal weight; it does not.

For a detailed plain-language breakdown of each permission type, see the App Permissions Glossary.

Android vs. iOS: Where the Models Diverge

The two platforms share the same high-level goal — user consent before sensitive access — but implement it differently in ways that affect everyday control.

Granularity of Location Access

Both platforms now offer approximate and precise location as separate choices. iOS introduced this split in iOS 14; Android followed with Android 12. Approximate location shares a rough area (roughly 3 km radius) rather than GPS coordinates, which is sufficient for weather apps but inadequate for turn-by-turn navigation. Users can grant the coarser option to limit exposure.

Background Access

On Android, a separate "Allow all the time" option permits location access even when the app is closed. iOS uses the same language but adds a safeguard: it periodically surfaces a notification showing how often an app accessed location in the background, giving you a concrete usage record rather than an abstract permission state.

One-Time Permissions

Android 11 introduced one-time permissions for location, microphone, and camera. iOS 17 extended one-time camera and microphone grants as well. A one-time grant expires when the app is backgrounded, forcing a new request next session — useful for apps you use infrequently.

Understanding how the two ecosystems compare more broadly can also help — see why the same app feels different across platforms.

High-Risk Permissions: What Each One Exposes

Certain permissions open wider data pipelines than their single-word labels imply.

• Contacts: Grants read (and often write) access to your entire address book, including names, phone numbers, emails, and relationship labels. Some apps upload this data to map social graphs.
• Microphone: Enables audio capture from the device microphone. This is required for voice calls and voice search, but an app with this permission running in the background can technically record ambient audio on Android unless restricted to foreground-only use.
• Camera: Opens the image sensor for photo or video capture. Combined with location metadata embedded in EXIF data, camera access can reveal precise whereabouts even without a location permission grant — provided the app reads image metadata.
• Storage / Photos: On Android, "Read external storage" can expose the entire file system depending on API level. Android 13 introduced granular media permissions (images, video, audio separately). iOS has always scoped this to the Photos library, with options to share selected photos only rather than full library access.
• Bluetooth: From Android 12 and iOS 13 onward, Bluetooth is a separate dangerous permission because it can be used for proximity tracking via beacon scanning — independent of location services.

Auditing and Revoking Permissions

Both platforms provide a permission manager that shows every app mapped to every permission it holds — accessible without downloading any third-party tool.

On Android, navigate to Settings → Privacy → Permission Manager. Tapping any permission category (e.g., Microphone) lists every app that has been granted that permission and at what level (always, only while in use, denied). On iOS, the equivalent path is Settings → Privacy & Security, where the same category-first layout applies.

A useful auditing habit: filter by permissions you consider high-risk and look for apps you no longer actively use. Dormant apps retain their grants until manually revoked — the OS does not automatically rescind them on inactivity, though Android 11 and later does auto-reset permissions for apps unused for several months.

Before installing a new app, the permission scope it declares in the App Store or Google Play listing is visible before download. Reviewing declared permissions at that stage — rather than reacting to runtime dialogs — gives you a cleaner decision point. The pre-install permission checklist walks through exactly that process.

For a broader security framing, the guide to when to say no to app permissions covers the decision logic in more depth.