Guideline 5.1.5

Guideline 5.1.5 - Privacy: Requesting Location Access Without Relevant Feature

Medium RiskEasyTypical Fix: 1-2 hours0 Reports
Also known as:App requests location without a feature that requires itApp requests Always location when When In Use would sufficeLocation access requested for analytics or advertising purposesPurpose string does not adequately explain location usageThird-party SDK requests location not needed by the app

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

01

**Audit location usage** — Determine every place your app or its SDKs request location. Map each request to a specific user-facing feature.


02

**Downgrade to minimum access** — If 'When In Use' suffices, remove the `NSLocationAlwaysAndWhenInUseUsageDescription` key and only keep `NSLocationWhenInUseUsageDescription`. Only request 'Always' for genuine background needs.


03

**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.


04

**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.'


05

**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

  • Request location only at the moment the user needs a location feature
  • Always use the minimum access level (When In Use before Always)
  • Audit SDKs for location access you don't need
  • Write purpose strings that reference the specific feature
  • Example Rejection Email

    From:Apple App Review Team
    Subject:Guideline 5.1.5 - Privacy: Requesting Location Access With
    Guideline 5.1.5 - Legal - Privacy - Location Services Your app requests location access but does not have a feature that requires the user's location, or the level of location access requested exceeds what is necessary. Specifically, your app requests 'Always' location access, but the app's location-based features only require location when the app is in use. Additionally, the purpose string does not adequately explain to users why the app needs location access. Next Steps: Please update your app to: 1. Only request the minimum level of location access needed (When In Use vs. Always). 2. Ensure location access is tied to a clear, user-facing feature. 3. Update the location usage purpose string to clearly explain why the app needs location data.

    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.

    Generate Appeal

    Before & After

    Before — Rejected

    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'

    After — Approved

    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

    View all Guideline 5 rejections