Privacy Rejections - Guideline 3.2.2(ix) Fixing Your Privacy Policy and App Privacy Label Mismatch

This note shows how to fix Apple Guideline 5.1.1 rejections caused by mismatches between your App Privacy label, published privacy policy, and observable runtime or SDK behavior. Read this to triage a rejection, choose the least-effort realistic fix, and assemble the evidence reviewers expect.

Guideline 5.1.1 Privacy Rejections: Fixing Your Privacy Policy and App Privacy Label Mismatch goes deeper on the ideas above and adds concrete next steps.

How quickly do metadata fixes resolve 5.1.1 privacy-label mismatches?

Takeaway - metadata-only fixes were the fastest wins in our sample, usually returning a reviewer response in 24-72 hours and often avoiding code changes.

What this block means: across 30 Froxi-managed cases the fastest wins were App Store Connect and policy edits teams could complete in hours. If an SDK or runtime behavior is the root cause, expect multi-day work and back-and-forth with reviewers. Use these as operational benchmarks, not guaranteed industry timings.

When you move from outline to execution, How to Fix App Store Guideline 5.1.2 Data Use and Sharing Rejection helps close common gaps teams hit here.

Why does Apple flag Guideline 5.1.1 and what should you check first?

Process diagram mapping the three top mismatch types (Missing category, Missing third‑party sharing clause, SDK telemetry mismatch) to the immediate remediation action (edit policy text / update App Privacy form / remove or replace SDK) with estimated effort annotations (minutes, hours, days).

Apple rejects for 5.1.1 when App Store metadata, your public privacy policy, and observable runtime behavior do not match. Identify which of the three checkpoints diverges and you can pick the least-effort remedy.

Three reviewer checkpoints (validate these first)

• App Store Connect App Privacy form

  Confirm each selected data category and sharing toggle is reflected in your policy text.

• Published privacy policy URL

  Ensure the policy names data categories, sharing or vendor relationships, and purposes.

• Runtime behavior / SDK network evidence

  Capture logs or a short proxy trace to confirm whether SDKs transmit the declared categories.

Top mismatch types and immediate fixes

• Missing data category in policy but selected in App Privacy

  Fix: add a short policy bullet mapping category - purpose - retention, or uncheck the category in App Store Connect. Often same-day.

• Label shows third-party sharing but policy lacks sharing language

  Fix: add a sharing subsection with named vendors or vendor classes and update App Store Connect. Note that naming vendors can require partner legal review.

• Policy claims "device-only" while included SDKs send telemetry

  Fix: inventory the SDKs and either remove or gate the SDK, or update policy and App Privacy to match telemetry. Expect engineering, QA, and a 2-5 business day minimum for small code changes.

A complementary angle worth comparing lives in How to Fix App Store Guideline 5.1.1 Privacy Rejection.

Which remediation steps should you run first and how long will they take?

A printable checklist block for the 60 - 90 minute triage: export App Privacy answers, map categories to policy bullets, update sharing clause, take screenshots, draft App Review note, and resubmit - each item includes an expected time budget (5 - 30 minutes).

Fix metadata first with a 60-90 minute pass; escalate to a policy patch next day if needed; move to binary changes only when runtime evidence shows undeclared transmissions. This minimizes engineering time and reviewer friction.

Quick triage (60-90 minutes)

1. Export App Privacy answers

   Screenshot the App Store Connect form so you have selected categories and sharing toggles. Allow 5-10 minutes.

2. Map categories to your published policy

   Search the policy for each category; if missing, add one-line bullets: category - purpose - retention. Budget 10-30 minutes.

3. Confirm sharing language

   If sharing is checked, add a one-paragraph clause with named vendors or vendor classes and purposes. Expect 15-30 minutes; vendor confirmations can add days.

4. Draft App Review note and resubmit

   Screenshot policy and App Privacy, write a concise note, and resubmit metadata-only. Expect a 1-3 day reviewer response; allow buffer for account history.

One thing worth noting: metadata fixes often reduce friction but do not eliminate the chance of follow-ups.

If runtime or SDK issues appear - realistic path and risks

Run an SDK inventory (CocoaPods, SPM, Gradle) and a short network capture (Charles, mitmproxy) to confirm transmissions. Options: replace the SDK, gate it behind server logic, feature flag it, or remove it.

Binary remediation requires dev work, QA, privacy or legal sign-off, and TestFlight testing. Plan 3 business days for small changes and multiple weeks for complex work. Expect a realistic 20-40% schedule buffer for unexpected reviewer questions or integration issues. Tradeoffs: removing or gating an SDK can reduce analytics or feature capability; replacing a vendor may create compliance or integration work.

Sample App Review notes and evidence to attach

• Metadata-only sample note

  Updated App Privacy and privacy policy to list [Data categories]. No SDK or code changes. Policy URL updated to include a Sharing & Vendors paragraph. Please re-review.

• Binary resubmission sample note

  Removed analytics SDK X and replaced with X-lite. Attached SDK inventory CSV, network capture excerpt, and a test account to reproduce.

Evidence checklist: public policy URL, screenshot of updated App Privacy form, SDK inventory CSV (name/version/purpose), and a short network capture if runtime behavior changed. Keep attachments concise and clearly labeled.

For tradeoffs, checklists, and edge cases, Writing a Privacy Policy That Actually Passes App Store Review rounds out this section.