Yes, a privacy policy URL is required for every app in App Store Connect. Apple requires a publicly accessible privacy policy URL in your app's App Information, and review guideline 5.1.1 states that all apps must include a link to their privacy policy in the App Store Connect metadata field and within the app. The URL has to load without a login and point to a policy that accurately describes what data your app collects and how it is used. You can write the policy with a free generator as a starting point and host it anywhere public, including a Notion page published to the web, as long as the URL is stable, loads reliably, and the policy matches what your app actually does.
Short answer
The privacy policy URL is mandatory, not optional, for all apps including free and simple ones. Per Apple's App Store Connect guidance, you are required to provide a publicly accessible privacy policy URL, and per guideline 5.1.1, the policy must identify what data the app collects, how it is collected, and how it is used. So you cannot complete submission without it. You may draft the policy with a free generator and host it on any public page, such as your website, a static host, or a Notion page published to the web, provided the URL stays live and the policy reflects your real data practices rather than a generic template.
Is the privacy policy URL required?
Yes, and there is no exemption based on how small or simple your app is. Apple made a privacy policy link mandatory for every app, so a free utility with no accounts still needs one, and both new apps and updates require the field to be filled before you can submit. The App Information section will not let you complete submission with the privacy policy URL empty, so this is a hard requirement rather than a recommendation you can skip.
The requirement has two parts that people often miss. Guideline 5.1.1 asks for the link in the App Store Connect metadata field and within the app itself in an easily accessible manner, so a policy hosted only in the store listing may not be enough for apps where in-app access is expected. For the store side specifically, which is what the App Information URL covers, the answer is simply that it is required, and the practical task is producing a valid, accurate policy at a stable public address.
Where the field is and what it applies to
The privacy policy URL lives in App Store Connect under your app's App Information, in the general information area, as a dedicated Privacy Policy URL field. It is set at the app level rather than per version, so the URL you enter applies across your app's releases until you change it, and you do not re-enter it for every update.
App Store Connect also allows a localized privacy policy URL, so if you serve multiple regions with different policy versions, you can provide a specific URL per language or storefront. The key point is that the field is part of App Information, which is where reviewers and users find your policy link, so entering a correct, working URL there is what satisfies the store requirement.
What makes a valid privacy policy URL
A valid URL is one that is publicly accessible, loads reliably, and points to an actual privacy policy that matches your app. Publicly accessible means it opens without a login or paywall, because a reviewer, and a user, must be able to read it directly; a link that sits behind authentication fails. It should load consistently and use a stable address that will not change or expire, since a dead or moved link is treated as a missing policy.
The content matters as much as the address. The policy has to describe what data your app collects, how it is collected, and how it is used, and per guideline 5.1.1 it must also confirm that any third party you share data with provides equal protection. A URL that loads but shows a generic or irrelevant policy can still be rejected, because Apple checks that the policy is real and consistent with your app. So a valid URL is the combination of a working public link and a policy that honestly reflects your data practices.
Can you use a free privacy policy generator?
Yes, a free privacy policy generator is a fine starting point, as long as you tailor the result to your app rather than pasting it as-is. These tools produce a structured policy from answers about your data collection, which saves you writing one from scratch and covers the standard sections reviewers expect. For a straightforward app, a generated policy that you review and adjust is usually acceptable.
The risk is a generic policy that does not match what your app actually does. If the generated text claims practices you do not follow, or omits data you do collect, it can conflict with your App Privacy details, the nutrition label, and trigger a 5.1.1 rejection for an inaccurate or inconsistent policy. So treat the generator as a draft: confirm every data type it lists is one you actually collect, add anything it missed, and make sure it aligns with the answers you gave in App Store Connect. The requirement is accuracy, and a generator only gets you an accurate policy if you check it against your real behavior.
Can you host it on Notion?
Yes, you can host your privacy policy on a Notion page, and more generally on any publicly accessible page, because Apple only needs a working public URL, not a specific host. To use Notion, publish the page to the web so it is viewable without a Notion account, and use the resulting public link as your privacy policy URL. The same applies to a page on your own site, GitHub Pages, a Google Site, or another static host.
There are practical caveats with a third-party page. The link must be public and stable, so confirm the page stays published and that its URL does not change, and be aware that a Notion link is long and unbranded and depends on Notion staying up. A privacy policy on a domain you control is more reliable and looks more professional, which matters if the page ever fails to load during review. So Notion works and is a reasonable free option, but whatever you choose, the test is the same: does it load publicly, stay live, and show your real policy.
Hosting options compared
Any public, stable host works, and the differences are about reliability and effort. The table below compares common choices.
| Hosting option | Works for Apple? | Caveat |
|---|---|---|
| Your own domain | Yes | Most reliable and professional; needs setup |
| GitHub Pages or static host | Yes | Free and stable; a little technical to set up |
| Notion published page | Yes | Must be public; long URL; depends on Notion uptime |
| Google Sites or Docs (public) | Yes | Ensure sharing is fully public, not link-restricted |
| A page behind login | No | Fails because reviewers cannot access it |
Read the last row as the disqualifier: any option is fine except one that is not publicly accessible, which is the single thing Apple will not accept.
Review impact of a missing or bad URL
Because the field is required, a missing privacy policy URL blocks submission outright, and a broken or inaccessible one causes a rejection once review reaches it. A link that returns a 404, has expired, or requires a login is treated as no policy at all, which is a common and avoidable 5.1.1 rejection. So the URL failing is not a gray area; it stops the app.
A subtler rejection comes from a policy that loads but does not match your app. If your written policy contradicts your App Privacy details or omits data you actually collect, a reviewer can reject it for being inaccurate even though the link works. Conversely, a correct, accessible, accurate policy has no negative review impact and simply satisfies the requirement. So the two things to get right are that the link works publicly and that the policy honestly matches your data practices.
Setup checklist
Working through these steps satisfies the requirement cleanly. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Write the policy | Draft it, using a generator you then tailor | [ ] |
| Match your data use | Confirm it reflects what your app collects | [ ] |
| Host it publicly | Use a stable page with no login required | [ ] |
| Test the link | Open it in a private window to confirm access | [ ] |
| Add it in App Information | Paste the URL in the Privacy Policy field | [ ] |
| Align with App Privacy | Ensure it matches your nutrition label answers | [ ] |
The step teams skip most is aligning the policy with the App Privacy answers, since a mismatch between the two is a frequent cause of a 5.1.1 rejection even when the link works.
Where a scan fits
Writing an accurate policy depends on knowing what your app actually collects and sends, which is easier to confirm when you can see it rather than rely on memory or a generator's assumptions.
A scanner like PTKD.com analyzes your app build and reports the data-related behavior in it, such as third-party SDKs, network endpoints, and permissions, by severity and mapped to OWASP MASVS. To be clear about the boundary: PTKD does not write your privacy policy or host your URL, which are yours to create and publish. It helps you see what your app really does with data, so the policy you write and the App Privacy details you enter reflect reality rather than guesswork.
What to take away
- A privacy policy URL is required for every app in App Store Connect, including free and simple ones, and you cannot submit without it.
- It goes in App Information as a dedicated field, applies at the app level across versions, and can be localized per region.
- The URL must be publicly accessible with no login, load reliably at a stable address, and point to a policy that accurately describes your data practices.
- You can draft the policy with a free generator and host it anywhere public, including a Notion page published to the web, as long as you tailor the content and keep the link live.
- A missing or broken URL blocks submission or triggers a 5.1.1 rejection, and a tool like PTKD.com helps you see what data your app handles so the policy is accurate.
