How do I fix an Apple Guideline 5.1.1 data collection rejection?

A Guideline 5.1.1 rejection arrives when an App Review reviewer finds that the data your app collects, including through third-party SDKs, does not line up with what your privacy policy, App Privacy questionnaire, or Privacy Manifest declares. The message is generic on purpose, which makes the first useful step identifying which collection point triggered the flag.

Short answer

The short answer is that Guideline 5.1.1 covers data collection and storage under Apple's App Review Guidelines, and a rejection under this rule usually means three things at once: the build collects data the reviewer was not expecting, the privacy policy or App Privacy answers are silent on that collection, and the source is often a third-party SDK rather than first-party code. Per Apple's App Review Guidelines 5.1.1, the policy requires that all uses of collected data appear in the privacy policy. The fix begins with identifying which SDK is producing the undisclosed call.

What you should know

• Guideline 5.1.1 is a class of rejections, not a single rule. It has sub-points (i) through (x), and the rejection message names which one applies.
• Most 5.1.1 rejections in 2025 and 2026 are SDK-related. Firebase, Facebook SDK, AppLovin, AdMob, OneSignal, and attribution frameworks drive a large share of flagged builds.
• Privacy Manifest is a separate object from the App Privacy questionnaire. PrivacyInfo.xcprivacy lives inside the binary; App Privacy answers live in App Store Connect.
• Apple maintains a published list of commonly used SDKs. Builds shipping any of them since May 1, 2024 must include a Privacy Manifest for that SDK.
• Resolution Center is usually enough. A 5.1.1 rejection can often be answered with a metadata or App Privacy correction; a fresh binary is required only when the Privacy Manifest or a purpose string needs to change.
• The privacy policy URL must work and the policy text must match the questionnaire. Reviewers do open the link.

What does Apple actually check under Guideline 5.1.1?

The short answer is that Guideline 5.1.1 covers the entire chain of data collection and storage. According to Apple's App Review Guidelines, the rule has ten sub-points. The ones that drive the most rejections are (i) Privacy Policies, (ii) Permission, (iii) Data Minimization, and (v) Account Sign-In.

In practice, the reviewer compares three artefacts: the App Privacy answers you filled in inside App Store Connect, the privacy policy URL on the listing, and the actual behavior of the binary. If the binary collects identifiers, advertising data, or device telemetry that the policy or the questionnaire does not disclose, the build is rejected under 5.1.1. The most common trigger is a third-party SDK the developer either forgot was included or assumed someone else had declared.

The rejection message itself is short. It usually begins with a single paragraph that names the sub-point and the data category at issue. Reading it word by word, before reaching for the codebase, saves time. The sub-point reference inside the parenthesis is the most useful signal in the entire letter.

How do I identify which SDK is triggering the privacy flag?

The honest answer is that Apple rarely names the SDK in the rejection letter. The reviewer names the data category (advertising identifier, device identifier, user content) and leaves the developer to trace it. A reliable trace looks like this.

First, open Xcode and run Product, then Generate Privacy Report on the archive. Apple's Privacy Report aggregates every PrivacyInfo.xcprivacy file present in the binary and lists which SDKs declare which data types. Per Apple's documentation on Privacy Manifest files, the report becomes the canonical source for what your app says it collects.

Second, compare the Privacy Report against your App Privacy answers in App Store Connect. Any data type that appears in the report but not in the questionnaire is a candidate for the rejection. Any data type in the questionnaire but missing from the report is a different kind of risk for later submissions.

Third, if a category appears in the report under an SDK you did not add intentionally (a common pattern with Firebase pulling in GoogleUtilities or Facebook SDK pulling in FBAEMKit), trace it back through your Podfile, Swift Package dependencies, or React Native autolinked modules. Mobile security scanners that perform a static pass over the IPA can also list the third-party libraries inside the binary, which shortens this step considerably.

Where does Privacy Manifest fit into a 5.1.1 rejection?

The short answer is that Privacy Manifest does not replace App Privacy answers; both must be present, and both must agree. Per Apple's published third-party SDK requirements list, as of May 1, 2024 a set of commonly used SDKs (including AFNetworking, Alamofire, the Firebase suite, OneSignal, FBSDKCoreKit, Reachability, RxSwift, GoogleSignIn, and many others) must ship a PrivacyInfo.xcprivacy file. Builds that include one of these SDKs without a manifest receive an ITMS-91061 warning, and after a grace period the warning becomes a hard rejection.

Privacy Manifest is also where the Required Reason API declarations live. Apple flags categories such as NSPrivacyAccessedAPICategoryFileTimestamp and NSPrivacyAccessedAPICategoryUserDefaults and asks for a specific reason code. A missing reason code can produce both an ITMS-91065 warning and a 5.1.1 rejection if the reviewer concludes that the data those APIs touch is being collected silently.

In practice, when a 5.1.1 rejection arrives:

1. Check whether ITMS-91061 or ITMS-91065 was issued for the same build (it appears in the App Store Connect Activity tab).
2. If yes, the SDK named in that warning is almost certainly the trigger.
3. If no warning was issued, the trigger is more likely an App Privacy answer or a privacy policy gap rather than a missing manifest.

This is the gap that pre-submission scanners aimed at App Review readiness try to close. PTKD.com (https://ptkd.com), for example, focuses on static analysis of the IPA or APK against the published SDK lists and the OWASP Mobile Application Security Verification Standard, so the developer sees which manifest is missing before the build is uploaded.

How do I read the exact rejection text?

The short answer is to find the sub-point reference inside the parenthesis. The body of a 5.1.1 rejection is usually one of these shapes.

• 'Guideline 5.1.1(i), Privacy Policy' means the policy is missing, the URL is broken, or the published text does not cover the actual collection.
• 'Guideline 5.1.1(ii), Permission' means a permission prompt is missing a clear purpose string, or the app collects data without obtaining consent first.
• 'Guideline 5.1.1(iii), Data Minimization' means the app asks for more data than the core functionality requires (the classic City, State, Birthdate registration form is the canonical example).
• 'Guideline 5.1.1(v), Account Sign-In' means an account is required for a feature that does not need one, or in-app account deletion is missing.

Each sub-point has a different fix. A 5.1.1(iii) rejection is typically a form change with no binary needed. A 5.1.1(i) rejection often needs a policy text update on the live URL. A 5.1.1(ii) rejection usually involves rewriting an NSXxxUsageDescription purpose string and uploading a fresh build.

Which third-party SDKs most often trigger a 5.1.1 flag?

A short comparison helps. The table below lists the categories of SDK most often named in 2025 and 2026 forum threads and the data type the reviewer typically catches.

This table is directional, based on patterns reported by developers in the Apple Developer Forums and on Stack Overflow. Apple does not publish per-SDK rejection rates, so any precise number on which SDK fails most often would be a fabrication.

How do I respond in Resolution Center without resubmitting?

The short answer is that for most 5.1.1(i), (iii), and (v) rejections, an App Privacy or metadata update plus a clear Resolution Center reply is enough. The flow looks like this.

1. Open Resolution Center inside App Store Connect and read the rejection message word for word.
2. Identify the sub-point and the data category named in the parenthesis.
3. If the issue is the App Privacy questionnaire, update the answers under My Apps, App Privacy. The change does not require a new binary.
4. If the issue is the privacy policy text, update the published URL (the live page, not a draft) and confirm the URL still loads in an incognito browser.
5. Reply in Resolution Center with a short note: the sub-point, the specific change made, and the date of the change. Reviewers respond better to specific notes than to vague 'policy updated' replies.
6. Tap Submit and wait. The same reviewer often picks up the reply within 24 to 48 hours.

For 5.1.1(ii) issues involving a permission prompt, a new build is required because purpose strings ship inside the Info.plist. For SDK-driven issues that need a manifest, a new build is also required because PrivacyInfo.xcprivacy is embedded in the binary.

What to watch out for

Several edge cases produce a 5.1.1 rejection that looks unrelated to data collection at first glance.

• Pre-account analytics. Some SDKs (notably AppsFlyer, Adjust, Branch) fire an attribution call before the user sees the App Tracking Transparency prompt. The reviewer can flag this under 5.1.1(ii). The fix is to gate any tracking SDK initialization behind the ATT response.
• Cached privacy policies. If your policy URL was cached at a CDN with stale content, the reviewer may still see the old text. Verify the live URL from an incognito browser before replying.
• Reused builds across regions. A build that passed review in one storefront can fail in another if the local privacy policy translation is missing. The reviewer in a different region reads the policy in their language.
• Embedded WebViews. A WebView that loads a third-party page can be flagged under 5.1.1 if the embedded page collects data the host app does not declare. The remote page counts as part of your app for the purpose of review.
• The myth that App Privacy answers can be left vague. Some teams answer 'Data Not Collected' on every category in the hope of skipping the questionnaire. The reviewer will then compare against the Privacy Report and reject the mismatch.

The OWASP Mobile Application Security Testing Guide treats third-party SDK inventory as part of MASVS-STORAGE and MASVS-PRIVACY. Treating an SDK as someone else's problem is the most reliable way to fail a 5.1.1 review.

Key takeaways

• Treat a Guideline 5.1.1 rejection as a mismatch between three objects: the binary's actual collection, the App Privacy questionnaire, and the published privacy policy. Aligning the three is the entire fix.
• Use Xcode's Generate Privacy Report on the archive to see the consolidated Privacy Manifest view; the SDK named there will usually match the SDK behind the rejection.
• ITMS-91061 and ITMS-91065 warnings in App Store Connect are the strongest signals that a specific SDK is missing a manifest; check the Activity tab before guessing at the codebase.
• Most 5.1.1(i), (iii), and (v) rejections can be resolved without a new build by updating metadata and replying in Resolution Center; only sub-points that change the binary need a fresh upload.
• Some teams outsource the pre-submission privacy audit, including the per-SDK manifest check against Apple's published list, to platforms like PTKD.com (https://ptkd.com); it is one way to catch a missing manifest before App Review does.