Quick answer: Both stores require a publicly reachable privacy policy URL entered on the store listing — App Store Connect will not let you submit without one, and Google Play requires one for every app. It must be a live page anyone can open without logging in, it must be specific to your app, and it must match what your app actually does. Apple additionally makes you complete the App Privacy label, declaring each data type you collect — and analytics or crash-reporting SDKs count as collection. Host the page on your own domain, not inside a document-sharing link.
| Requirement | Apple | Google Play |
|---|---|---|
| Privacy policy URL on the listing | Required for all apps | Required for all apps |
| Support URL | Required | Contact details required |
| Per-data-type declaration | App Privacy label | Data safety section |
| Third-party SDK data counts | Yes | Yes |
| Page must be publicly accessible | Yes | Yes |
There is a moment in most first launches where the build is done, the screenshots are ready, and App Store Connect refuses to accept the submission because one field is empty. The field is Privacy Policy URL, and it does not want a promise — it wants a page that already exists on the internet.
Both stores require it. Neither of them is flexible.
Apple requires a privacy policy URL in App Store Connect for every app, without exception. Separately, it requires a support URL — a different field, pointing at a page where a user can get help. And separately again, it requires you to complete the App Privacy label: a per-data-type declaration that becomes the "App Privacy" section users see on your store page.
Google Play requires a privacy policy URL on the store listing for all apps, and a completed Data safety section declaring what you collect and share.
None of these are satisfied by a paragraph inside your app. They are listing fields, and they want URLs.
The requirement that surprises people: your SDKs count
You can write "we do not collect any personal data" in perfect good faith and still be wrong, because the question is not what you look at — it is what leaves the device.
If your app includes an analytics SDK, crash reporting, an ads network, a sign-in provider, push notifications, or an in-app purchase framework, data is being collected. Anonymised counts as collected. Never opening the dashboard counts as collected. A default that you left switched on in a starter template counts as collected.
So the first step is not writing — it is an inventory. Open your dependency list and go through it honestly. Then write the policy against what you found, and make Apple's App Privacy label and Google's Data safety form agree with both. Mismatches between the three are a routine rejection, and after launch they are an enforcement risk rather than a review one.
What the page has to say
At minimum:
- Who you are — the developer or company name, and a contact email that works.
- What you collect — each data type, named, not "certain information".
- Why — the purpose for each type.
- Who it is shared with — every third party, including your analytics and ads vendors.
- How long you keep it, and how a user asks for deletion.
- Children's data, if your app is directed at or accessible to children.
- A last-updated date.
If you want the structure without writing it from scratch, our app privacy policy generator builds the policy from Apple's own App Privacy label categories, so the text and the declaration you file describe the same thing. It also produces the support page. Reconcile both against your real dependency list before you submit — a generator cannot know your SDKs.
Where the page has to live
At a stable, public URL on a domain you control — yourapp.com/privacy. It has to load for someone who is not signed in, on any device, without a redirect chain or a download prompt.
This is why the privacy policy quietly becomes a domain requirement. A document-sharing link is regularly rejected, and it is fragile in exactly the way a compliance artefact should not be. You need the domain regardless for Apple's support URL, and the reverse-domain package ID you are about to permanently commit to assumes you own it too.
Check the domain for your app →
Once you have the domain, one static page covers the privacy policy, the support page and your marketing page. That is an afternoon, not a project.
If you have no site at all yet, Carrd is the shortest route to a real one — a single page with your app description, a support section and a /privacy page, on your own domain, for a few dollars a year. It exists to satisfy exactly this kind of requirement.
Then finish the rest of the submission
The privacy policy URL is a hard gate, but it is not the only one. The 30-character title cap, the permanent package ID, the support URL and the screenshot requirements all sit between you and a live listing. The Ship an App path covers each of them in order.
And before any of that: check that your app name is actually free →
