Key checks
Work through the guide
Start with the section that matches your task, then follow the evidence and recovery steps before calling the test complete.
Request the least access at the moment it becomes understandable
Apple describes When in Use as the preferred authorization level because of its privacy and battery implications, and reserves Always access for features that need delivery outside active use. Test that the app asks only after a person reaches a feature whose value is clear. A prompt on first launch, before any relevant action, makes the usage description carry too much explanatory work and gives the team little evidence about informed intent.
The Info.plist usage string and the in-app context should agree in plain language. Verify the When in Use description whenever the app requests location, and the additional Always description if the product requests elevated access. Apple documents that missing required usage keys can cause authorization requests to fail. Include a release-build check so a development configuration cannot hide a missing or inaccurate string.
- Tie the request to a user-initiated feature such as nearby results or trip recording.
- Explain the feature benefit, not a vague need to improve the experience.
- Prefer When in Use unless a documented background behavior requires more.
- Verify every shipping localization of the usage description.
Treat authorization level and accuracy as separate axes
An allowed app may still receive reduced rather than full accuracy. Check CLLocationManager accuracyAuthorization and design the feature for the precision it actually needs. A city-level discovery screen may work well with approximate data; a turn-by-turn or narrow-boundary feature may need to explain why temporary full accuracy is useful at the moment of use. Do not repeatedly pressure people who keep reduced accuracy.
Apple's API reference notes that reduced accuracy affects requested precision and prevents region monitoring and beacon ranging. A permission matrix must therefore assert feature capability, not merely a green authorization label. If geofencing is unavailable under the chosen accuracy, present an honest alternative such as a manual place, saved region, or foreground check instead of silently showing stale results.
- Record CLAuthorizationStatus and CLAccuracyAuthorization independently.
- Test the same screen with full and reduced accuracy where the feature supports both.
- Request temporary full accuracy only for a named, immediate purpose.
- Keep a usable fallback when precise data is declined.
Verify denial, Settings changes, relaunch, and data cleanup
Denial is a normal product state, not a broken test. The app should preserve the user's work, explain which feature is unavailable, and offer a non-coercive path to Settings only when changing the decision would restore a requested function. Test Restricted separately because the person may not be able to change it. A manual city, address, or map search can keep many experiences useful without automatic location.
People can change authorization while the app exists, so observe the platform's authorization-change callback or asynchronous diagnostics and update the interface without requiring a reinstall. Test foreground change, background-to-foreground return, and relaunch. Verify that revoking access stops unnecessary collection, clears transient precise data according to policy, and does not leave a spinner, stale nearby label, or hidden background session.
Use a fixed developer location only after the permission branch is established. Otherwise a successful coordinate fixture can disguise a missing consent flow. A GPS changer, fake GPS label, or selected map pin is never evidence that iOS granted access. Keep the permission decision, the location input, and the product result as three separate entries in the QA record.
- Cover deny on first request and a later Settings change without reinstalling.
- Verify Restricted copy does not promise that Settings can always fix access.
- Stop active services and background work after revocation.
- Test manual and no-location modes for accessibility and data freshness.
Decision table
A practical iOS permission matrix
Pair platform state with a product expectation. Add only the combinations that the feature and supported OS versions can actually reach.
| State | Expected product behavior | Evidence |
|---|---|---|
| Not determined | Explain value before the system request | Trigger action, usage string, prompt timing |
| Denied | Keep the app usable and offer a relevant fallback | Fallback task, Settings guidance, no new collection |
| Restricted | Explain unavailability without blaming the user | Distinct copy and disabled location-only action |
| When in Use + full accuracy | Run the foreground feature at required precision | Status, accuracy authorization, fresh result |
| When in Use + reduced accuracy | Use approximate behavior or explain a narrow limitation | Approximate result, fallback, no repeated pressure |
| Always authorization | Deliver only the documented background feature | Elevation flow, indicator, background event |
| Authorization revoked in Settings | Stop services and refresh UI on return | Change callback, cleared state, manual alternative |
Practical playbook
Turn one location feature into a permission test suite
Anchor the matrix to a real user task so privacy, functionality, and recovery are evaluated together.
- 1Name the minimum needDocument why the feature needs location, whether foreground access is enough, and what precision changes the result.
- 2Write the supported branchesDefine not determined, allowed, denied, restricted, reduced accuracy, elevated access if needed, and the manual fallback.
- 3Prepare isolated statesStart each test with known authorization, accuracy, account, cache, and developer location inputs rather than depending on prior order.
- 4Change and recoverModify permission in Settings, return or relaunch, verify the updated UI, stop disallowed collection, and prove the fallback remains useful.
References
Verify the claims in this guide
Open the references below for the platform documentation, service policies, and product boundaries used in the guide.
Requesting authorization to use location services
When in Use and Always choices, usage descriptions, request timing, and authorization changes.
Open the source ↗CLLocationManager accuracyAuthorization
How full and reduced accuracy affect requested precision and region-monitoring capability.
Open the source ↗CLAuthorizationStatus
The not-determined, restricted, denied, When in Use, and Always states an app handles.
Open the source ↗Protecting the user's privacy
Apple's platform guidance for purpose strings and access to protected resources.
Open the source ↗FAQ
Core Location · permission QA FAQ
Should an iPhone app request Always authorization first?
Usually no. Apple recommends When in Use as the preferred level and says to request Always only when necessary for the product's background behavior. Test a contextual, staged flow.
Is Precise Location the same as allowing location?
No. Authorization level and accuracy authorization are separate. A person can allow access while providing reduced accuracy, and the product should have a defined result for that state.
Does a mock location bypass denied permission?
No. A controlled developer input does not replace consent. Establish and assert the authorization branch separately from the coordinate supplied to the test.
What should happen when location is denied?
Preserve the user's task where possible with a manual city, address, map search, or non-location mode. Explain the limited feature without coercion and collect no new location data.
Do I need to reinstall for every permission test?
Not necessarily. Use approved test-state controls for isolation, and also test a real Settings change plus relaunch because that is a customer path. The result must not depend on suite order.
Why does geofencing fail with allowed permission?
Check accuracy authorization as well as the main status. Apple's documentation says reduced accuracy prevents region monitoring, so the app needs an appropriate explanation or alternative.