Diagnostic8 min read

Apple Rejected Your Privacy Policy. Here Is the 2026 Fix

Privacy violations are the leading cause of App Store rejection in 2026. 15% of submissions fail Guideline 5.1.1 alone. Here is exactly what Apple checks, what fails most often, and how to fix it before you resubmit.

Published April 12, 2026

Key takeaways

  • Privacy is the leading cause of App Store rejection. Roughly 15% of submissions fail for privacy-related reasons.
  • Apple checks your privacy policy link in both App Store Connect metadata AND inside the app itself. Missing either one means rejection.
  • In 2026, under updated Guideline 5.1.2, you must also disclose if you share data with any third party, including AI systems.
  • Most rejections are fixable in under an hour once you know what Apple is actually looking for.

You got the rejection. Your submission failed review. The reason says something like "Your app collects user data but we were unable to find a privacy policy in the app" or "the privacy policy URL is invalid."

This is the single most common rejection category in 2026, and it's fixable. Here is exactly what Apple checks, what fails most often, and how to get through review on the next pass.

Why this keeps happening

Apple's review system enforces privacy more strictly every year. 15% of app submissions now get rejected, and privacy violations are the single biggest reason. The rules aren't new, but the enforcement is.

There are two places where Apple checks for a privacy policy:

  1. App Store Connect metadata: the privacy policy URL field in your app's settings
  2. Inside the app binary itself: a visible link to your privacy policy accessible from within the app, typically in Settings, Help, or an About screen

Missing either one means rejection. Having both but one is broken means rejection. Having both but the policy doesn't match what your app actually does means rejection.

The six things Apple actually checks

1. The URL works and returns real HTML

Apple's reviewers click the link. If it 404s, redirects to your homepage, returns a PDF (PDFs are not accepted), or times out, your app is rejected. Test the URL in an incognito window before submitting.

2. The privacy policy is visible inside the app

Not hidden behind three taps. Not only shown during onboarding. Not embedded in a terms screen that users scroll past. Apple's reviewers expect to find a clear link from somewhere like Settings → Legal → Privacy Policy, or a footer link on your main screen. If they can't find it in 30 seconds, you're rejected.

3. The policy matches what your app actually does

This is the trap. You copy-pasted a template that says "we collect email addresses and usage data." But your app actually accesses the camera, stores photos on your server, and sends events to a third party analytics service. Apple rejects the mismatch. Your privacy policy has to reflect the actual data you collect, how you collect it, and where it goes.

4. Third-party data sharing is disclosed

Under Guideline 5.1.2 in 2026, if your app shares any personal data with third parties, including third-party AI systems, you must explicitly disclose this and obtain clear user permission before the data is transmitted. This includes analytics SDKs, crash reporting tools, feature flag services, and any AI feature you've integrated.

Specifically call out:

  • Which third parties receive user data
  • What kind of data each one receives
  • Why it's being sent
  • Whether the user can opt out

5. The App Store privacy nutrition label matches your policy

App Store Connect has a "Data Types" section where you declare what your app collects. This shows up as the nutrition label on your App Store listing. If your privacy policy says one thing and your nutrition label says another, Apple rejects. Go through the list and make sure every data type you collect is declared.

6. App Tracking Transparency is implemented if applicable

If your app tracks users across apps and websites owned by other companies, you must use ATT (App Tracking Transparency) and prompt the user. If you skip ATT, Apple rejects. Even if you're only using Facebook SDK for login (no tracking), many SDKs enable tracking by default, so double-check your Info.plist and SDK configuration.

How to fix it (step by step)

Step 1: Audit what your app actually collects

Write it down. For each data point:

  • What is it (email, usage events, crash logs, etc)
  • Who collects it (your server, Firebase, PostHog, Sentry, etc)
  • Why it's collected
  • Whether it's linked to a user identity

Step 2: Update your privacy policy

Rewrite the policy to match the audit. Use plain language. Keep sections short. Include:

  • What data you collect
  • Why you collect it
  • Who you share it with (name the third parties)
  • How long you keep it
  • How users can delete their data
  • A contact email for privacy questions
  • A "last updated" date

Step 3: Host it on a working URL

Not a PDF. Not a Google Doc that requires sign-in. A real HTML page at a real URL likehttps://yourapp.com/privacy. Test it in an incognito window.

Step 4: Add a visible link inside the app

Put a "Privacy Policy" link in your Settings screen or an About screen. Make it obvious. Reviewers are looking for it.

Step 5: Update App Store Connect

Go to App Store Connect → your app → App Privacy. Update:

  • Privacy Policy URL (matches the one inside your app)
  • Data Types declaration (matches your policy exactly)
  • Any third-party data sharing disclosures

Step 6: Resubmit with a clear reviewer note

In the Review Information section, add a note: "Updated privacy policy to reflect all data collection and third-party sharing. Privacy link visible from Settings → Legal → Privacy Policy." Reviewers appreciate when you tell them what changed.

What to avoid in your privacy policy

  • Generic template language that doesn't match your app
  • Vague phrases like "we may collect" instead of specific lists
  • Missing third-party SDK disclosures
  • No contact method for privacy questions
  • No last-updated date
  • PDF-only policies (Apple requires HTML)
  • Password-protected or signed-in pages

How to avoid this next time

Run through your privacy setup before you hit submit. The two places to check are always the same: does the URL work, and is it findable inside the app. Keep a "data collected" document somewhere in your repo that you update every time you add a new feature or SDK. Match it against your privacy policy before every submission.

If you want something that does this automatically for you, the Trust and Legal category of the eight launch categories covers privacy policy, terms, and third-party disclosures for mobile apps specifically.

Common questions

Does Apple care if my privacy policy is a template?

Apple doesn't care where it came from, only whether it accurately describes your app's data practices. Template is fine as a starting point. Customized to match your actual app is what matters.

What if my app collects zero data?

You still need a privacy policy. It can be short: "This app does not collect, store, or share any personal data." But the link still has to exist in both App Store Connect and inside the app.

Is Google Play different?

Google Play has similar requirements. Their "Privacy policy link invalid or missing" rejection is the equivalent of Apple's 5.1.1. The fix is the same: real HTML page, visible link, matches actual data collection. Google also requires the Data Safety form to be completed.

How long does re-review take after resubmitting?

Typically 24-48 hours in 2026, sometimes same-day. If you include a clear reviewer note explaining what you fixed, it tends to be faster.

Can I use a privacy policy generator?

You can use one as a starting point, but read it carefully and customize it. Most generators produce overly broad language that doesn't match what your specific app does. Apple rejects mismatches.

CalmLaunch checks this for you automatically.

112 launch constants across 8 categories. Adaptive to your project type. Free for 3 projects, no credit card required.

See what I'm missing

Related reading