In this guide
Google Play has the Data safety section. Apple has App Privacy Details, shown as privacy labels on the product page. Both ask what your app collects and why. The common mistake is answering each form from memory, in a hurry, at submission time. The safer way is to build one inventory first and answer both forms from it. This is not legal advice.
What the stores say
Google Play. Per Play Console Help, all developers with published apps must complete the Data safety form, including apps that collect no data, and a privacy policy is required for it. The page says: "You alone are responsible for making complete and accurate declarations in your app's store listing on Google Play." It also says declarations must include data handled by third-party libraries and SDKs, and must stay accurate and complete when your data practices change.
Apple. Per Apple's App Privacy Details page, the information is required to submit new apps and app updates. You must account for the practices of third-party partners whose code you integrate, such as analytics tools, ad networks and SDKs. You must identify all data you or those partners collect, unless it meets every one of Apple's criteria for optional disclosure. You can update your answers at any time, without an app update. A public privacy policy URL is required.
Differences exist in wording and categories, so one answer sheet should be translated into each form, not copied.
Step 1: Build the inventory
Make a sheet with one row per data item.
| Column | Example (illustrative) |
|---|---|
| Data type | Email address |
| Where it comes from | Sign-up form |
| Why you collect it | Account, support |
| Who gets it | Own server; email service provider |
| Required or optional | Required |
| Stored where, how long | Server; until account deletion |
| Linked to the user? | Yes |
| Used for tracking/ads? | No |
| Source in code | Auth module |
Step 2: Find everything, including SDKs
- Go through the code and the dependency list. List each SDK and what it sends.
- Read each SDK provider's own documentation on data; many publish it for exactly this purpose.
- Check analytics events, crash reports, device and advertising identifiers, logs, and anything sent to a backend.
- Include what happens on first launch, before any sign-in.
Step 3: Answer the forms from the sheet
For each row, find the matching question in each store's form. Where the form distinguishes "collected" from "shared", "optional" from "required", or purposes, pick by the sheet, not by what sounds friendlier. If a definition is unclear, read the store's help text for that term.
Step 4: Match the privacy policy and the app
The privacy policy, the in-app behavior and both forms should tell the same story. A policy that says "no data shared" while the app uses an ad SDK is a mismatch that causes trouble.
Step 5: Keep it current
Add a line to your release checklist: "Did we add or change an SDK, a permission or a data flow?" If yes, update the sheet and both forms. Review the sheet before every release that touches data.
Pitfalls
- Forgetting SDK data because "we did not write that code".
- Copying a competitor's answers. Their app is not yours.
- Answering "none" without checking logs and analytics.
- Updating one store and not the other.
- Children in your audience: see apps for children.
For legal questions about what you must disclose or obtain consent for, ask a lawyer or the regulator.
Testers can show you flows where data leaves the app that you forgot about. Get a fresh look from testers.
Related: ASO and launch hub, App Store review guidelines basics, Google Play policy basics.