Few rejection notes sting like the one that arrives after you thought you were done: your app was rejected for a privacy policy problem. It is one of the most common reasons a first submission bounces, and it is also one of the most avoidable. Both Apple and Google treat a reachable privacy policy as a baseline requirement — not an optional nicety — and both check it the same way a stranger would: by opening a link in a plain browser.
This page explains what the two stores expect, the handful of failures that trigger the rejection, and what a reviewer (and an automated scan) actually sees on your public surface. It closes with a short fix checklist. The aim is to help you clear the bar before you resubmit, not to promise an outcome.
What Apple and Google actually require
On the App Store side, Guideline 5.1.1 of Apple's App Review Guidelines requires every app to include a link to its privacy policy — in App Store Connect metadata and, where relevant, within the app itself. This applies broadly, including to apps that collect little data. On the Google side, Play Console requires a privacy policy URL for every app, entered in the app's store listing and Data safety section. Store guidelines are updated periodically, so confirm the current wording against Apple's and Google's official policy pages rather than relying on memory.
The shared thread is simple: a policy that a user, and a reviewer, can reach and read. A document sitting in your repo, behind a login, or linked from a broken URL does not satisfy that.
The failures that trigger the rejection
Most privacy-policy rejections trace back to one of four things:
- No policy at all — the URL field is blank, or the app links nowhere. The most direct failure.
- A broken or placeholder link — a 404, a domain that lapsed, a "coming soon" page, or lorem-ipsum text that was never replaced. From a reviewer's browser, this reads the same as having no policy.
- A policy that doesn't match the data the app collects — the app uses analytics, location, or contacts, but the policy is silent on them, or it describes a different product entirely. Mismatches invite follow-up questions and rejections.
- No AI or third-party disclosure — the app sends user input to a model provider, ad network, or analytics SDK, but the policy never names those data flows. → maps to privacy policy
A subtler variant: the link is fine, but it disagrees with your store privacy answers. Apple's privacy labels and Google's Data safety form ask what you collect and share; if the policy says one thing and the form says another, the inconsistency itself can stall review.
What a reviewer — and a scan — sees
A reviewer does not read your source code. They open your privacy policy URL from a plain, logged-out browser and look at what loads. If the page returns an error, demands a login, or clearly isn't a privacy policy, it fails the check — regardless of what exists on your servers.
An automated scan works the same way. LaunchTrust fetches your public page and inspects the HTML an anonymous visitor receives. The privacy policy detector reports detected when it finds a linked page that looks like a privacy policy, not detected when it can't find one, and unable when the page can't be fetched. The App Store privacy check looks at whether your privacy surface lines up with store expectations, and the terms of service detector reports whether a terms document appears present and linked.
Each result is a signal, not a judgment. "Detected" means a policy-shaped page is reachable; it does not confirm the policy is complete, accurate for your app, or sufficient for a given store's rules.
The fix checklist
Work through these before you resubmit. Each is something you can confirm from the outside, the way a reviewer will.
- The policy is published at a stable, public URL that opens for a logged-out visitor — no login wall, no placeholder, no 404.
- The same URL is in App Store Connect and Play Console, and linked inside the app where required, so every surface points to one reachable policy.
- The policy matches the data the app collects — it names the categories you gather and the third-party services that receive them, including any AI model providers. → privacy policy
- The policy agrees with your store privacy answers — Apple's privacy labels and Google's Data safety form tell the same story. → App Store privacy check
- Terms of service are linked where your app needs them, especially if you have subscriptions or user-generated content. → terms of service
- Any AI feature is disclosed — if your app runs a chatbot or generative feature, an in-context notice and a policy mention both help. → EU AI Act Article 50 checklist
- The link is legible and not hidden — reachable in a couple of taps, not buried behind microscopic text or a paywall.
If you can tick the first three plus the store-answer item, you have addressed the parts of the privacy-policy requirement that most often cause a rejection.
Check this in 30 seconds
Run your URL through LaunchTrust's free scanner. It fetches your live page and reports whether a privacy policy is detected, not detected, or unable to determine — alongside your terms of service and other launch signals — so you can catch a missing or unreachable policy before an app reviewer does. No signup, no crawl of private pages: it reads the same public HTML your visitors get. If the policy shows not detected, that is exactly the gap a store reviewer would flag.
FAQ
Does every app really need a privacy policy? In practice, yes. Apple's App Store Review Guideline 5.1.1 requires every app to link to a privacy policy, and Google Play requires a privacy policy URL for all apps in Play Console. This holds even for a simple app that collects little or no data — the reachable link is expected regardless. Confirm the current wording against Apple's and Google's official policy pages, since they are updated periodically.
Why was my app rejected when I already had a privacy policy link? The most common reasons are that the link was unreachable at review time (a 404, a login wall, or a temporary outage), that it pointed to a placeholder or the wrong page, or that the policy did not match the data the app actually collects. Reviewers open the URL from a plain browser, so anything a logged-out visitor can't reach counts as missing.
Does the privacy policy have to mention AI and third-party services? If your app sends user input to a third-party model provider, analytics SDK, or ad network, that data flow is generally expected to be described. A policy that omits the services your app clearly relies on is a common source of follow-up questions or rejection. Store data-safety and privacy-label answers should also line up with what the policy says.
Does a "detected" privacy policy mean my app will be approved? No. "Detected" means the scanner reached your URL and found a page that looks like a privacy policy. It does not confirm the policy is complete, accurate for your app, or sufficient for a given store's rules. LaunchTrust surfaces signals — it is not legal advice, certification, or a guarantee of approval. For your specific situation, consult a qualified professional.
Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.