Short answer
Tie location to one visible feature, request it when the user starts that feature, and ask for When In Use unless the feature truly needs Always. Write a purpose string that names the feature. Remove location from SDKs that don’t need it, then resubmit and explain the change in App Review notes.
Rather not fix it yourself? App Fix Ticket starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.
What triggers 5.1.5, and the fix
01
No feature in the app needs location
“Use Location Services in your app only when it is directly relevant to the features and services provided by the app.” Apple, Guideline 5.1.5
A location prompt in an app with no map, nearby search or delivery feature looks like data collection. Remove the request, or build the feature that uses it.
02
The app asks at launch
“Ensure that you notify and obtain consent before collecting, transmitting, or using location data.” Apple, Guideline 5.1.5
A prompt on the first screen gives the user no context. Ask when the user taps the feature that needs location, after a short in-app explanation.
03
The purpose string is vague
“If your app uses Location Services, be sure to explain the purpose in your app; refer to the Human Interface Guidelines for best practices for doing so.” Apple, Guideline 5.1.5
Text like “This app needs your location” doesn’t say why. Name the feature and the benefit, for example finding stores near the user, in NSLocationWhenInUseUsageDescription.
<key>NSLocationWhenInUseUsageDescription</key> <string>Your location is used to show stores near you on the map.</string>04
The app asks for Always
Also check: Always access needs a feature that works in the background, such as trip tracking. If the feature works while the app is open, ask for When In Use only, and check that no SDK requests more.
Checked against the vendor’s docs on : App Store Review Guidelines: 5.1.5 Location Services; Apple: App Review (replying and appeals).
Rather hand it over?
Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.
Resubmit before Apple’s holiday slowdown
Pay for the Diagnosis and send the rejection and access to the app by (US Eastern). The Diagnosis is back by . Pay for the Fix that day and it arrives as a pull request by , in time to build and resubmit before .
In past years Apple said reviews may take longer around the holidays: December 20 to 26 in 2024 (opens in a new tab), December 22 to 27 in 2023 (opens in a new tab), December 23 to 27 in 2022 (opens in a new tab). Apple hasn’t posted its 2026 dates yet (checked ). Approval stays Apple’s decision.
“Very responsive, attentive to fixing bugs, and completed the project as needed! Thank you!”
Related: App Store Guideline 5.1.1 (data collection) · App Store Guideline 5.1.2 (data use and sharing) · Google Play background location permission · App Store Guideline 2.5.1