Guideline 5.1.5
Guideline 5.1.5 - Privacy: Requesting Location Access Without Relevant Feature
Our Take
Apple is rejecting your app because it requests location access (Always or When In Use) without a clear, user-facing feature that requires the user's location. Under guideline 5.1.5, location data can only be collected when directly relevant to the core functionality of the app, and it must be clearly communicated to the user why location is needed. This rejection commonly appears when: (1) the app requests 'Always' location when 'When In Use' would suffice, (2) location is requested for analytics, advertising, or ad targeting rather than a visible feature, (3) a third-party SDK requests location access that the app itself doesn't need, or (4) the app has a location feature but the purpose string doesn't adequately explain why location is needed. Apple is particularly strict about 'Always' location — you must demonstrate a continuous background location need (navigation, geofencing, fitness tracking during workouts). If your app only needs location when the user is actively using it, 'When In Use' is the maximum you should request. Requesting 'Always' for a feature that only needs foreground location will be rejected.
Resolution Guide
**Audit location usage** — Determine every place your app or its SDKs request location. Map each request to a specific user-facing feature.
**Downgrade to minimum access** — If 'When In Use' suffices, remove the `NSLocationAlwaysAndWhenInUseUsageDescription` key and only keep `NSLocationWhenInUseUsageDescription`. Only request 'Always' for genuine background needs.
**Remove unnecessary location** — If any location request has no corresponding user-facing feature (e.g., analytics-only), remove it entirely. Check third-party SDK configurations.
**Write a clear purpose string** — The `NSLocationWhenInUseUsageDescription` must specifically explain the feature. Bad: 'This app uses your location.' Good: 'Your location is used to show nearby restaurants and provide directions.'
**Request location at point of use** — Don't request location on app launch. Request it when the user taps a feature that needs it (e.g., 'Find Nearby' button), so the connection between the permission and the feature is clear to the reviewer.
Prevention
Example Rejection Email
Consider Appealing
Appeal if the location feature exists but was not found by the reviewer. Provide reproduction steps and screenshots showing the location-dependent feature. For 'Always' location, provide a detailed justification of continuous background location need.
Before & After
App requests Always location on first launch with purpose string 'This app needs your location'; location is used only to sort a list of stores by proximity when user taps 'Nearby'
App requests When In Use location only when user taps 'Nearby Stores' button; purpose string: 'Your location is used to sort stores by distance when you use the Nearby feature'
What changed: Request location at the point of use, use the minimum access level, and write a purpose string that references the specific feature.
Community Solutions · 0
Sign in to share your solution.
More Guideline 5 (Legal) rejections
- Guideline 5 - Legal: Remove Watermark Feature
- Guideline 5.1.1 - Data Collection and Storage: Incomplete Privacy Manifest
- Guideline 5.1.1 - Data Collection and Storage: Missing Purpose Strings
- Guideline 5.1.1 - Data Collection and Storage: Privacy Manifest Missing
- Guideline 5.1.1 - Data Collection and Storage: Privacy Nutrition Label Mismatch
- Guideline 5.1.1 - Data Collection and Storage: Privacy Policy