Always location gets rejected for one sentence and one form you did not fill in.
A rejection for Always location is a writing problem on both stores. On iOS, App Review reads the purpose string in your Info.plist and measures it against guideline 5.1.1(ii), which says to ensure your purpose strings clearly and completely describe your use of the data. Guideline 5.1.5 Location Services adds that you may use Location Services only when it is directly relevant to the features the app provides. On Google Play, background location is approved through a declaration process in Play Console, and the form asks you to name one feature that cannot work without it. Every field name and requirement below comes from Apple's and Google's own pages, read on 21 October 2026. The App Store Review Guidelines carried a last updated date of 16 October 2026 when read. People usually meet this page after a first rejection, so it is worth knowing the app store rejection rates your submission sits inside.
What follows is the exact wording Apple calls insufficient, the two Info.plist keys an Always app needs rather than the one most people add, where the Google form lives and what it asks, and the sentence Google wants on your disclosure screen. Then the part that catches people twice: you can ask for Always once, and then never again.
Start hereThe short version
Name the feature, in the prompt and on the form.
Both stores are asking the same question in two different places. Apple asks it inside your binary, through the usage description strings that appear in the permission prompt. Google asks it inside Play Console, through a declaration form, a video and a disclosure screen your app has to show. Neither store is checking whether your background code works. The question is whether a person could read your reason and agree with it.
The short answer to the Apple half: no template is published, no character count is published, and a string that only restates the resource name is rejected. The short answer to the Google half: yes, there is a form, it lives on the App content page, and it evaluates one feature only. Everything else on this page is detail hanging off those two facts.
What does Apple require in an Always location purpose string?
One sentence that names what the app does with the location. The normative text is short. Guideline 5.1.1(ii) Permission says to ensure your purpose strings clearly and completely describe your use of the data. Guideline 5.1.5 Location Services says to use Location Services only when it is directly relevant to the features and services the app provides, to notify and obtain consent before collecting, transmitting or using location data, and to explain the purpose in your app. That is the whole published requirement for content. There is no required format and no word limit.
Apple does publish a longer help page, 5.1.1(ii) Write clear purpose strings, in App Review Help. It is worth reading because it gives the failing example rather than describing it. A purpose string that only restates the name of the resource, or promises a general benefit without saying what your app actually does, does not meet the requirement. The page prints two insufficient strings. One is To use location. The other is a sentence about providing a better experience. Set against them is a clear example about determining the recommended route to your destination and providing turn by turn directions. The difference is that the second one names a feature.
The same page lists what to do. Name the specific feature or outcome the data makes possible. Write a separate purpose string for every protected resource your app requests. Give a concrete example of what your app does with the data. Write one brief, complete sentence in active voice and sentence case, ending with a period. And what not to do: no vague benefit, no passive construction that hides who gets the data, no restating the resource name, and no marketing copy or feature list stuffed into the prompt. The article publishes no character count anywhere in its body, minimum or maximum, read on 21 October 2026. If you have seen a number quoted for purpose string length, it did not come from there.
Two mechanical requirements sit underneath the writing, and they are where Always differs from When In Use. Apple's Core Location article, Requesting authorization to use location services, publishes a table of usage keys. NSLocationWhenInUseUsageDescription is required when the app requests When In Use or Always. NSLocationAlwaysAndWhenInUseUsageDescription is required when the app requests Always. An Always app therefore needs both keys and both sentences, and the same article warns that authorization requests fail immediately if the required keys are not present. The second requirement is a limit on asking. If your app already has When In Use authorization you can make a separate request for Always later, but you can make that request only once. There is no second prompt to fall back on.
Apple, App Store Review Guidelines, page last updated 16 October 2026, read 21 October 2026
Does Google Play need a declaration form for background location?
Yes, and it is called the Permissions Declaration Form. Play Console Help gives the path: go to the App content page, click Start in the Sensitive app permissions section, then click Start within Location permissions. If the console shows you other forms first, such as App Access Rights or the Authority Declaration Form, those come first and are part of preparing the app for review. If the prompt is not there at all, the trigger has not fired. A bundle targeting Android 10 or newer, SDK level 29 or higher, with ACCESS_BACKGROUND_LOCATION in the manifest, gets directed to the location usage details. A bundle targeting Android 9 or older, SDK level 28 or lower, with either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, first has to state an intention to access location in the background.
The form is not the only deliverable. Google lists four items for background location: the Permissions Declaration Form, a video demonstration, a prominent in-app disclosure, and a privacy policy both in your app and on its store listing page. The form itself turns on two questions. What is the main purpose of your app, and why does your app need access to location in the background. The second answer has a hard constraint on it. Tell Google about one location based feature only, explain why it cannot be implemented without background access, and keep it related to the main purpose of the app. Google can evaluate one feature at a time, and says plainly that including several will result in rejection. Approval, when it comes, covers the entire app rather than that one feature.
The bar is core functionality, which Google defines as the main purpose of the app, a set of important features without which the app is broken or rendered unusable. Those features also have to be documented and promoted in the app description. Google splits user benefit into two tiers in the review criteria. Physical safety, perceived safety and health or fitness count as significant. Ads, offerings, analytics, personalisation, entertainment and convenience count as minimal. Requesting location for advertising or analytics alone is called out as something you should never do. Without approval, Google says app updates may be blocked and the app may be removed from Google Play, and the review covers bundles on every active release track, closed and open tracks included.
The video has its own spec, and it is the item most often sent back. It must show the feature being activated from the background, the prominent in-app disclosure dialog shown to users, and the runtime prompt, along with the steps a person takes to reach and enable the feature. Aim for 30 seconds or less. A YouTube link is preferred and a Google Drive link to an MP4 or similar is accepted. It has to be recorded on an Android device, and Google says in as many words not to submit a video of your iOS app. Where the feature has no user-facing interface while background location is live, say so in the declaration and show the effects as far as you can.
Check yours
Does your feature actually need Always
Pick the one feature you would put on the declaration form. The verdicts are Google's own worked examples, taken from its background location article.
Needs location when the app is closed
Info.plist: Both keys, When In Use and Always
Google Play: Declaration form, video, in-app disclosure
Why: Google lists perceived safety as a significant user benefit, and uses child safety geo-fencing as its own worked example
Google reviews each app against its own declared core functionality, so a listed foreground feature is not an automatic rejection. It does raise the odds.
What has to appear on the disclosure screen inside the app?
Google sets the content of this one, not just its existence, and the rules are specific enough to check against your own copy. The language must include the term location. It must indicate the nature of the background use by carrying one of four phrases: background, when the app is closed, always in use, or when the app is not in use. It must list all of the app features that use location in the background. And if you extend the permitted usage to ads, it must say so, with wording such as used to provide ads or support advertising.
Google also publishes the sentence it recommends, as a fill in the blank. This app collects location data to enable the named features even when the app is closed or not in use. Its own examples name a fitness app collecting location to enable fitness tracking, and an app collecting location to enable tracking and delivery of local weather alerts. Both end with the same clause about the app being closed or not in use. Copying that structure and swapping in your feature names is the cheapest way through this requirement.
Placement is scored as strictly as wording. The disclosure has to be within the app itself as well as in the app description and on the website. It has to be displayed in the normal usage of the app rather than behind a menu or a settings screen. It has to describe the data being accessed and explain how that data will be used or shared. It cannot live only in a privacy policy or terms of service, and it cannot be bundled with other disclosures that have nothing to do with personal or sensitive data. One relief: it needs no explicit consent, no accept button and no I understand, because the runtime prompt follows immediately after it. People can close it or swipe it away.
The privacy policy has its own checklist on the same page. It has to sit on an active URL, with no PDFs, be non-editable, be linked both on the store listing and inside the app, be labelled clearly as the privacy policy in the title or URL and in the body, name the entity or the app as it appears on the Play listing, and specifically reference location data and how the app uses it. A generic policy that never says the word location fails this, which is the quiet reason some second submissions come back.
Google Play Console Help, understanding location in the background permissions, read 21 October 2026
Why does the same rejection come back after you fix the string?
Because the string is often not the only thing being judged. Guideline 5.1.1(iii) Data Minimization says apps should only request access to data relevant to the core functionality and should only collect what the task needs. Guideline 5.1.1(iv) Access says apps must respect the user's permission settings and must not manipulate, trick or force people into consenting to unnecessary data access, and it uses location for its own illustration: where a user declines to share Location, offer the ability to enter an address manually. An app that falls over when the person picks When In Use is failing that clause, no matter how good the sentence in the prompt was.
The second repeat cause is a reviewer who never saw the feature work. Apple's help page on purpose strings also answers the SDK question directly: you are responsible for everything in your app, including third party SDKs, and an SDK can reference location APIs without you realising. If the app has a valid reason, define the purpose string. If it does not, remove the references from the binary. So a map or ads SDK you never configured can put a location prompt in front of a reviewer with nothing to justify it. Say where the feature lives and how to reach it in your app store review notes, and if the feature sits behind a login, remember the app store demo account requirement applies to it like any other gated screen.
On the Android side the repeat usually comes from a build you forgot about. Google reviews bundles across all active release tracks, so an old closed-track build still carrying ACCESS_BACKGROUND_LOCATION keeps the violation alive. Play Console lists the affected bundles under Policy, App content, Sensitive app permissions, Show summary, and App bundle explorer shows which versions are still active. A compliant release has to roll out to 100 percent and fully deactivate the noncompliant ones. Material changes later can trigger another review, and Google asks for a new declaration form whenever the background location feature itself changes.
There is also a plain mechanical difference worth planning for. Android's own developer documentation on requesting background location notes that from Android 11, API level 30, the system permission dialog no longer offers Allow all the time, so a person has to enable background access on a settings page. Android suggests an educational screen first, and reading the real button label with getBackgroundPermissionOptionLabel so that the text you quote matches the user's language. If the Apple rejection is the one you are holding, the next step is a rewrite and a resubmission rather than an appeal app store rejection route, because a purpose string is a fact about your binary rather than a judgement call.
Apple, App Store Review Guidelines, sections 5.1.1 and 5.1.5, read 21 October 2026
What each store wants before it approves background location
The two processes look alike from a distance and almost nothing is interchangeable. Every row below is from the two pages cited on this page, read on 21 October 2026.
| What is asked for | App Store, Always location | Google Play, background location | Same on both |
|---|---|---|---|
| A written justification a reviewer reads | The purpose string, shipped inside the build | The Permissions Declaration Form, filled in the console | No |
| A form in the developer console | No | Yes | No |
| A video of the feature working | No | Yes, 30 seconds or less, on an Android device | No |
| Prescribed wording | No template published, best practices only | Must contain location plus one of four named phrases | No |
| Approval hangs on one named feature | No | Yes | No |
| A privacy policy in the app and on the listing | Yes | Yes | Yes |
| Getting it wrong can block updates | Yes | Yes | Yes |
Where this lands if a builder generated your app
There is a specific trap for generated React Native and Expo apps, and it is visible in the documentation. The expo-location config plugin sets the iOS purpose strings for you, and its published default for locationAlwaysAndWhenInUsePermission is Allow $(PRODUCT_NAME) to use your location. That is a restatement of the resource with no feature named, which is the shape Apple's own help page lists as insufficient. Nothing is broken, and the build will upload. A default string is not an answer to the question App Review is asking. The Android half has a kinder default: isAndroidBackgroundLocationEnabled is false, so ACCESS_BACKGROUND_LOCATION is not in the manifest until somebody turns it on. Expo also notes that this permission does nothing on its own, because it needs coarse or fine location alongside it. Checked against the expo-location reference for SDK 58 on 21 October 2026, in both the Markdown and the rendered page.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync, so the Info.plist keys and the app config are yours to edit. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. Newly costs $25 a month and there is no free tier. What it does not do is press submit on the App Store, because guideline 4.2.6 requires apps made from an app generation service to be submitted by the provider of the app content, which is you.
The practical consequence is that two small edits belong on your launch list, not the builder's. Replace the default purpose strings with one sentence each that names the feature. Then decide whether you need Always at all, because the honest answer for most generated apps is When In Use, and the When In Use path skips the Google declaration, the video and the disclosure screen entirely. Ask for background location only when the app is broken without it.
Questions people ask about Always location rejections
Usually for the writing, not the code. On iOS, App Review reads the purpose string in your Info.plist against guideline 5.1.1(ii), which says to ensure your purpose strings clearly and completely describe your use of the data. Apple's App Review Help page on purpose strings gives its own insufficient example, and it is the string most apps ship: 'To use location.' Guideline 5.1.5 Location Services adds that you may use Location Services only when it is directly relevant to the features the app provides. On Google Play the usual cause is the background location declaration, where approval depends on background access being required for the core functionality of the app. Both pages read on 21 October 2026.
Describe the app, then write the sentence yourself
Write down the one feature that stops working when the app is closed. If you cannot name it in a sentence, you do not need Always, and the whole declaration process goes away. If you can name it, you have already written both the purpose string and the answer on Google's form.
Start building