Guideline 5.1.1: Understand and Fix an App Store Rejection

Guideline 5.1.1 is Apple's rule on data collection and storage. I've had three rejections from this family, and each time the cause was one of two gaps: what the app did with data didn't match what was declared, or the permission request pushed the user to say yes.

This article covers this one rule only: its clauses, what I check before submitting and what to fix, with three rejections I got on my own apps. For the big picture of every rejection reason, read why Apple rejects an app instead.

What is guideline 5.1.1?

Guideline 5.1.1, "Data Collection and Storage", sets what an app must respect as soon as it touches personal data: a complete privacy policy, consent before collection, honest permission requests and an account you can delete. It applies to every app, even the ones that collect almost nothing.

The official text is in the App Review Guidelines, section 5 "Legal", part 5.1 "Privacy". Apple's message often cites a specific clause in parentheses: 5.1.1(i), 5.1.1(iv), 5.1.1(v). That clause tells you where to look.

The five 5.1.1 clauses to know first

Clause	What Apple requires	Typical rejection
5.1.1(i) Privacy Policies	Complete, linked policy	Missing or incomplete
5.1.1(ii) Permission	Consent before collection	Vague permission text
5.1.1(iii) Data Minimization	Only the data you need	Full photo library access
5.1.1(iv) Access	Don't push users to accept	Screen that pushes to accept
5.1.1(v) Account Sign-In	No forced account	Mandatory sign-in

Three clarifications. The privacy policy is linked in App Store Connect and in the app. It says what data is collected, how and why, confirms that any third party receiving it offers the same protection, and explains how to withdraw consent or get data deleted. A paid feature can't depend on access to data the user is free to refuse. And an account created in the app must be deletable from the app.

The rule has more clauses, (vi) to (x), for more specific cases like regulated fields or compiling personal data.

The three things I compare before submitting

I don't have the reviewer's playbook. Here's what I compare myself before every submission, because my rejections came from a gap between these:

• what the online policy says, at the URL declared in App Store Connect;
• what the app actually does, screen by screen, including every permission request;
• what's declared on the listing, in the app privacy section (App Privacy Details).

I also test every permission screen by closing the app and relaunching it. That's the cause I identified for my second rejection on Nolera.

Three 5.1.1 rejections I got, and their real cause

Clic: the online policy was the old version

Clic turns a product into ready-to-post slides, with AI. On September 16, 2026, Apple rejected the app citing 5.1.1(i) and 5.1.2(i). The AI consent screen was in the app. The problem was outside the app: the privacy policy published on the website was the old version. The new one existed, but it hadn't been put online.

The fix: full policy published, an English summary added for the reviewer, review notes updated. I didn't make a new build: I resubmitted the same submission.

The lesson: Apple reads what's online, not what's in your repo. On submission day, open your policy URL and search for the name of every third-party service your app uses.

Nolera: an "Allow" button before the system request

Nolera is my wardrobe app. On September 17, 2026, after a review on iPad Air, Apple cited 5.1.1(iv). Before the camera access request, the app showed an explanation screen with an "Allow the camera" button.

Apple's design rules are precise on this. A custom screen shown before a system request must have only one button, which opens that request. Apple recommends a word like "Continue" or "Next", not "Allow": a button that looks like the system one pushes people to tap the real "Allow" afterward without meaning to.

This rule targets screens shown before a system request: camera, microphone, location, contacts, calendar, tracking. It leaves one exception, for consent required by law.

The fix: the button now says "Continue", in all 8 of the app's languages.

The lesson: a screen that prepares a permission explains. It doesn't decide for the user.

Nolera, second rejection: the "camera denied" screen showed before the request

Resubmitted, Nolera was rejected a second time on September 22, 2026, again under 5.1.1(iv), this time on an 11-inch iPad Pro. Apple flagged two things: a link to Settings before the access request, and a screen you could leave without ever seeing that request.

The cause I identified: a case I hadn't tested. The capture screen showed its "camera denied" panel, with the link to Settings and a fallback option, whenever access wasn't granted. Including when it had never been requested. In the normal flow, the explanation screen came first and everything was fine. But if you closed the app midway and relaunched it, you landed straight on the capture screen, without having seen the system request.

The fix: as long as iOS can still ask the question, the screen triggers the system request itself. The "camera denied" panel only appears after a real denial. This fix required a new build, since the reviewer tests the shipped code.

The lesson: "never requested" and "denied" are two different states. Test every permission screen by coming back to it after closing the app, not just in flow order.

5.1.1 and AI: what 5.1.2(i) adds

On Clic, Apple cited 5.1.2(i) on top of 5.1.1. This rule asks you to clearly disclose where personal data is shared with third parties, and it explicitly names third-party AI. It also requires explicit permission before sharing.

My practice since that rejection: three things that match each other.

• A consent screen in the app, before the first upload, saying which service the data goes to and which data.
• The same information in the online privacy policy.
• The same information in the listing's privacy declarations.

The details of what the policy must contain are in privacy policy for an app.

How to reply to Apple after a 5.1.1 rejection

The conversation happens in your app's App Review section in App Store Connect. The official procedure to reply to App Review is the same as for other rules. Write in English, keep it plain: what the problem was, what changed, how to verify it. Here's the template I use (replace the build number and fix with yours):

Hello,

Thank you for your review.

Issue: the custom screen shown before the camera permission
request used an "Allow" button, and the "camera denied" panel
could appear before the system alert had ever been shown.

Fix in build X:
- The custom screen now has a single "Continue" button that
  opens the system alert.
- The "camera denied" panel only appears after the user has
  actually denied access in the system alert.

How to verify: delete the app, install this build, launch it
and go to the photo step. The system alert appears first.

Best regards,

There are two cases:

• The cause is online (policy, support page, listing declarations): you fix it, reply, and the same submission can go back without a new build.
• The cause is in the app (screen, button, request order): you need a new build. A remote update isn't enough, as I explain in the guide on guideline 2.1.

The 5.1.1 checklist before submitting

• Your privacy policy URL opens, and the online page is the latest version.
• The policy names every third-party service that receives data, AI included. That's my rule, stricter than Apple's text.
• Your listing's privacy declarations say the same thing as the policy and as the build's privacy manifest.
• Every permission text explains the use in one precise sentence.
• No permission is requested at launch if the app can work without it. Same logic for background modes: no mode declared without a feature that uses it.
• A custom screen before a request has only one button, "Continue", which opens the system request.
• Someone who denies a permission can continue another way, or understands what they lose.
• The "access denied" screen only appears after a real denial. You tested it by closing and relaunching the app.
• The app works without an account when an account isn't essential.
• An account created in the app can be deleted from the app: the recipe is in iOS account deletion.
• Everything is tested on iPad too: both my 5.1.1 rejections on Nolera were flagged on iPad.

Fix your rejection with someone who's already been through it

If your app just got rejected under 5.1.1, the Apple Review Kit helps you find the cited rule, what it requires, and an example fix and reply. If you want us to look at your case together right now, book an hour with me on video. The full approach is also on the app rejected by Apple page.

If you're preparing your first release, take the free diagnostic: it puts your steps back in order and sends you my Apple anti-rejection checklist, privacy included. To build your mobile app designed for review from day one, the four-step path in the iOS Kit takes you from idea to submission to Apple.

Nobody can guarantee Apple will accept your app. What I can do is help you avoid the 5.1.1 rejections I've already paid for with a review cycle.

Frequently asked questions

What does "Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage" mean?

That's the full title of the rule in Apple's message. It flags a personal data problem: incomplete privacy policy, a permission request judged pushy, or an account that can't be deleted. The clause in parentheses, for example 5.1.1(iv), tells you which one.

Do I need a new build after a 5.1.1 rejection?

Not always. If the cause is online, like a privacy policy that isn't up to date, you fix the page, reply to Apple and the submission goes back without a new build. If the cause is a screen or button in the app, you need a new build.

Can I show an explanation screen before a permission request?

Yes, Apple allows it when it's genuinely useful. The screen then has only one button, which opens the system request, with a word like "Continue" or "Next". No "Allow" button, no button to close or skip, except for consent required by law.

My app uses an external AI: what do I need to declare?

Guideline 5.1.2(i) asks you to disclose where data is shared with third parties, AI included, and to get explicit permission first. I apply it in three places: a consent screen in the app, the online privacy policy, and the listing's privacy declarations. On Clic, Apple cited this rule along with 5.1.1.

Is an account required to comply with 5.1.1?

No, it's the opposite. If your app has no feature that truly relies on an account, Apple asks you to keep it usable without sign-in. And if it lets people create an account, it must also let them delete it from the app.