Why do apps get rejected under 5.1.1 Privacy?
5.1.1 requires that apps only collect data they need, disclose it in the App Privacy 'nutrition labels', and get consent. Rejection triggers reviewers actually hit: the privacy labels say 'no data collected' while the app visibly contains analytics/ad SDKs (reviewers and automated scans check for Firebase, Adjust, Meta SDK network calls); a privacy policy link that is dead, generic, or does not match the app's actual collection; requesting permissions (location, contacts, photos, tracking) at launch with no context; and missing or boilerplate purpose strings. The privacy policy URL must be functional at review time and cover every data type your SDKs touch. Audit your actual network traffic with a proxy once — what you ship and what you declare must match.
What is the in-app account deletion requirement (5.1.1(v))?
Since 2022, any app that supports creating an account must let users delete that account from inside the app — guideline 5.1.1(v). Reviewers test this: they create an account with the demo credentials and look for the deletion path. Requirements that bite: deletion must be real deletion of the account and associated data (not just sign-out or 'deactivation'), must be reachable in a reasonable number of taps, and must not require emailing support or visiting a website as the only path. You may send the user to a web flow to finish, but the entry point must be in-app. 'Delete my data but keep my account' options are fine as additions, not substitutes. This is a top-5 rejection reason for account-based apps.
My permission purpose strings got auto-rejected — why?
App Store Connect validation (and later review) rejects builds where an Info.plist usage-description string is missing, empty, or generic. The error for missing keys is ITMS-90683 at upload time; vague strings fail later in human review. Purpose strings must name the concrete user-facing feature: 'We use your location to show nearby drivers' passes; 'This app needs location access' or marketing filler does not. Every sensitive API needs one: camera, photo library, microphone, contacts, location (when-in-use and always — 'always' needs strong justification), Bluetooth, local network, motion, tracking (plus AppTrackingTransparency for cross-app tracking). Rule of thumb: write the string as the answer to 'why does this app need this, right now?'
What is the privacy manifest and when does it block me?
Apple requires a PrivacyInfo.xcprivacy manifest in apps and in listed third-party SDKs, declaring required-reason API usage and tracking domains. Since May 2024, uploads that use a required-reason API (file timestamps, system boot time, disk space, user defaults, etc.) without a declared reason produce ITMS-91053-style warnings that become hard upload errors. Practically: if you embed Firebase, analytics, or ad SDKs, you depend on those SDKs shipping valid manifests — an outdated SDK version with a missing or malformed manifest blocks your App Store upload, not just review. Fix by upgrading SDKs to versions that include manifests and adding your own manifest with the correct reason codes (e.g., CA92.1, C617.1). As of early 2026 this is enforced at upload, before any human sees the build.
What does Google Play's Data safety form actually require?
The Data safety section in Play Console is a sworn declaration of what data your app collects, shares, and how it is secured — and Google cross-checks it. Under the User Data policy, mismatches between the form and actual behavior (e.g., declaring 'no data shared' while an ad SDK transmits the advertising ID) are a policy violation that can remove the app. The form asks per data type: collected or shared, purpose, optional vs required, encrypted in transit, and whether users can request deletion. Since 2024 the deletion requirement is real: apps with account creation must provide a deletion path and disclose it in the form, with a web link for deletion requests. Fill it from an actual audit of your SDKs' data flows, not from guesses — SDK vendor docs (Firebase, Meta) publish the values you should declare.
What is the privacy manifest, and when does it block my submission?
PrivacyInfo.xcprivacy is a required plist declaring: the collected data types (matching your privacy nutrition labels), tracking domains, and — the part that blocks builds — 'required-reason API' usage: declared reasons for APIs Apple considers fingerprint-capable (file timestamps, UserDefaults, disk space, system boot time, keyboard active input). If your code or a dependency touches a required-reason API without a declared reason, App Store Connect rejects the upload at processing time with ITMS-91053-style errors. Equally blocking: third-party SDKs on Apple's listed-SDK registry must ship their own privacy manifest AND be signed with a valid signature — an unsigned or manifest-less listed SDK fails the same way. The fix workflow: run a required-reason API scan, add reasons to your manifest, update listed SDKs to signed versions, and re-archive.
Why do apps get rejected under 5.1.1 beyond the account-deletion rule?
5.1.1 is Apple's data collection/storage guideline, and the common triggers are broader than 5.1.1(v): (1) data minimization — collecting data not needed for core functionality (requesting contacts, precise location, or health data 'for analytics' is a standing rejection); (2) forced registration — requiring account creation for features that don't inherently need an account; the rule is that account-free usage must work for anything not tied to server-side identity, and 'sign in to see the weather' fails; (3) missing or broken privacy policy — the link must resolve, cover your actual data practices, and match the nutrition labels; (4) purpose strings that don't explain WHY the data is used ('this app uses location' fails; 'to show nearby stores' passes). Reviewers test all four in the first session: they decline every permission and check the app still functions where it reasonably should.
The 5.1.1(v) account deletion requirement — implementation rules and exceptions
If your app supports account creation, deletion must be available IN-APP since 2022: a findable path (settings-level, not hidden in a web form), that initiates full deletion — not deactivation, not logout. Implementation rules reviewers test: deletion must complete without forcing the user to re-authenticate through extra barriers (a confirmation is fine; 'email support from your registered address' is not); the action must be real — test accounts they create during review must actually disappear, and a 'we'll delete within 30 days' holding pattern fails unless regulation requires retention. Exceptions are narrow: apps in highly regulated industries (banking, health records) may route deletion through a verified process, and accounts with legal retention duties (transaction records) may delete the profile while retaining mandated data — but this must be explained in the deletion UI. A web-link to a deletion page is acceptable only if it deletes, not if it opens a support ticket.