The Google Play data safety form asks two questions, and collecting is not the same as sharing.
Answer the Google Play data safety form as two questions per data type, not one: what your app transmits off the device, and what it then hands to a third party. Google asks those separately, and the sharing half is where most forms go wrong. Every developer with an app published on Google Play has to complete it, including apps on closed, open and production testing tracks, and including apps that collect nothing at all. Apps that are active only on an internal testing track are exempt. If you are working through publishing to Google Play for the first time, do the form early, because it is reviewed as part of app review and a bad answer holds the release.
Everything below comes from Google Play Console Help and Apple Developer, both opened on 3 October 2026. Where the two stores ask different questions, this page says so rather than describing one and implying the other. Where Google does not publish an answer, it says that too.
Check a case against Google's definitionsThe short version
One form, one package name, and the sum of every version on the store.
The data safety section is a single global declaration per package name. Google states that it is agnostic to app version, region and user age, and that your section describes the sum of your collection and sharing across every version currently distributed on Google Play. So the form is not a description of your latest build. It is a description of all of them.
That one rule settles most of the arguments people have while filling it in. If any version, anywhere, in any region, requires a data type, you declare that type, and you declare it as required rather than optional. Version-specific detail belongs in the About this app section instead.
The five steps, and the two answers that cost the most
Google's current help article puts the form on the App content page in Play Console: under Data safety, select Start. That is the whole location Google publishes, so treat any longer menu path you have read elsewhere as someone's console from an older year. It names five steps in order, Overview, Data collection and security, Data types, Data usage and handling, and a store listing preview before you submit. Save as draft holds your place, Back lets you amend, and Discard changes means starting over. Buttons near the top right of the form export your answers to a CSV and import them back, and an import overwrites whatever is already in the form. A privacy policy is required before the form can be completed and your information shown to users.
Step two is two questions and both are claims about your infrastructure. First, whether all of the user data your app collects is encrypted in transit. Read that literally, because Google says you can only declare encryption in transit if it applies to all user data that your app, including every SDK and library in it, collects and transmits off the device. One plain HTTP call to one legacy endpoint makes the honest answer no. Second, whether you provide a way for users to request deletion of their data. That one is looser: Google prescribes no particular mechanism and accepts in-app features, contact forms or a dedicated email alias, and you may also select it if you automatically delete or anonymise collected data within 90 days of collection. Both questions sit squarely in the territory of app security basics, and neither is a box you want to tick optimistically.
There is a second deletion requirement that people confuse with that badge. Google Play Console Help documents data deletion questions inside the same data safety form, and states that if your app allows users to create an account from within the app, its User Data policy requires both an in-app path to delete the account and its associated data, and a web link where users can request the same deletion. An app with sign-up and only an in-app toggle has met half of it.
Then it is reviewed. Google reviews the form as part of the app review process, and is blunt about the limits of that: the review is not designed to verify the accuracy or completeness of your declarations, and you alone are responsible for them. Where Google does find a discrepancy between your app behaviour and your declaration it requires a fix, and apps that do not become compliant face blocked updates or removal. On timing it will only say that certain apps are subject to expanded reviews, which may take up to 7 days or longer in exceptional cases. It publishes no typical turnaround for a data safety form on its own.
Apple asks a different third question
Do not translate your Play answers into Apple's form. Google says so itself: asked how much iOS work can be reused, its help article answers that the data safety form asks for additional and different information, and that the taxonomy and framework may differ materially from those used in other app stores. Apple's questions live in App Store Connect and produce the app store privacy nutrition labels on your product page.
The structural difference is the one to hold on to. Apple has no separate sharing question. For each data type you declare the purposes it serves, whether it is linked to the user's identity, and whether it is used to track them, and tracking has a tight published meaning: linking data collected from your app about a user or device with third-party data for targeted advertising or advertising measurement, or sharing it with a data broker. So a vendor who only works for you is outside Apple's tracking definition and outside Google's sharing definition, but by different routes, and the two answers are not interchangeable.
The definitions drift in ways that change individual cells. Apple's collect covers transmitting data off the device and holding it in readable form for longer than it takes to service the request, which folds Google's ephemeral exception into the definition itself rather than asking about it. Precise location splits at a different place: Apple draws the line at a latitude and longitude with three or more decimal places, Google at an area of 3 square kilometres. Apple publishes an optional disclosure carve-out with four conditions that must all hold, plus narrower ones for regulated financial services and approved health research, and Google publishes no equivalent for infrequent, user-initiated submissions. Apple also lets you update your answers at any time without submitting an app update. Google's form goes back through app review.
They agree on two things worth saying out loud. Data processed only on the device is not collected on either store. And third-party code you shipped but did not write is yours to declare on both. Neither store will accept not knowing what an SDK does as an answer.
Apple Developer, App privacy details on the App Store (read 3 October 2026)
What actually gets a form sent back
The failures are repeatable and dull. An SDK nobody audited. A crash reporter quietly sending a device identifier, which is a declared data type, not plumbing. An encryption-in-transit yes that one old endpoint makes false. A form that describes the build you are shipping this week instead of every build on the store. One thing that is not a failure: a permission sitting in your manifest with no matching declaration. Google states you do not need to declare collection or sharing unless the data is actually collected or shared, and separately explains that the permissions list on your listing is built from install-time permissions in the manifest while the data safety section describes what you collect and share. They are two different surfaces.
Nested data types catch people as well. Google's guidance is that if you purposefully collect one data type while collecting another, you disclose both. Collecting contacts that include email addresses means declaring both. Deriving ethnicity from user photos means declaring that too. IP addresses are the sharpest version of this, because neither store has an IP address data type. Google says to disclose your collection, use and sharing of IP addresses based on your particular usage, and that approximate location inferred from an IP address must still be disclosed as approximate location. Apple spells the options out: declare the relevant data types based on how you use the IP address, such as precise location, coarse location, device ID or diagnostics.
One honest gap. Apple names who may enter privacy answers: Account Holders, Admins and App Managers. Google's data safety article says nothing about which Play Console role can open, edit or submit the form, so if you need to know who on your team can touch it, read the permission in your own console rather than trusting any page, including this one. The related question inside your own app, who can see what, is a separate exercise with a longer answer.
Where the two stores genuinely differ
| The question | Google Play data safety form | Apple App Store privacy questions | Same exercise? |
|---|---|---|---|
| Is third-party sharing asked on its own | Yes, per data type: collected, shared or both, with separate purposes for each | No separate sharing question; asks if data is linked to the user and used to track them | No |
| Where precise location starts | An area smaller than 3 square kilometres | A latitude and longitude with three or more decimal places | No |
| Changing your answers later | The submitted form is reviewed as part of app review | Answers can be updated at any time with no app update | No |
| Data processed only on the device | Not declared as collected | Not collected, so not disclosed | Yes |
| Who may fill the form in | Not stated in the data safety help article | Account Holders, Admins and App Managers | Not published for Play |
Answering the form for an app you generated
The form is a description of your architecture, so the cheapest way to answer it is to write that architecture down first. List every endpoint the app talks to, every SDK you shipped, and for each one what leaves the phone and who can read it once it arrives. Most of the form falls out of that list, and the parts that do not are usually the parts you did not know about.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, then uploads to TestFlight and publishes to Google Play internal testing. It is $25 a month and there is no free plan. The default matters here: a new app is local-first, keeping its data on the phone with no accounts and no server, which on Google's published definition is not collection at all. Newly Backend gets added only when the app needs accounts, shared data, syncing or payments, and that is the moment your answers change, because sign-in, an API service, a Postgres database and file storage all sit off the device.
Two later additions carry specific answers. A paywall arrives through a Connect RevenueCat card, and purchase history plus a user identifier start crossing the network. Push notifications arrive through a OneSignal card, and a device identifier goes with them. Both are third-party code inside your app, so both are yours to declare. And watch where builds land. Under Google's current rule an app active only on internal testing is exempt from the form, which means the day you promote a build to closed, open or production testing is the day the form becomes a blocker rather than a chore.
Questions people ask about the data safety form
On the App content page. Under Data safety, select Start. Google's help article, read on 3 October 2026, describes five steps: Overview, Data collection and security, Data types, Data usage and handling, and a store listing preview before you submit. You can save the form as a draft at any point, and export or import your answers as a CSV from buttons near the top right.
Write down what leaves the phone, then answer the form
List every endpoint and every SDK in your app, mark what each one sends off the device and who can read it, and the collected, shared and security answers write themselves.
Start building