The permission is held from the moment you grant it until the moment you revoke it. It does not expire, does not reset, and does not re-ask on its own.
iPhone App Permissions: How to Check What Each App Can Access
An iPhone app keeps a permission until you take it back. Here is how to audit all eight permission surfaces one at a time, what the green and orange indicator dots mean, and how to tell a routine hygiene check from a real warning sign, using only Apple's own settings.
General information only. Setting names and locations vary by iOS version and device, so check Apple's own Support pages for your model, and read our disclaimer.
The Basics
How iPhone App Permissions Work
The permission-is-a-door-not-a-window reframe — an OS permission is a grant that the app holds until you revoke it, not a one-time question that resets. I answered the permission question when I installed the app, so the matter is settled and I do not need to think about it again. The permission is a grant that the app holds until you revoke it. The door stays open until you close it, and the latch is the only thing that keeps it closed. The discipline is the surface-by-surface audit: walk the eight surfaces separately, set each permission against the app's stated function, and watch the indicator as the signal that the door is currently open. The most common loss is not the app that spies; it is the permission you granted once and never audited. This is the reframe the page exists to make, and it is the most carefully hedged line in the batch, because the naive version — "I answered the question, so the matter is settled" — leads a reader to grant a permission once, forget it, and never audit the latch, while the second naive version — "revoke everything" — leads a reader to break the apps they rely on and create a churn that is worse than a considered audit.
The honest position is neither panic nor complacency: most apps use permissions for their stated function, the audit is a hygiene check rather than a witch-hunt, and the tells apply in both directions. But the permission is a grant that the app holds until you revoke it, and the discipline is the surface-by-surface audit — eight separate taps, walked on a schedule, with each permission set against the app's stated function rather than against a reflex. The page teaches the method; it does not assert a universal revoke-everything rule or a universal grant-everything rule, and it does not recommend third-party "permission manager" apps, because the device's own settings are the authoritative surface and a third-party tool may request permissions beyond what the OS asks for. The most common loss is the permission you granted once and never audited, and the second is the panic churn that breaks the apps you rely on.
The permission — the door the OS holds the latch to
- The grant — the app asks, you answer, and the permission is held until you revoke it
- The trichotomy — "ask next time" / "while using" / "always" / "never," where the OS offers the choice
- The limits — the precise-location toggle, the photo-picker limit, the contact-list limit, where offered
- The indicator — the green or orange dot that signals the door is currently open
- The revoke — the latch you can close at any time, on any of the eight surfaces
- The permission is the OS's contract; the latch is yours
The dividing line is the behaviour: the permission is the door; the app's conduct behind the door is the app's to honour, not the OS's to enforce. A reader who grants the photos permission and assumes the OS is auditing what the app does with the photos has confused the latch with the guard. The indicator tells you the door is open right now; it does not tell you what the app did with the room last Tuesday. The discipline is to set the permission against the app's stated function — core, ancillary, or unnecessary — and to read the indicator as a signal worth investigating rather than as proof of a spy. Both naive ends fail: the reader who assumes the latch guarantees the conduct, and the reader who assumes every indicator is an intrusion.
The usage — what the app actually does behind the door
- The stated function — the reason the app exists, and the permission it genuinely needs to do it
- The ancillary function — the feature you do not use, whose permission you may not need to grant
- The background behaviour — what the app does when you are not looking, which the indicator may or may not catch
- The privacy documentation — the app's own statement of what it does with the room
- The gap — the distance between the grant and the conduct, which the OS cannot close for you
- The usage is the app's contract; the enforcement is the app's to honour
The two bands and the divider are the page's entire method compressed into one distinction, and its power is that it converts a witch-hunt into a trade-off. The failure mode the split prevents is the sympathetic one: a reader who sees the orange dot while a messaging app is idle, concludes the app is listening, revokes the microphone, breaks the voice-note feature they use daily, and then re-grants it in frustration — a churn that leaves the permission exactly where it started and the reader exactly where they began, minus the trust in their own judgement. The discipline is to set the permission against the app's stated function, to read the indicator as a signal to investigate rather than a verdict, and to consult the app's own privacy documentation for the conduct behind the door. And the honest limit is stated in the same breath: the OS holds the latch, not the guard, and the page cannot audit any specific app's behaviour for you.
The surface-by-surface permission audit — eight separate taps, walked on a schedule
1
Camera — the door to the room that seesOpen the device's camera-permission surface and read which apps hold the grant. Ask of each: is the camera core to the function I use (a camera app, a video-call app, a scanner), ancillary to a feature I do not use (a game's AR mode), or unnecessary? Set core to "while using," ancillary to "ask next time," unnecessary to "never."
The 111 surface-by-surface discipline transplanted: the audit is a routine, not a one-time setup, and the camera is the first of eight taps.
2
Microphone — the door to the room that hearsRead which apps hold the microphone grant, and apply the same core/ancillary/unnecessary test. A voice-assistant or call app needs it core; a note-taking app's dictation feature needs it ancillary; a torch app needs it never. The orange indicator is the signal that this door is currently open.
The indicator tell: an unexpected orange dot while an app is idle is a signal to investigate — but investigate through the app's own privacy documentation, not through a verdict.
3
Location — the door with the most settings behind itLocation is the surface with the richest trichotomy: "never," "while using," and — where offered — "always," plus the precise-location toggle that gives an approximate position instead. A navigation app needs "while using" and precise; a weather app may accept "always"-off and approximate; a flashlight app needs "never." Audit the "always" holders first, because that is the door that stays open behind your back.
The precise-location toggle is the photo-picker's cousin for location: it lets an app use the room without seeing the whole house. Where offered, it is the ancillary-function answer.
4
Photos — the door with the picker behind itWhere the OS offers it, the photo-picker limit lets an app see only the images you explicitly choose rather than the whole library. Audit which apps hold full-library access, and downgrade the ancillary ones to the picker. A photo-editing app needs the library; a profile-picture setter needs the picker; a calculator needs neither.
The picker limit is the single most under-used privacy control on the device, and it is the answer to the "why does this app want all my photos" question.
5
Contacts — the door to other people's dataContacts are not only your data; they are your contacts' data, held by you in trust. Audit which apps hold the grant, and apply the same test. A messaging app needs it core; a call-screening app needs it core; a game needs it never. Where the OS offers a limited list, use it.
The contact-list limit is the picker principle applied to other people's details, and the trust framing is the reason this tap is worth walking even when the app seems harmless.
6
Bluetooth and nearby devices — the door to the room around youBluetooth and nearby-device permissions let an app discover the devices and beacons around you — which can locate you as surely as GPS, and sometimes more precisely indoors. Audit which apps hold the grant, and apply the test. A headphone or wearable app needs it core; a file-sharing app needs it core; a shopping app's beacon feature needs it ancillary or never.
The 109 metadata lesson inverted: a proximity signal is metadata that can identify a place, and an app that reads beacons does not need to read your location permission to know where you are.
7
Tracking — the door between apps, not into the deviceThe tracking permission is structurally different: it does not let an app into a room on your device; it lets one app's data follow you into another app's. Where the OS offers it, set the default to deny and grant per-app only where you understand the benefit. This is the tap most often confused with the other seven, and the confusion is the loss.
The tracking permission is the cross-app door, not the device door. Auditing it with the same core/ancillary/unnecessary test is a category error — the question here is "should this app's data follow me elsewhere?"
8
Notifications — the door that 117 already taught you to sortNotification permission is the outbound channel's device-side gate, and it is the tap where this page meets the notifications guide. Where the OS offers per-category control, keep the transactional carve-out (order, delivery, security, refund, recovery) open and close the marketing categories — the same sort, applied at the device level rather than the account level.
The 117 dependency, now at the device tap: muting an app's notifications wholesale to quiet the badge also mutes the login alert and the delivery notice. Sort by category if the OS allows it; do not nuke the channel.
The sequence's logic is the eight-tap audit, walked on a schedule and set against the app's stated function: camera, microphone, location, photos, contacts, Bluetooth, tracking, notifications — because the most common failure is a reader who answered the permission question once at install, never reopened the latch, and so holds a grants inventory they cannot describe. The discipline is to walk the eight taps separately, to apply the core/ancillary/unnecessary test to the first six, to treat the tracking tap as a structurally different question, and to hand the notification tap to the sort the notifications guide already teaches. And the honest limit is that the menu names, the per-app versus per-surface layout, the trichotomy options, and the picker and precise toggles vary by OS version, device, and region; the page teaches the audit, not the layout of any one settings screen.
The permission anatomy — the control, what it does, and the limit
The grant and the revoke
The control
The limit
The reader who believes the question was one-time holds an inventory they cannot describe. The audit is the routine that keeps the inventory legible.
The trichotomy — ask next time / while using / always / never
The control
Where the OS offers the choice, "ask next time" re-prompts, "while using" opens the door only in the foreground, "always" opens it in the background, and "never" closes it.
The limit
The "always" holders are the doors that stay open behind your back, and they are the first to audit. Not every "always" is wrong — a security app, a find-my device, a health monitor may legitimately need it — but every "always" deserves a reason you can state.
The indicator — the green and orange dots
The control
The indicator signals that the camera or the microphone is currently in use. It is the OS's honest report that the door is open right now.
The limit
It is a signal, not a verdict, and not a log. It does not tell you what happened last week, and it does not tell you the app is malicious — a legitimate call, a voice memo, or a video conference lights it honestly. Investigate an unexpected indicator; do not convict on it.
The precise-location toggle
The control
Where offered, it lets an app receive an approximate position instead of an exact one — the room without the street number.
The limit
It is the ancillary-function answer: a weather app, a news app, or a store-locator may work perfectly on approximate. Navigation and ride-hailing usually need precise. The toggle is the trade-off made visible.
The photo-picker limit
The control
Where offered, it restricts an app to the specific images you choose, rather than the whole library.
The limit
It is the single most under-used control on the device, and the direct answer to "why does this app want all my photos." Downgrade the ancillary holders; keep the library only where the function genuinely needs it.
The contact-list limit
The control
Where offered, it restricts an app to a chosen subset rather than the full address book.
The limit
Contacts are other people's data held in your trust, so the bar for granting full access is higher than for your own files. A messaging or call-screening app may warrant it; a game does not.
The tracking permission
The control
It governs whether one app's data can follow you into another app — a door between apps, not into the device.
The limit
Structurally different from the other seven, and the tap most often confused with them. The question is not "what can this app see on my device" but "should this app's profile travel with me." Deny by default; grant where you can state the benefit.
The notification gate
The control
It governs whether an app may present alerts at all, and — where the OS allows — per category.
The limit
The device-side twin of the account-side sort (117). Muting the whole gate to quiet a badge also mutes the security alert and the delivery notice. Sort by category where you can; otherwise choose between the noise and the carve-out knowingly.
The background-refresh and proximity pair
The control
Background activity and the Bluetooth/nearby gate together determine whether an app can act while you are not looking — the door that stays open behind your back.
The limit
A reader who audits only the foreground permissions has audited half the house. The "always" location holders, the beacon readers, and the background refreshers are the surfaces where the indicator will not help you, because nothing is happening on screen.
| Tap | The question to ask | The core answer | The tell |
|---|---|---|---|
| Camera | Does the function I use need to see? | While using for core; never for unnecessary | Green indicator while idle = investigate |
| Microphone | Does the function I use need to hear? | While using for core; never for unnecessary | Orange indicator while idle = investigate |
| Location | Precise, approximate, or never? | While using + precise for navigation | "Always" holders audited first |
| Photos | Whole library or picked images? | Picker for ancillary; library for editing | Full-library holders are the ones to downgrade |
| Contacts | Whose data is it really? | Core for messaging; never for games | Other people's data — higher bar |
| Bluetooth/nearby | Does it need to know the room? | Core for wearables; ancillary or never | Beacon reads can locate you without GPS |
| Tracking | Should the profile travel? | Deny by default | Structurally different from the other seven |
| Notifications | Sorted by category or nuked? | Keep the carve-out (117) | Wholesale mute kills the security alert |
The anatomy is the same claims-vs-mechanism habit the payslip, bill, and account-security guides taught, applied to a device where the claim is "I answered the permission question" and the mechanism is the nine controls above. A grant is not a one-time answer. An indicator is not a verdict. A precise toggle is not a luxury. A photo picker is not a nuisance. A contact list is not your data alone. A beacon read is not a location permission. A tracking prompt is not a privacy prompt. A muted gate is not a sorted channel. Background activity is not foreground activity. The discipline is the anatomy: read the control, name the limit, and set the permission against the function — because the most common loss is the permission you granted once and never audited, and the second is the panic churn that breaks the apps you rely on.
The permission tells — the signals that separate a hygiene check from a witch-hunt
the indicator lit while the app is idle
an "always" location holder you cannot justify
full-photo-library access for a profile-picture task
a contact grant on an app with no messaging function
a beacon or nearby-device grant on a shopping app
a tracking prompt accepted without a stated benefit
a notification gate muted wholesale to quiet a badge
a permission granted at install and never revisited
a third-party "permission manager" asking for its own grants
a re-grant churn after a panic revoke
The tells are the both-directions signals, and the discipline is to read them as audit prompts rather than as verdicts. The first seven are the doors worth closing or narrowing: an indicator that lies, an "always" you cannot justify, a library grant for a picker task, a contact grant with no messaging function, a beacon read on a shopping app, a tracking prompt accepted blindly, a notification gate nuked for a badge. The eighth is the loss this page exists to prevent: the permission granted at install and never revisited — the door you closed once and assumed stayed closed. The ninth is the official-route discipline the download, reduce-data, and buffering guides all hold: a third-party "permission manager" may request permissions beyond what the OS asks for, and the device's own settings are the authoritative surface. The tenth is the panic churn — revoke everything, break the apps, re-grant in frustration — which leaves the inventory exactly where it started and the reader worse off. The safe posture is the considered audit: walk the eight taps, set each against the function, and revisit on a schedule.
A worked example: the two readers, and the one who walked the eight taps
Concretely, the permission-is-a-door reframe, the permission-versus-usage split, the surface-by-surface audit, the permission anatomy, and the permission tells meeting two readers who each hear that apps are "collecting too much" and open their settings for the first time.
Reader one revokes everything and breaks the house. Alarmed, reader one goes through the settings and sets every permission to "never" — the camera, the microphone, the location, the photos, the contacts, the Bluetooth, the tracking, and the notifications. By evening the navigation app cannot navigate, the messaging app cannot send a voice note, the camera app cannot save a photo to the library, the headphones will not pair, and the delivery notice that would have started a convergence check (113) never arrives, because the notification gate is shut. Reader one re-grants in frustration, one by one, without a plan, and ends the night holding the same inventory they started with — plus a muted security alert (111) and a confused weather app. The loss is not the app that collected; it is the panic churn that broke the functions and left the permissions unexamined.
Reader two walks the eight taps and sets each against the function. The same alarm, the same settings — but reader two opens the audit as a routine rather than a purge. Camera: the video-call app is core, "while using"; the torch app is unnecessary, "never." Microphone: the note-taking app's dictation is ancillary, "ask next time"; the call app is core. Location: navigation is "while using" with precise; the weather app drops to approximate; the flashlight app is "never" — and reader two audits the two "always" holders first, finding one legitimate (the find-my device) and one not (a shopping app that only needs a store locator). Photos: the editing app keeps the library; the profile-picture setter drops to the picker. Contacts: messaging keeps it; the game loses it. Bluetooth: the headphones and the wearable keep it; the shopping app's beacon feature loses it. Tracking: denied by default, with one grant where reader two can state the benefit. Notifications: sorted by category where the OS allows, keeping the order, delivery, security, refund, and recovery carve-out (117) and closing the marketing — the same sort the notifications guide teaches, applied at the device tap. Reader two writes the date of the audit and revisits in a season. The house still works; the doors are legible; the indicator is a signal reader two now knows how to read rather than a threat to fear.
The lesson is the whole page. Both readers had the same alarm and the same settings; the difference was not the apps but the method. Reader one purged and churned, breaking the functions and leaving the inventory unexamined. Reader two walked the eight taps, applied the core/ancillary/unnecessary test, audited the "always" holders first, used the picker and precise toggles, treated tracking as a structurally different question, sorted the notification gate rather than nuking it, and diaried the audit. The permission-is-a-door reframe is what prevented the one-time-answer assumption — the grant is held until you revoke it — and the permission-versus-usage split is what prevented the verdict reflex — the indicator is a signal, not a conviction. The honest limit is that the page cannot assert your OS version's menu names, your device's per-category controls, or any specific app's conduct behind the door. The most common loss is the permission you granted once and never audited, and the discipline is the eight-tap audit, walked on a schedule, with each permission set against the function you actually use.
The Check
A Sensible Default
- Hold the reframe: an OS permission is a grant the app holds until you revoke it — not a one-time question that resets — so the audit is a routine, not a setup.
- Respect the permission-versus-usage split: the permission is the door and the OS holds the latch; the app's conduct behind the door is the app's to honour, and the indicator is a signal that the door is open now, not a verdict on what the app does with the room.
- Walk the eight taps separately: camera → microphone → location → photos → contacts → Bluetooth/nearby → tracking → notifications — because revoking one does not revoke the others.
- Apply the core / ancillary / unnecessary test to the first six: core to "while using," ancillary to "ask next time" or the picker/approximate toggle, unnecessary to "never."
- Audit the "always" holders first, and the background and proximity surfaces too — the indicator will not help you there, because nothing is happening on screen.
- Use the toggles the OS offers: the precise-location approximation, the photo picker, the contact-list limit — the trade-offs made visible, and the answer to the ancillary function.
- Treat tracking as a different question: it is a door between apps, not into the device. Deny by default; grant only where you can state the benefit.
- Sort the notification gate rather than nuking it (117), and keep the transactional carve-out — the order, delivery, security, refund, and recovery alerts that 111, 113, and 114 depend on.
- Refuse both naive ends: the one-time-answer assumption and the panic churn — and refuse third-party "permission managers," because the device's own settings are the authoritative surface.
- Diary the audit date and revisit on a schedule, because the inventory drifts as apps update and new apps arrive.
The honest takeaway is that a permission audit is a hygiene check on eight separate taps rather than a witch-hunt or a one-time answer, and the discipline that keeps the house legible is the surface-by-surface audit: walk the eight taps, apply the core/ancillary/unnecessary test, audit the "always" and background holders first, use the picker and precise toggles, treat tracking as a structurally different question, sort the notification gate rather than nuking it, and revisit on a schedule. For the platform-level hygiene check this page transplants to the device, see our account-security guide; for the notification sort this page hands back at the eighth tap, see our notifications guide; for the memory-and-recommendation surfaces that are different from the device permissions (revoking the microphone does not change what the platform recommends), see our clear-watch-history and manage-search-history guides; for the content filter that is a platform surface rather than a device one, see our restricted-mode guide; for the data-portability and erasure task that sits above the device audit, see our export-or-delete guide; and for the actual menu names, the per-app versus per-surface layout, the trichotomy options, the picker and precise toggles, the indicator behaviour, and any specific app's conduct behind the door, see the device's own settings, the OS vendor's support documentation, and the app's own privacy documentation — the authorities this page keeps routing you to, because the shape of the eight-tap audit is durable, the specifics are not ours to assert, and the permission you granted once and never audited is the loss.
Common Questions
Frequently Asked Questions
How do I check what permissions my apps have?
Through the device's own settings, surface by surface. The camera, the microphone, the location, the photos, the contacts, the Bluetooth, the tracking, and the notifications are eight separate taps, and revoking one does not revoke the others. The discipline is to open the device's privacy or permissions settings and audit each surface separately, because a permission is a grant that the app holds until you revoke it — it is not a one-time question that resets. The exact menu names and the per-app vs per-surface layout vary by OS version and device, and they change over time; the page teaches the method of the surface-by-surface audit, not the layout of any one settings screen.
Does revoking a permission stop the app from working?
It can, and the trade-off is the permission-versus-usage split in action. A navigation app that loses the location permission cannot navigate; a camera app that loses the camera permission cannot photograph; a voice-assistant app that loses the microphone permission cannot listen. The discipline is to audit the permission against the app's stated function: if the permission is core to the function you use, revoking it breaks the function; if the permission is ancillary to the function you use, revoking it may be the right trade-off. The page does not tell you which to revoke; it teaches the method of the audit and the trade-off.
What is the green or orange dot at the top of the screen?
It is the indicator that the camera or the microphone is currently in use — the door is open right now. The green dot is the camera; the orange dot is the microphone (the colours and the behaviour vary by OS version). The discipline is to read the indicator as a signal that the door is currently open, not as a guarantee of what the app does with the room. If the indicator appears when you are not using an app that needs the camera or the microphone, that is a tell worth investigating — but the indicator is the OS's signal, not the app's behaviour, and the page does not assert that every indicator is a spy.
Should I revoke every permission I do not actively use?
Not necessarily, and the page refuses both naive ends. The reader who revokes every permission for a panic reflex breaks the apps they rely on and then re-grants them in frustration, creating a churn that is worse than a considered audit. The reader who grants every permission for a convenience reflex leaves the doors open unnecessarily. The discipline is the surface-by-surface audit: for each permission, ask whether it is core to the function you use, ancillary to the function you use, or unnecessary, and set the permission accordingly — 'while using' for the core, 'ask next time' for the ancillary, 'never' for the unnecessary. The page teaches the method; it does not assert a universal revoke-everything rule.
Why does a shopping app want my location "all the time"?
Usually it does not need to, and this is the "always" audit in action. A store-locator or delivery-radius feature needs location while using; a delivery app may need it while the app is open and occasionally in the background for a driver's route; but a continuous "always" grant on a shopping app is the tell worth narrowing. Drop it to "while using," and if the OS offers it, drop the precision to approximate — the store locator works on an approximation. The honest limit is that some background location is legitimate (a find-my device, a security app, a health monitor), so the test is not "is always bad" but "can I state the reason this app needs the door open behind my back." If you cannot, narrow it.
An app asked for photos and I only want it to see one picture. Is there a middle setting?
Where the OS offers it, yes, and the photo picker is the most under-used control on the device. Instead of granting the whole library, the picker lets you select the specific images the app may see, which is exactly the profile-picture, avatar, or send-this-one task. The discipline is to reach for the picker before the library: a photo-editing app that genuinely works across your library warrants the library; a form that wants one image warrants the picker; an app that asks for the library to "improve your experience" warrants a question you can answer from its own privacy documentation. The same principle applies to contacts (the limited list) and to location (the approximate toggle) — the trade-off made visible rather than all-or-nothing.
Is the tracking prompt the same kind of permission as the camera prompt?
No, and confusing them is the most common category error on this page. The camera, microphone, location, photos, contacts, and Bluetooth permissions are doors into your device — they let an app into a room. The tracking permission is a door between apps — it lets one app's data follow you into another app's, which is a cross-app profile question rather than a device-access question. The test is different too: for the device doors you ask "does the function I use need this room"; for tracking you ask "should this app's profile travel with me, and what do I get for it." Deny tracking by default and grant it only where you can state the benefit, and do not let a tracking prompt's familiar shape trick you into treating it as just another privacy toggle.
Ask our AI. Auditing a permission or reading an indicator? Tap the chat icon and tell us the app, the permission it holds, the function you actually use, and whether the indicator lit unexpectedly, and it can walk the eight-tap audit, apply the core/ancillary/unnecessary test, and flag the picker, approximate, and "always" tells — and it will never assert a universal menu path, convict on an indicator, or recommend a third-party permission manager. It will route the menu names, the per-category controls, and the toggle availability to the device's own settings and the OS vendor's support documentation, and any specific app's conduct to the app's own privacy documentation.
More device & privacy guides like this
We treat a permission audit as a hygiene check on eight separate taps rather than a witch-hunt or a one-time answer — so the discipline is the surface-by-surface audit: walk the eight taps, apply the core/ancillary/unnecessary test, audit the "always" and background holders first, use the picker and precise toggles, treat tracking as a structurally different question, and sort the notification gate rather than nuking it.
Explore All GuidesKeep Reading
Sources:
Other Projects
More from the creator
Explore two other projects from the same creator.