Your app got rejected for Guideline 5.1.1 with the reviewer specifically pointing at your registration form, asking why it collects fields a free app does not actually need. The note typically names city, state, country, full address, or date of birth. The fix is rarely structural. Most of the time it is a metadata change you can ship without rebuilding the binary.
Short answer
Guideline 5.1.1 rejections that flag registration form fields fall under section (iii), Data Minimization, of Apple's App Review Guidelines on Data Collection and Storage. Apple expects each field on the sign-up screen to map to a feature the app actually delivers. Remove every required field that does not justify itself, make the rest optional, then reply through App Store Connect Resolution Center describing the change. A new binary upload is usually not required.
What you should know
- The rejection points at data minimization, not your privacy policy. Section (iii) of 5.1.1 says apps should only request data relevant to core functionality.
- City, state, and date of birth are the most flagged fields. Apple cites them when the app has no shipping, no localization that depends on a region, and no age-gated content.
- Optional is enough in most cases. Apple allows the field to remain visible if it is genuinely optional and the form submits without it.
- The reply is usually a metadata change. No new IPA upload is needed if the requirement is server-side or controlled by a remote flag.
- The reviewer rechecks the same screen. If a field returns to required on resubmission, the same clause fires again.
Why does Apple flag registration form fields under Guideline 5.1.1?
The short answer is that 5.1.1 owns disclosure and minimization, and registration is the first place a reviewer can audit both.
Section (iii) of Apple's App Review Guidelines sets the rule: apps should only request access to data relevant to the core functionality of the app and only collect what is required to accomplish the relevant task. The reviewer opens the sign-up screen, lists every required field, and asks whether each one ties to a feature on the screen later. If a meditation app collects birthdate without an age-gated flow, that field fails the minimization test.
This matters because the bar is per field. A reviewer who finds three non-essential required fields does not need to argue the philosophy of data collection. They send the rejection naming the fields and quote the clause. The fix is then narrow: remove the fields, or move them behind an optional flag and verify the form submits without them populated.
Which fields commonly trigger the rejection?
The short answer is any field that asks for data the app does not visibly use.
The Apple developer forum thread on Guideline 5.1.1 account registration is one of the more cited examples, where a reviewer required the developer to drop a forced sign-up before access to non-account features. The pattern repeats across thousands of rejections, with a small set of fields appearing again and again.
| Field | Allowed when | Flagged when |
|---|---|---|
| City | App uses location for local content or shipping | Field has no downstream use; data sits unused in the database |
| State or province | Tax, regional pricing, or compliance reason | App is global with the same content everywhere |
| Country | Required by GDPR-style consent flows | No region-specific behavior in the app |
| Full address | Physical goods shipping, in-person services | Digital-only product with no delivery |
| Date of birth | Age-gated content, regulated services (5.1.1 ix) | App has no age check, parental controls, or restricted feature |
| Phone number | OTP verification, two-factor login, call routing | Field is collected without any SMS or call code being sent |
| Gender | Personalization the user picks and can change | Asked at sign-up with no visible effect on the experience |
| Postal code | Local search, sales tax | Decorative or analytics-only use |
The line is not whether the data feels sensitive. It is whether the app, as the reviewer sees it, uses the field. A field that the backend stores but the UI never references reads as collection without purpose.
How do I fix this without uploading a new binary?
The short answer is server-driven flags and Resolution Center text.
For builds that source field requirements from a feature flag or a remote config, the change is metadata-only. Toggle the required flag off, redeploy the backend, then reply to the rejection in App Store Connect Resolution Center. A typical reply reads:
City, State, and Date of Birth are now optional on the registration screen. These fields are no longer required for account creation and the form submits without them.
Apple's reviewer usually retests the same build, sees the change, and approves it. The submission status moves from In Review with the rejection back into review without a new binary processing cycle.
If the field requirements are baked into the compiled bundle and a remote toggle does not exist, the change costs a build. Update the form validation in the client, remove the asterisks in the UI, and resubmit. Apple's documentation on offering account deletion in your app is worth bookmarking at this point, because account deletion is the other clause 5.1.1 enforces alongside data minimization, and the next reviewer often checks both together.
Do I have to delete the field, or only make it optional?
The short answer is optional is enough as long as the form genuinely submits empty.
Section (x) of Guideline 5.1.1 is specific: apps may request basic contact information so long as the request is optional for the user, features and services are not conditional on providing the information, and the request complies with all other provisions of the guidelines. The clause names name and email address as the canonical example, but the same logic applies to softer fields like postal code or gender.
The honest answer is that a field marked optional on the screen but rejected by the server when blank reads as required, and reviewers test this. The verification path is the same one the reviewer takes: fill out the form with only the truly required values (commonly email and password), tap Sign Up, and confirm the account is created. If the request returns a 400 because city is missing, the field is still required regardless of the absence of an asterisk.
For builders who want an external read of their compiled build against OWASP MASVS and Apple's privacy disclosure clauses before resubmitting, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning of AI-coded and no-code builds. The report flags fields collected by the binary that map to permission categories or to privacy nutrition label entries, which is the same surface the reviewer compares against the form.
What should the Resolution Center reply look like?
The short answer is short, specific, and naming the fields by their visible labels.
A reply that just says the issue has been addressed tends to bounce back. Apple's review team reads dozens of replies a day and the ones that move fastest name the field, the clause, and what changed. A template that works:
Thank you for the feedback under Guideline 5.1.1. The registration form previously required City, State, and Date of Birth, none of which are used by the app's current features. City and State have been removed from the form and from server-side validation. Date of Birth remains visible but is now optional, and account creation completes without it. The change is live in the current build and can be verified on the sign-up screen.
The reply names the clause, names the fields exactly as the reviewer sees them, and ends with a verification step. Three short paragraphs is plenty. Avoid arguing the clause; reviewers are not the audience for that, and the appeal path runs through a separate App Review Board request.
What to watch out for
The first trap is collecting the data anyway through analytics. If a field is removed from the visible form but the same data point is still gathered through a tracker or a profile enrichment call, the privacy nutrition label still has to declare it. The reviewer can compare the label to the form, and a label entry without a visible collection point invites a follow-up.
The second trap is hiding fields behind a third-party login button. An app that asks the user to sign in with Apple, Google, or a social provider and then pulls birthdate, phone, or address from the provider's profile is still collecting that data. Section (v) of 5.1.1 explicitly excludes pulling basic profile information from the definition of core functionality, so this path does not solve the rejection. The fields need to be unnecessary, not just relocated.
The third trap is region-gating the requirement. Some apps require a postal code only for users in certain regions, hoping the reviewer is in a region where the field is hidden. Apple reviewers test from multiple regions, and a field that fires in one region but not another tends to surface during retest.
The fourth trap is the regulated-fields carve-out in 5.1.1 (ix). Banking, financial services, healthcare, gambling, legal cannabis, air travel, and crypto exchanges have a separate KYC bar and can require more identity data, but only when the developer is a legal entity providing those services. A consumer wellness app that collects identity data on the strength of being health-related, without operating as a regulated provider, fails both clauses at once.
Key takeaways
- Guideline 5.1.1 rejections that name registration form fields fall under section (iii), Data Minimization. Each required field should trace back to a feature the user reaches inside the app.
- City, state, country, full address, date of birth, phone number, gender, and postal code are the fields reviewers flag most often when they sit on the sign-up screen without a feature behind them.
- Optional is allowed when the form genuinely submits without the field. A server that rejects an empty field reads as required regardless of UI styling.
- The reply through App Store Connect Resolution Center names the clause, names the fields by their visible labels, and ends with a verification step the reviewer can repeat in under a minute.
- Some teams pair the registration audit with an external pre-submission scan. PTKD.com (https://ptkd.com) is one of the platforms focused on automated scanning of compiled mobile builds against OWASP MASVS and Apple's privacy disclosure clauses before they reach App Store Connect.
