Core Location · permission QA
Test the permission journey, not only the Allow button
iOS location permission testing needs more than one successful system prompt. People can deny a request, allow access only while using the app, change the choice later in Settings, or limit accuracy. A useful matrix pairs each platform state with the exact feature that requested it, the explanation a person saw, the fallback they can use, and the result after authorization changes.
Which iOS location permission states should an app test?
Cover not determined, denied, restricted, When In Use, and Always where the product truly requires it. Cross those states with full and reduced accuracy where available, plus app relaunch and a Settings change. Verify the usage description, request timing, authorization callback, product fallback, and data minimization at each supported branch.
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.
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 |
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.
Name the minimum need
Document why the feature needs location, whether foreground access is enough, and what precision changes the result.
Write the supported branches
Define not determined, allowed, denied, restricted, reduced accuracy, elevated access if needed, and the manual fallback.
Prepare isolated states
Start each test with known authorization, accuracy, account, cache, and developer location inputs rather than depending on prior order.
Change and recover
Modify permission in Settings, return or relaunch, verify the updated UI, stop disallowed collection, and prove the fallback remains useful.
Frequently asked questions
Should an iPhone app request Always authorization first?
Usually not — 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?
Authorization level and accuracy authorization are separate 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?
A controlled developer input does not replace consent 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?
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?
Accuracy authorization is the first thing to check the main status. Apple's documentation says reduced accuracy prevents region monitoring, so the app needs an appropriate explanation or alternative.
Sources
- Apple authorization sourceRequesting authorization to use location servicesWhen in Use and Always choices, usage descriptions, request timing, and authorization changes.
- Apple API referenceCLLocationManager accuracyAuthorizationHow full and reduced accuracy affect requested precision and region-monitoring capability.
- Apple API referenceCLAuthorizationStatusThe not-determined, restricted, denied, When in Use, and Always states an app handles.
- Apple privacy sourceProtecting the user's privacyApple's platform guidance for purpose strings and access to protected resources.