Guideline 5.1.5: Location Services

A Guideline 5.1.5 rejection almost always comes down to the sentence in your Info.plist. The reviewer read your purpose string, could not tell what you do with the user's location or why you need it, and stopped there.

The second most common cause is asking for Always when the app only needs location while it is open. Both are fixable in an afternoon.

How it is usually worded

The header arrives as Guideline 5.1.5 - Legal - Privacy - Location Services, and the body is normally one of:

• "Your app requests access to the user's location but the purpose string does not sufficiently explain the use of the location data."
• "We noticed that your app requests persistent access to the user's location but does not include features that require it."

That second variant is often the awkward one. It can mean the reviewer never reached the feature, which is a discoverability problem as much as a privacy one.

What it actually means

The guideline asks you to use location services only when they are directly relevant to what your app does, to explain the purpose of the collection and use, and to get the user's consent before you collect or transmit location data.

The purpose string is where that explanation happens. It sits inside the system permission dialog, it is the only sentence you get, and Apple treats a vague one as a failure to explain rather than a styling choice.

The purpose strings, by key

Get the key right before you rewrite the sentence, because the wrong key produces a dialog with no text at all, which reads as a crash.

• NSLocationWhenInUseUsageDescription: shown when you request authorisation while the app is in use. Almost every app needs this one.
• NSLocationAlwaysAndWhenInUseUsageDescription: shown when you request Always authorisation. Required if you ever call for always-on access.
• NSLocationTemporaryUsageDescriptionDictionary: for a one-off request for full accuracy when the user has granted approximate location only. Keyed by your own purpose key.

Why it triggers

• The string is a label, not a reason. "This app needs your location." "Location access required." "To improve your experience." Every one of these will be read as no explanation at all.
• Always requested at first launch. Asking for background location before the user has done anything reads as data collection.
• No visible feature. The app asks for location, and the reviewer cannot find a map, a nearby list, a distance, a weather panel or a check-in anywhere. If the only consumer of location is analytics or ad targeting, this rejection is the expected outcome.
• Background location with no user-facing purpose. A location entitlement in the background modes list, no live tracking, no geofence, no route recording. That is a 2.5.4 conversation as well.

How to fix it, in order

1. Rewrite the purpose string to name the feature and the benefit. One sentence, specific, in the user's language. "Your location is used to show fuel stations near you and to sort them by distance." "Your location is used to record the route of a run while you are exercising."
2. Downgrade to When In Use if you can. If nothing in the shipped build needs location while backgrounded, delete the Always key, delete the request, and remove location from UIBackgroundModes. Most 5.1.5 rejections we see disappear here.
3. If you genuinely need Always, earn it in two steps. Request When In Use first, let the user use the feature, then request Always at the moment the feature needs it, with a screen of your own explaining why immediately before the system dialog.
4. Justify the background case in writing. Live turn-by-turn navigation, geofenced reminders, continuous fitness tracking, family location sharing: name the concrete thing. If your background reason is "so data is fresher when they come back", that is not a reason.
5. Add the battery reminder if you use background location. Apple asks for a reminder that continuous background location can decrease battery life. It costs one label and it is explicitly requested.
6. Make the feature reachable in review. Ask for the permission at the point of use, on a screen the reviewer will actually reach, and describe the path in Review Notes with working credentials.
7. Localise every purpose string. In InfoPlist.strings, for every language you ship. An untranslated dialog is a rejection in that locale's review.
8. Audit your SDKs. Stop any of them triggering the prompt before your own request does.

What to send back

Thank you for the review. The purpose string now names the feature: "Your location is used to show charging points near you and sort them by distance." We have removed the Always authorisation request and the location background mode entirely, since the feature only needs location while the app is open. The prompt now appears when the user opens the Nearby tab rather than at launch. To reach it: launch the app, tap Nearby in the tab bar, then tap Use my location. No account is required.

If you need background location and are defending it:

Thank you for the review. The app records running routes, which requires location while the screen is off, so the background location mode is in use. We now request When In Use first, and request Always only when the user starts a workout, after a screen explaining why. The purpose string reads: "Your location is used to record your route while a workout is in progress, including when your screen is locked." The workout screen carries a note that continuous location use can reduce battery life. To reproduce: launch the app, tap Start workout, then tap Begin.

When it is really a different guideline

• A background mode declared with no matching user-facing feature is 2.5.4.
• Missing or inadequate purpose strings for other permissions, or a privacy policy problem, sits under 5.1.1.
• Location data sold or shared beyond what you disclosed is a 5.1.2 data use and sharing issue.

AppSubmit reads the purpose strings out of the build and lists them next to the permissions your app declares, so you read what the user reads before a reviewer does. Opening the Info.plist gets the same list.

Source: Apple, App Store Review Guidelines, 5.1.5 (https://developer.apple.com/app-store/review/guidelines/#location-services)

Related: apple-guideline-2-5-4-background-modes, apple-guideline-5-1-1-v-account-deletion