Tolaron RadarBefore you start
App location permissions: what Apple and Google need in January
Google Play wants precise location justified by 27 January 2027, Apple a Shared Location answer from every app by 12 January. What to do now.
Zdeněk Dolák · Founder8 min read
On this page
If your app uses location, both app stores want answers from you in January 2027. Google Play's updated policy on app location permissions becomes mandatory on 27 January, and every Android app that requests precise location must justify it in a Play Console declaration. Apple adds two age rating questions that every app must answer by 12 January, one of them whether the app shares a user's location with other people.
What you need to do depends on how each app uses location. That's usually something your supplier knows better than you do: which location permissions the app requests, for which features, and whether it reads location after the user leaves the app. That inventory shows which declarations you have to submit and whether any screen has to change.
One rule has no date yet. Apps that target Android 17 (API level 37), meaning your developer has set Android 17 as the version the app is built for, must use Android's new location button for one-time or infrequent precise location. Google hasn't announced when Google Play will require apps to target Android 17, so for now that rule applies only once your app's target moves there.
This article summarises the stores' published rules as at 4 November 2026. It's general information, not legal advice.
The dates
Scroll sideways to see every column.
| When | Store | What changes | Which apps |
|---|---|---|---|
| 16 November 2026 | App Store | The age rating questionnaire adds two questions, Shared Location and Dating and Relationships. You answer them with your next update | Every app |
| November 2026 | Google Play | Google says the precise location declaration will open in Play Console | Apps that request precise location |
| 12 January 2027 | App Store | Every app must have answered the new questions | Every app |
| 27 January 2027 | Google Play | The location policy becomes mandatory, with a 30-day extension available in Play Console. Geofencing stops being an approved reason for a foreground service | Apps that use location |
| When your app targets Android 17 | Google Play | One-time precise location must go through the location button. Google hasn't said when Play will require this target | Apps targeting Android 17 |
Google Play: minimum scope and a declaration
Google treats device location as personal and sensitive data, and asks apps to request only the minimum location access their core functionality needs. Its updated location policy, which becomes mandatory on 27 January 2027, spells out what that means. Scope comes down to two questions: does the feature need a precise position or only an approximate one, and does it need location only while the user is in the app (foreground) or also after they leave it (background)?
Approximate location is often enough. Google's own example is a store locator. Approximate location is enough to show the three nearest branches; precise location helps with walking directions. If your branch finder asks for precise location just to sort a list, expect to explain why.
Precise location needs a declaration. Google says every app that requests precise location must complete a declaration in Play Console. It asks two questions:
- Which user-facing features need precise location. You choose from Google's list of use cases, among them search nearby, live tracking, navigation, location tagging and geofencing, which Google calls area-specific actions.
- Why approximate location or the location button isn't enough, and the app needs ongoing precise location.
Google said the form would open in Play Console in November 2026. In April it also said that from 27 October, pre-review checks in Play Console would flag possible location permission problems before an app goes to review.
Never for advertising alone. Google doesn't allow an app to request location solely for advertising or analytics, and device location data may never be sold.
Background location still needs approval. This isn't new. Google counts access as background when it happens after the user closes the app or goes back to the home screen. An app that uses it must be approved through a declaration in Play Console. The declaration describes one location feature, and the approval then covers the whole app. Google also wants a short video of that feature, a prominent disclosure inside the app, a privacy policy both in the app and on its store listing, and the feature described in the store listing. Without that approval, Google says, "app updates may be blocked and your app may be removed from Google Play." Builds in every active release track, open and closed testing included, are subject to review. Google lists delivery tracking for customers, not for drivers, as a feature that should work with foreground location.
Foreground services have tighter rules. Google describes a foreground service as a separate API that lets an app access location while it's minimised. An app that has only while-in-use permission may use one for location only to continue an action the user started, and must stop it as soon as that action is complete. From 27 January, geofencing is no longer an approved use case for a foreground service; Google points developers to its Geofence API instead.
What happens after 27 January. Google says compliance is then mandatory for all apps, a 30-day self-extension will be available in Play Console, and apps in scope that don't comply "are subject to enforcement". Its location guide doesn't spell out what enforcement means for precise location.
The same date brings two other Play changes: broad access to a user's contacts is restricted to apps that need it, and verifying an account through a phone call is no longer an accepted reason to read the call log.
The location button, once you target Android 17
Android's location button is a system button that gives an app precise location for one session only. The access expires when the session is closed. For apps that target Android 17 (API level 37) or higher, Google Play requires it when the app needs precise location only for one-time or infrequent actions the user starts. Google's examples are finding stores or ATMs nearby, sharing a location once, tagging a photo and filling in a delivery address. The app declares this with a flag called onlyForLocationButton.
- The date depends on your target. Google Play has required new apps and updates to target Android 16 (API level 36) since 31 August 2026. It hasn't announced a date for Android 17. Google says it anticipates enforcing the button rule for apps that target Android 17 from late January 2027, and that this timeline "will harden" as it gathers feedback.
- Existing apps aren't exempt. Google's FAQ says all apps that target Android 17, new and existing, must comply, and that updates that don't meet the standards "may be rejected."
- Older phones get the usual prompt. On Android 16 and older, Google's Jetpack library for the button falls back to the standard permission prompt. Google still marks the library as experimental and subject to change.
- It can carry your brand, within limits. Colours, outline, size and shape can be adjusted, and the label is chosen from Google's list. The location icon can't be changed.
- It's for the foreground only. Continuous tracking, navigation and background use stay on the regular permissions, with the declarations above.
Apple: the Shared Location question
From 16 November 2026, the age rating questionnaire in App Store Connect asks whether your app includes:
- Shared Location, which Apple defines as "sharing of real-world location with another person or group."
- Dating and Relationships, which gives an app a minimum age rating of 18+.
You answer when you submit your next update or change the questionnaire. All apps must have answered by 12 January 2027, including apps with no location features.
What counts as sharing. So far, Apple's definition is that one line, and the App Store Connect help pages we checked don't explain it further. On our reading, a branch finder that uses location only to show the nearest branch doesn't share it with another person. An app that shows a courier's position to the customer, or technicians' positions to a dispatcher, quite possibly does. App Store Connect shows examples for each age rating category, so read them when the question appears.
What it does to the rating. Apple says Shared Location "may not have an impact" on an app's minimum age rating in some regions. In Brazil, local rules require an A16 rating for it. If your app is available in Brazil, check the rating it will show there.
What happens if you don't answer. Apple's announcement doesn't say. When Apple last added age rating questions, due on 31 January 2026, it said that answering on time would avoid "an interruption when submitting your app updates". Whether the same applies this time, Apple hasn't said, so we wouldn't leave the answer until the deadline.
Who can answer. In App Store Connect, only the Account Holder, Admin, App Manager or Marketing roles can set the age rating. Agree the answer with your supplier, and make sure someone with one of those roles enters it. If nobody at your company has one, who owns your app explains why the accounts should be in your name.
Apple's current App Review Guidelines also apply. Guideline 5.1.5 asks apps to use location only when it is directly relevant to their features, to obtain consent before using it, and to explain the purpose in the app.
What to do now
- Ask your supplier for a location inventory of each Android and iOS app: every location permission it requests, precise or approximate, foreground or background, and the feature each one serves. Include third-party SDKs; Google asks developers to confirm that their libraries comply too. On iOS, ask to see the text that explains why the app wants location.
- Move what you can to approximate location. Store and branch finders are Google's own example.
- Write the precise location justification now. For each feature that keeps precise location, name Google's use case and explain in a sentence or two why approximate location or the location button isn't enough. Check Play Console for the declaration and submit it once it's there, well before 27 January.
- Check background and foreground service use. If the app tracks drivers or technicians in the background, confirm that its approval matches what the app does today. If it uses geofencing through a foreground service, plan the move to the Geofence API.
- Agree your Shared Location answer before your next iOS update after 16 November, and have someone with an Admin, App Manager or Marketing role submit it by 12 January.
- Ask for the Android 17 plan. Which API level does each app target today, when will it move to Android 17, and which one-time location actions will then need the location button?
If you want a second opinion on what your app's location features need before January, the mobile app development page describes how we work. A short description through the contact page is enough to start.
Sources
Checked on 4 November 2026.
- Google Play Console Help: Policy announcement: October 29, 2026
- Google Play Console Help: Policy announcement: April 15, 2026
- Google Play Console Help: Preview: Permissions and APIs that Access Sensitive Information
- Google Play Console Help: Minimum Scope: Foreground Location Access and the Location Button
- Google Play Console Help: Understanding location in the background permissions
- Google Play Console Help: Policy Deadlines
- Google Play Console Help: Target API level requirements for Google Play apps
- Android Developers: Request session-based location access with the location button
- Android Developers Blog, 15 April 2026: Boosting user privacy and business protection with updated Play policies
- Apple Developer News, 2 November 2026: Upcoming: New age rating content descriptors in App Store Connect
- Apple Developer: Upcoming requirements
- App Store Connect Help: Set an app age rating
- Apple Developer: App Review Guidelines

Zdeněk DolákFounder of Tolaron. Spent the years before it building payment software.
