iOS has two separate systems worth understanding: runtime permission prompts (what happens when an app first tries to access something) and App Store privacy labels (what a developer discloses before you even install).
Permission prompts — the "why" matters
iOS requires apps to request access to sensitive data at the moment they need it, with a system-controlled prompt the app can't skip or fake:
"MyApp" Would Like to Access Your Photos
[Don't Allow] [Allow]
For camera, microphone, and location, iOS goes further and requires apps to explain why they're asking (a string the developer provides, shown directly in the prompt). A photo-editing app asking for photo access is self-explanatory; a flashlight app asking for contacts access is a signal worth pausing on.
The Settings-level permission review
Settings → Privacy & Security lists every permission category (Location Services, Photos, Camera, Microphone, Contacts, etc.) and every app that has access to each — the same "audit by category, not by app" approach that's more useful than checking apps one at a time.
For location specifically, tapping into an app's entry shows options beyond Allow/Never: "Ask Next Time," "While Using the App," and "Always" — and iOS periodically re-surfaces a reminder showing you a map of where an app accessed your location in the background, specifically to make "Always" access visible instead of silent.
App Store privacy labels — what they actually tell you
Every app's App Store listing has a "App Privacy" section, broken into three categories:
- Data Used to Track You — data potentially linked to you and shared with third parties/data brokers for tracking across other companies' apps and websites. This is the category worth the most scrutiny.
- Data Linked to You — data tied to your identity but not used for cross-app tracking.
- Data Not Linked to You — collected but not tied to your identity.
| Category | What it means |
|---|---|
| Data Used to Track You | Linked to you and shared with third parties for cross-app/site tracking — the category worth the most scrutiny |
| Data Linked to You | Tied to your identity, not used for cross-app tracking |
| Data Not Linked to You | Collected but not tied to your identity |
The important caveat: these are self-reported
Privacy labels are filled out by the developer, not independently verified by Apple before publishing. Apple does take enforcement action against apps found to be inaccurate after the fact, but there's no guarantee a label perfectly reflects an app's actual behavior at the moment you're looking at it. Treat labels as a meaningful signal, not a guarantee.
App Tracking Transparency (ATT)
Separate from privacy labels: since iOS 14.5, apps must explicitly ask permission before tracking you across other companies' apps and websites (the system prompt: "Allow [App] to track your activity across other companies' apps and websites?"). Declining this doesn't block the app from functioning — it blocks that specific cross-app tracking use case, most commonly used for targeted advertising.
A practical approach
Before installing an app that seems to want more access than its function justifies, check its App Privacy section on the listing page first — it takes ten seconds and often makes the decision obvious before you've even downloaded it.
Privacy Report: seeing what apps have actually accessed
Beyond the permission toggles and privacy labels, Settings → Privacy & Security → App Privacy Report (once enabled) logs the specific times each app actually accessed sensors and data — a more concrete record than a label's category, since it shows real accesses rather than declared intentions:
MyApp accessed:
Location — 14 times in the last 7 days
Microphone — 2 times in the last 7 days
Contacts — 1 domain contacted: analytics.example.com
The domains-contacted section is particularly useful — it surfaces third-party analytics or ad SDKs an app talks to that wouldn't be obvious from the App Store listing alone, since a privacy label reports data categories, not the specific network destinations receiving that data.
Third-party SDKs: the hidden layer behind a single app's label
A privacy label describes the app as a whole, but most apps of any complexity embed multiple third-party SDKs (analytics, crash reporting, ad networks) — each capable of collecting its own data independently of what the app's own code does. This is why two apps with similar core functionality can have meaningfully different privacy labels: the difference is often in which SDKs each one bundled, not in what the app itself was built to do. It's also why an app's label can change after an update with no user-facing feature change at all — swapping or adding an analytics SDK alone can shift the disclosed categories.
Local Network access — an easy-to-miss permission
A separate, less-discussed prompt covers Local Network access — whether an app can discover and connect to devices on your home Wi-Fi (a smart TV, a printer, a home automation hub). It's easy to approve reflexively since it doesn't sound as sensitive as location or contacts, but it's worth applying the same scrutiny: an app with a genuine reason to talk to local devices (a casting app, a smart-home controller) is different from one with no obvious local-network use case asking for it anyway.
Permissions and privacy labels are one layer of account security — pairing sensible permission grants with two-factor authentication on the accounts those apps connect to, and understanding the broader OWASP Top 10 risks those apps' own backends need to defend against, rounds out the picture beyond what's visible on-device.
Common mistakes
- Granting "Always" location access reflexively because it's offered, when "While Using the App" covers what most apps actually need to function. Reserve "Always" for apps where background location is the entire point (navigation, fitness tracking with route history).
- Assuming a low "Data Not Linked to You" count means an app is privacy-friendly overall — check all three categories together; an app can look reasonable in one column and aggressive in "Data Used to Track You."
- Treating the privacy label as a one-time check. Labels can change across app updates as a developer adds new SDKs or features — worth a second glance after a major update to an app you're not fully confident in.
- Ignoring the periodic "this app has been using your location in the background" reminder iOS surfaces. It exists specifically to make silent "Always" access visible again — dismissing it without reviewing defeats the point.
Related reading
- iOS Shortcuts: Automating Your iPhone Like a Developer — shares tags: iphone (same category).
- Android App Permissions: A User's Guide to Staying Safe — shares tags: cybersecurity.
- Two-Factor Authentication: How It Actually Works — shares tags: cybersecurity.
- OWASP Top 10, Explained for Developers Who Aren't Security Specialists — shares tags: cybersecurity.
