This one field blocks more first submissions than any other, and not because the document is hard to write. It is because a privacy policy needs somewhere permanent to live, and most developers discover that on the day they submit.
Why both stores insist
Apple has required a privacy policy URL on every App Store listing since 2018, and Google Play requires one in the Play Console for every app. Neither makes an exception for free apps, offline apps, or apps that collect nothing at all. If your app genuinely collects no data, you still need a policy — one that says so.
What counts as a valid URL
- HTTPS. Plain HTTP is rejected.
- No login. A reviewer opens it cold, in a private session, from another country.
- Directly to the policy. Not your homepage with the policy three clicks away.
- Readable on a phone. Reviewers frequently check on the device.
- Permanent. It has to still resolve in two years, or your live app is at risk.
- Not a PDF, and not editable by anyone who opens it. Play says this outright, and adds that the URL must not be geofenced.
- Linked inside the app as well. Both stores want the policy reachable from the app itself, not only from the store listing.
That last point is the one that catches people. A Google Doc link, a Notion page, a GitHub Gist or a file in a repository will often pass review on the day — and then break when sharing settings change, the workspace is reorganised, or the repo is renamed.
| Where people host it | Passes review? | Problem |
|---|---|---|
| Google Doc / Notion page | Usually | Login-gated by some sharing settings; blocked in some regions; URL changes when moved |
| GitHub Pages / Gist | Usually | Breaks on repo rename; reads as untrustworthy to some users |
| Your own website | Yes | Only if you already have one and will keep it |
| A hosted policy page with a stable link | Yes | The intended answer — a URL you control that will not move |
What the document has to cover
A serviceable app privacy policy answers six questions. Length is not a virtue here; the clearer it is, the less trouble it causes.
- What you collect. Be specific and include what your SDKs collect, not only what your own code does — analytics, crash reporting, attribution and ad SDKs all count as collection by you.
- Why. A purpose per data type. “To improve the app” is too vague to be useful.
- Who you share it with. Name the processors: the analytics vendor, the crash reporter, the payment provider.
- How long you keep it, and what happens after.
- How someone deletes it. Apple requires apps with account creation to offer in-app account deletion. Google Play goes further: an in-app path and a web link where deletion can be requested — and the data has to be deleted, not the account frozen.
- How someone withdraws consent. Apple asks for this explicitly, separately from deletion: describe how a user revokes permission they previously gave.
- How to contact you. A working email address, not a form that goes nowhere. Play requires the developer’s name and a privacy point of contact, and that the policy name your app or the entity on your store listing.
If you serve the EU, the UK or California, add the lawful basis for processing and the specific rights those regimes grant. If your app is aimed at children, or handles health or financial data, this is the point at which a generated document stops being enough — get it reviewed.
It has to agree with your privacy labels
Apple’s App Privacy questionnaire and Google’s Data safety form both publish a summary on your listing. Reviewers compare those answers against your policy, and inconsistency between the two is a rejection reason in its own right. Fill in the questionnaire from your actual SDK list, then make sure the policy names the same things.
Generate and host your privacy policy free
Design once with device frames and export every required App Store & Google Play size in one ZIP — watermark-free on the free plan.
Start free — no cardWhile you are here: the support URL
Apple also requires a support URL, and reviewers expect it to resolve to something real. A single page carrying your app’s name, a short description, a contact route and links to your privacy policy and terms satisfies the support URL, the marketing URL and the general expectation that a real app has a website. An app landing page is the cheapest way to produce all three at once, on the same domain as the policy.
What a generated policy is and is not
A generated policy built from an honest description of your app is a reasonable starting document, and it is considerably better than the copy-pasted template most first submissions use. It is not legal advice, and it cannot know anything you did not tell it. Read it before you publish it, and if your app touches regulated data, have a lawyer read it too. The point of automating the document is to free up the attention you should be spending on whether it is accurate.
Apple’s own wording on this is in the App Review Guidelines, section 5.1.