Guideline 5.1.5 — location services
Two patterns get rejected under 5.1.5: demanding location before the user has seen why, and breaking when they decline.
The guideline requires that location use be directly relevant to features the app provides, that consent comes first, and that the app remains usable without it. An app that shows the system location prompt on the first screen after launch is asking for a decision the user has no basis to make, and an app that shows a blank screen afterwards has answered the guideline's question for the reviewer.
The fix is staging: a plain-language primer, then When In Use, then let the user experience the feature, then escalate to Always with a rationale they can see the point of. And a genuine degraded mode, because the reviewer will decline the permission and watch what happens.
The staging pattern
1. Primer screen, before any system prompt. Your own UI, your own words, explaining what the app does with location and what the user gets. This is the only screen where you get to make the case, because the system dialog is not yours to write beyond one line.
"MileTruth detects your drive sessions automatically so you never lose a trip. To do that it needs location access, including when the app is closed. Nothing is uploaded until you choose to export."
2. Request When In Use. Not Always. The lower permission first.
3. Let them use the feature. One completed session, one visible result, one moment where the thing worked.
4. Escalate to Always, with a reason tied to what they just saw. Now the request is legible: "you started that session manually. Turn on Always and the next one records itself." Apple's model expects this escalation rather than an up-front demand.
5. Degrade gracefully if declined at any step. Manual start still works. The app still opens. Nothing is blank and nothing is modal.
The degraded mode is the part reviewers actually test
Assume a reviewer will decline the permission and keep going. What they see next is the whole of 5.1.5 for your app.
| If they decline | What the reviewer concludes |
|---|---|
| Blank screen | Non-functional without location. Rejected. |
| Blocking modal that cannot be dismissed | Same, worse. |
| Crash | Also a Guideline 2.1 completeness problem. |
| A usable app with one feature offering a manual alternative | Fine. |
Build the declined path deliberately, and test it on a real device with the permission actually denied, not in a simulator with it granted. It takes ten minutes and it is the single highest-value pre-submission test for a location app.
Background location is a second, harder conversation
If you need Always, you are also declaring the location background mode, which brings Guideline 2.5.4 into it: Apple rejects apps declaring that mode without a legitimate persistent-location feature. Two things follow.
Make the feature reachable and visible. A reviewer should be able to find the screen that depends on background location within a minute.
Say it in review notes. Name the feature, say where it is, explain why it needs to run in the background, and state the degraded behaviour. A reviewer who has to guess will guess conservatively. Review notes that work. · Guideline 2.5.4 in detail.
Android is a separate evidence bundle
ACCESS_BACKGROUND_LOCATION requires a Permissions Declaration in Play Console: a written justification that background location is core functionality, plus a demonstration video showing the feature in use. Google's stated expectation is that you use the least invasive option that satisfies the use case, so a background request a foreground-only flow could satisfy is likely to be refused.
Android also stages the request differently: you must request foreground location first, and the background request is a separate user action, with a rationale dialog required before it.
Two reviews, two evidence bundles, one shared prerequisite: the feature has to be real and visible.
The React Native and Expo specifics
Write your own purpose strings. Plugin defaults are generic, and a generic string is both a worse prompt and a weaker answer to a reviewer.
["expo-location", {
"locationWhenInUsePermission": "Used to detect your drive sessions while you are working.",
"locationAlwaysAndWhenInUsePermission": "Used to record trips automatically, including when the app is closed, so you never lose a deduction.",
"isAndroidBackgroundLocationEnabled": true
}]Set them in app config, not in ios/. Continuous native generation regenerates the native projects on every prebuild, so a hand edit works locally and vanishes on the build server. Auditing what your plugins added.
Check what actually shipped. Read the generated Info.plist and the merged AndroidManifest.xml, not the repository.
What a pre-submission check catches
Location purpose strings present with no location API call anywhere in the codebase. UIBackgroundModes declaring location with no persistent-location feature. ACCESS_BACKGROUND_LOCATION in the merged manifest with no Play Permissions Declaration prepared. Purpose strings still carrying a plugin's default text. Fixes applied in a generated directory.
All deterministic, all local, all findable before a build. That is what shipcheck scans for. What it cannot tell you is whether your degraded mode is good enough, because that is a person's judgement. What it checks.
Questions and answers
What is App Store Guideline 5.1.5?
Location Services. It requires that location use be directly relevant to features the app provides, that you get the user's consent before collecting it, and that the app remain usable when the user declines. Apps that demand location at first launch or break without it are rejected under it.
Can an app require location to function?
An app whose core feature genuinely needs location can require it for that feature, but it should degrade gracefully rather than becoming unusable, and it should not demand the permission before the user has seen why. Non-functional-without-location is the specific pattern the guideline targets.
How should you request Always location on iOS?
In stages. Show a plain-language primer screen explaining what the app does with location, request When In Use first, let the user experience the feature, then escalate to Always with a rationale when there is a reason they can see. Demanding Always at first launch is a rejection pattern.
Does Android need anything different for background location?
Yes, and it is a bigger hurdle. ACCESS_BACKGROUND_LOCATION requires a Permissions Declaration in Play Console including a written justification and a demonstration video showing the feature in use, and Google expects the least invasive option that satisfies the use case.
What happens if a user declines location?
The app should still open and still do something useful. A blank screen, a blocking modal or a crash after a declined permission is the clearest version of the failure this guideline describes.
shipcheck. “Guideline 5.1.5 — location services.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/guideline-5-1-5-location-services/