Every app on the App Store and Google Play needs a privacy policy link, including apps that collect nothing at all. It is one of the most common reasons a first submission is sent back — not because the app does anything wrong with data, but because the policy is missing, unreachable, or contradicts what the developer declared elsewhere in the console.
This is a practical guide to what the policy needs to contain and how to keep it consistent with the other privacy disclosures both stores ask for. It is not legal advice; if your app handles health, financial or children's data, have a lawyer review it.
Three disclosures, one story
Each store asks you to describe your data practices in more than one place, and reviewers compare them:
- The privacy policy itself — a public web page you link from the listing.
- Apple's App Privacy details ("privacy nutrition labels") in App Store Connect, which list the data types you collect, whether each is linked to the user, and whether it is used for tracking.
- Google Play's Data safety section in Play Console, which asks what data is collected and shared, why, and whether it is encrypted in transit and can be deleted.
The single most important rule: all three must tell the same story. If your Data safety form says you collect no location data and your policy mentions location, or an SDK in your app sends device identifiers you didn't declare, expect a rejection or a policy warning.
What the policy must cover
Regardless of jurisdiction, a store-ready policy answers these questions in plain language:
- Who you are and how to contact you about privacy.
- What you collect — account details, content users create, device and usage data, location, contacts, photos, payment information — and whether each is required or optional.
- Why you collect each item. "To provide the service" is not enough on its own for everything; say what the data does.
- Who you share it with, including the SDKs and services in your app: analytics, crash reporting, advertising, authentication, payments, AI providers.
- How long you keep it, and what happens when a user deletes their account.
- How users can access, export or delete their data. Both stores now expect a way to request account deletion for apps that let users create accounts.
- Children — whether the app is directed at children, and what that changes.
- How you'll announce changes to the policy.
The SDK problem
Most privacy mismatches don't come from code you wrote. They come from SDKs you added: an analytics library, an ad network, a crash reporter, a social login. Each collects data on its own terms, and that collection is yours to disclose.
Before writing the policy:
- List every third-party SDK in the release build, not just the ones you remember adding.
- Read each SDK's own data-collection documentation. Most major SDKs publish what to declare in Apple's labels and Google's Data safety form.
- Include them by category in your policy — "crash reporting", "advertising" — and name the provider where it matters to users.
Repeat this every release. A new SDK added for one feature can quietly make last version's policy inaccurate.
Hosting the policy
- It must be a public URL that loads without signing in, on any device. - It must be about this app. A generic company policy that never mentions the app or its data, or a template with placeholders left in, is a common rejection. - Keep the URL stable. It is stored in both consoles; moving it means updating every listing. - Date it. A visible "last updated" line shows reviewers and users that it is maintained.
Common reasons for rejection
- The privacy policy link is missing, broken, or behind a login. - The policy doesn't mention data that the app or one of its SDKs clearly collects. - The Data safety form or App Privacy labels contradict the policy. - The app lets users create accounts but offers no way to request account deletion. - The policy is a template with placeholder text still in it.
Keeping it current
Treat the policy as part of each release rather than a one-time document. Whenever you add an SDK, a permission, or a feature that touches personal data, update the policy, the App Privacy details and the Data safety form together — in that order, so the public policy is never behind what the consoles say.
A short, specific, current policy will pass review more reliably than a long generic one, and it is far more useful to the people actually reading it.