Guideline 5.1.1 Data Collection and Storage: how to fix the rejection

What Guideline 5.1.1 actually requires

Guideline 5.1.1 is the part of Apple's privacy rules that deals with collecting data: what you ask for, how you ask, and how you tell people about it. It has ten sub-clauses, (i) to (x), and the rejection message doesn't always say which one you failed. Apple marks it as part of Notarization Review too, so it also applies to notarized iOS and iPadOS apps distributed through alternative app marketplaces or the web, where that is available. These sub-clauses come up most often in 5.1.1 rejections:

Account deletion is also part of 5.1.1(v) but has its own playbook: see our 5.1.1(v) account deletion guide. Tracking, ATT and sharing data with third parties fall under Guideline 5.1.2.

Common reasons apps get rejected under 5.1.1

1. Purpose strings that don't explain anything

"This app needs access to your camera" or "Location is used to improve your experience" are classic triggers: they name the resource but not what the app does with it. Apple's Human Interface Guidelines use "Microphone access is needed for a better experience." as an example of a vague justification. Generic plugin defaults such as Allow $(PRODUCT_NAME) to access your photos fall into the same bucket.

2. Permissions for features the reviewer can't find

A NSContactsUsageDescription or NSBluetoothAlwaysUsageDescription key without a visible feature behind it raises questions. Often a third-party SDK references the API. Apple is explicit that you are responsible for all access to protected resources, including SDK access.

3. Forcing or nudging people to grant access

• Permission prompts fired at launch or as a mandatory onboarding step without context.
• A pre-permission screen whose button says "Allow" or something similar, or that offers "Not Now" or a close button so users can skip the system alert. Apple's Human Interface Guidelines advise against both, and developers on the Apple Developer Forums have reported 5.1.1 rejections over "Enable" and "Not Now" buttons.
• Blocking the app or a paid feature until users grant access the feature doesn't need.
• Screens that pressure users who tapped "Don't Allow" to reconsider.

4. Registration required for non-account features

A login wall in front of a recipe browser or meditation timer gets flagged under 5.1.1(v). A common variant: requiring registration with personal information before buying an in-app purchase that isn't account-based.

5. Unnecessary personal data or a weak privacy policy

Mandatory phone, birthday or gender fields the app doesn't need, no privacy policy link inside the app, a URL that errors or requires login, or a template policy that never mentions your SDKs, deletion or withdrawing consent.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a 5.1.1 rejection step by step

1. Pin down the exact issue. Note the resource or screen named in the rejection ("camera purpose string", "requires users to register") and any attached screenshots. If it's ambiguous, ask App Review before changing everything.
2. Inventory every permission in the build. Check the target's Info tab and search Build Settings for INFOPLIST_KEY_NS (Xcode stores purpose strings added in the editor as build settings like INFOPLIST_KEY_NSCameraUsageDescription). Then inspect the archived app, because plugins and build scripts can add keys: plutil -p MyApp.xcarchive/Products/Applications/MyApp.app/Info.plist | grep UsageDescription. Map each key to a feature.
3. Remove what you don't use. Delete unneeded keys together with the code or SDK modules that reference the API. If an SDK still references the API, Apple flags the upload with ITMS-90683 (missing purpose string). Use PHPickerViewController / PhotosPicker for photos and CNContactPickerViewController for contacts: they run out of process and need no permission prompt. Prefer "When In Use" location over "Always". For one-off location needs, Core Location's location button grants temporary access when the user taps it.
4. Rewrite the remaining purpose strings as data + purpose + concrete example (see below), in every localization (InfoPlist.xcstrings or InfoPlist.strings).
5. Ask at the moment of need. Trigger the system alert when the user taps the feature, not on first launch, unless the app can't function without it. A pre-permission screen, if you keep one, should have a single "Continue" or "Next" button that opens the alert, with no "Allow" wording and no cancel or close option, per Apple's Human Interface Guidelines.
6. Handle "Don't Allow" gracefully. Keep the app usable, offer an alternative such as manual address entry, and at most show a neutral hint with a button to UIApplication.openSettingsURLString.
7. Remove unnecessary login walls and fields. Add a guest mode for non-personal features. Let users buy non-account-based in-app purchases without an account, offer Restore Purchases via StoreKit for non-consumables and subscriptions, and explain that optional registration adds access on other devices. Make extra sign-up fields optional.
8. Fix the privacy policy. Host it on a publicly accessible page (no login, ideally HTTPS) and enter it in App Store Connect: Apps → your app → App Privacy in the sidebar, then Edit next to Privacy Policy. Link it inside the app where people can easily find it, for example in Settings or About and on the sign-up screen. Make sure it covers what you collect and why, third parties such as analytics and ad SDKs, retention and deletion, and how to withdraw consent.
9. Re-check your App Privacy answers. Apple expects you to disclose data collected by you and your third-party partners. In Xcode, Control-click the archive in the Organizer and choose Generate Privacy Report to combine the privacy manifests of your app and its SDKs. Compare that report with your answers and new purpose strings, then click Publish. SDKs without a privacy manifest won't appear in the report, so check those by hand.
10. Ship a new build with a new, higher build number and explain the changes in your reply and the review notes.

Purpose strings that fail vs. pass review

Apple's Human Interface Guidelines ask for a brief, complete sentence that is "straightforward, specific, and easy to understand", in sentence case, without passive voice and ending with a period. Apple's developer documentation adds that the string must be "accurate, meaningful, and specific" about why the app needs access. Both microphone strings in the "likely to fail" column are Apple's own examples of weak purpose strings from the HIG:

Only state what is true. If a string says data stays on the device while an SDK uploads it, a 5.1.1 rejection becomes the smaller problem. The contacts example above names the server-side matching openly for that reason. If you only need a few contacts, use the contact picker, which needs no permission. Also check what you show after a denial: a developer on the Apple Developer Forums reported that a purpose-string rejection was actually about the in-app message shown after "Don't Allow", and was resolved by making that message clearer.

Flutter, React Native, Expo and SDK pitfalls

• Flutter: Purpose strings go in ios/Runner/Info.plist. With permission_handler, enable only needed permissions via the GCC_PREPROCESSOR_DEFINITIONS macros in the Podfile's post_install block (e.g. PERMISSION_CAMERA=1). Its docs warn that a permission declared only in a dev flavor's Info-dev.plist is still compiled into the production binary and can trigger ITMS-90683. The package documents a permission_handler.yaml file that maps each flavor to its own plist.
• React Native: Edit ios/[AppName]/Info.plist. With react-native-permissions, list only the handlers you use in setup_permissions([...]) in the Podfile and run pod install again.
• Expo: Set strings in app.json under ios.infoPlist or via config plugin options. Expo's docs note the default messages will most likely need tailoring for App Store approval, and Info.plist changes need a new native build, not an over-the-air update.
• WebView apps: Camera, microphone or location requests from web content in a WKWebView still need native purpose strings, and those strings should describe the web feature that uses them.
• SDKs: If an upload triggers ITMS-90683: Missing purpose string in Info.plist for an API you never use, an SDK probably references it. Apple says a purpose string is still required in that case. Remove the SDK module, ask the vendor for a build without the API, or add an accurate string. Privacy manifest warnings are covered in our ITMS-91053 guide.

When login, permissions or data are legitimately required

5.1.1 doesn't ban login walls or permissions, only unnecessary ones. You can push back when the requirement is core:

• Account-based apps (banking, messaging, team tools, employer-provisioned accounts) may require login. Explain why and add a demo account under App Review Information, or risk a 2.1 Information Needed request.
• Social login: unless your core function depends on a specific social network, offer access without it, plus an in-app way to revoke the connection.
• Permission-centric apps: Apple's HIG accepts a request at launch when the app can't function without the resource and the reason is obvious, using a navigation app that needs location as its example. The purpose string still has to be specific.
• Regulated fields listed in 5.1.1(ix), such as banking and financial services, healthcare, gambling or crypto exchanges, and apps that need sensitive user information, should be submitted by the legal entity that provides the service, not by an individual developer.

How to respond to App Review

Reply in the App Review section of your app's page in App Store Connect. List each point, what you changed, the new purpose string text and the taps needed to see it. A short screen recording of the permission flow, including the "Don't Allow" path, helps.

• New build required: purpose strings, permission timing, pre-permission screens, sign-up and guest flows, the in-app privacy policy link.
• No new build needed: the Privacy Policy URL in App Store Connect can be edited while the version is in an editable status such as Rejected. The change goes live with that version. App Privacy answers can be updated and published at any time without an app update.

If the reviewer misunderstood your app, for example by missing why an account is essential, explain that in your reply first and answer any open questions. If that doesn't work, you can file one appeal per rejected submission with the App Review Board, giving specific reasons why your app complies with the guidelines.

How to prevent 5.1.1 rejections next time

• Permission allowlist in CI: after archiving, extract all *UsageDescription keys from the built Info.plist and compare them to a list in your repo, so a plugin or SDK update that adds a permission fails the pipeline instead of the review.
• String quality gate: fail the build if any purpose string, in any localization, is empty, very short or uses phrases like "needs access" or "better experience".
• Privacy policy check: verify the URL returns HTTP 200 without login and matches the in-app link.
• Manual walkthrough: install the release build fresh, decline every permission, skip registration and confirm the app stays usable.

AI-assisted checks help compare purpose strings with the code that accesses each resource and draft App Privacy answers from your dependency list, but a human should confirm the result. For a second opinion, book a free consultation call; appsubmitter.io can also add these checks to your CI/CD pipeline and handle submission and review communication via the order wizard. Code changes are not included and are discussed and quoted upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App Name], version [x.y] (build [build number]). We have addressed the Guideline 5.1.1 issues:

1. Purpose strings: [NSCameraUsageDescription / other key] now reads: "[new purpose string]"
2. Permission flow: [Camera / Location] access is requested only when the user taps [feature]. If access is declined, the app keeps working and offers [alternative].
3. Registration: [Features] are available without an account. An account is optional and only needed for [account-based features].
4. Privacy policy: Available at [URL] and linked in the app under [Settings > Privacy Policy].
5. App Privacy: Our App Privacy details now reflect [change].

To verify: [step-by-step path to the changed screens]. [Optional: screen recording attached.]

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Every UsageDescription key in the built Info.plist, in all localizations, says what is accessed, why, with a concrete example.
• No purpose string remains for a resource that neither your code nor any SDK uses.
• Permissions are requested when the related feature is used, not at launch, unless the app cannot work without them.
• Any pre-permission screen has one "Continue" or "Next" button that opens the system alert, without "Allow" wording or a cancel option.
• Declining each permission leaves the app usable, with an alternative path.
• Non-account features and non-account-based in-app purchases work without registration.
• Sign-up asks only for data a feature needs; other fields are optional or removed.
• The privacy policy URL is publicly accessible without login, is entered in App Store Connect and linked inside the app, and covers collection, third-party sharing, retention, deletion and withdrawing consent.
• App Privacy answers match what the app and every SDK collect (checked against the Xcode privacy report and SDKs without a manifest), and are published.
• Review notes explain where to find each change and include a demo account if login is still required.

Frequently asked questions

Official source: App Store Review Guidelines – 5.1.1 Data Collection and Storage. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.