Location permission App Review checklist

Map location to a visible feature

Start with the user-visible outcome: nearby results, route tracking, place tagging, delivery coordination, safety check-in, device finding, or another concrete function. If the team cannot name a feature that breaks without location, the permission request is not ready for review.

Document whether the app needs approximate or precise location, one-time foreground access, while-in-use access, or background updates. This decision should be made per feature rather than copied from an older entitlement file.

Ask at the moment of need

1. Open the app from a fresh install and confirm no location prompt appears before feature context exists.
2. Navigate to the feature that needs location and check that the pre-prompt explains the user benefit.
3. Trigger the system permission sheet only after the user expresses intent to use that feature.
4. Decline permission and verify the app offers manual entry, reduced functionality, or a clear explanation.
5. Grant permission and confirm the app uses the minimum location mode needed for the feature.

Treat background location as a separate review case

Background location needs a durable reason that a user can understand after the app leaves the foreground. A one-time convenience feature rarely justifies persistent collection. If the app tracks routes, safety state, delivery progress, or device proximity, show the ongoing control and stop behavior clearly.

AppReviewReady interpretation: include a screenshot or Review Notes path to the screen where the user starts, pauses, and stops background tracking. A reviewer should not have to infer that control from a privacy policy.

Reconcile privacy labels, policy, and runtime behavior

• App Store privacy answers should describe location collection, linkage, tracking, and purpose consistently.
• The privacy policy should explain retention, sharing, and deletion for location history if the backend stores it.
• Analytics events should avoid precise coordinates unless the feature requires them and the disclosure covers them.
• Screenshots and marketing copy should not promise location behavior that the submitted build does not implement.

Give the reviewer a route to verify location use

Use a realistic test location or sample account only when the reviewer cannot see the feature from an arbitrary place. Do not require the reviewer to travel, join a private area, or satisfy a hidden geographic allow-list to verify the main behavior.

Location review path:
Feature requiring location: [name]
Permission requested: [while in use, always, precise]
How to trigger: [steps]
Why background is needed: [if applicable]
Denial behavior: [manual city, limited mode]
Where user stops sharing: [settings path]

Block submission on permission drift

Location code often changes when teams add maps, ads, attribution, weather, or local recommendations. Re-run the location checklist whenever SDKs change, because a new dependency can alter collection even when the primary feature is unchanged.