Which fields most often trigger an App Store 5.1.1 rejection on a registration form?

The common ones are City, State, Country, Birthdate, Phone Number, Gender, and any custom demographic question added during onboarding. Anything that asks for personal data beyond the credentials needed to authenticate the account counts as suspicious in App Review's reading. The reviewer flags fields the user is forced to fill in before reaching the app's main screen, not optional fields shown later.

Does making a required field optional satisfy Apple, or does the field need to be removed entirely?

Optional is usually enough. Apple's Guideline 5.1.1(iii) is about whether the app forces collection, not whether the field exists. A registration form that lets the user submit with the field blank passes the data minimization test, even if the field is still rendered. Removing the field is cleaner from a privacy perspective, but a Required toggle change is accepted for the App Review pass.

Do I need to upload a new build to App Store Connect after I make the fields optional?

Not in most cases. When the registration form is fetched from a server, like a Supabase or Firebase backend or a no-code builder API, changing the field schema on the server is enough. Reply in the Resolution Center, name the fields, and confirm the change is live. A new build is needed only when the form is hardcoded in the native binary.

What does Apple consider a legitimate reason to require a registration field?

Either the field is directly required for the app's core functionality, or it is required by law. A regional community legitimately needs City to scope the directory. An age-gated app legitimately needs Birthdate. A regulated marketplace may need Phone Number for two-factor. Marketing segmentation, audience research, and analytics do not pass the test, even when they are commercially useful to the team.

Is a 5.1.1(iii) rejection the same as a 5.1.1(v) Account Sign-In rejection?

They share a number but address different problems. 5.1.1(iii) is about data minimization on a registration form a new user has to fill in. 5.1.1(v) is about whether requiring login at all is allowed for the app's core features. Read the Resolution Center text closely; the sub-clause Apple cites tells you which fix to apply.

Will Apple accept a written Resolution Center reply, or does the reviewer want screenshots?

A written reply that names each field and states the change works for most server-driven registration forms. Reviewers may add screenshots if the fix is unusual. The reply should be short, factual, and list the fields by their visible label so the reviewer matches it to the screen they tested. Avoid arguing whether the field was important to the product.

How do I fix a 5.1.1 rejection for required registration fields?

You uploaded the build to App Store Connect, sat through the queue, and the Resolution Center came back with Guideline 5.1.1 and a short list of registration fields the reviewer wants removed or made optional. The rejection reads like a privacy policy violation. It is actually a data minimization one, and the fix is usually smaller than the message implies.

Short answer

The short answer is that Guideline 5.1.1(iii) lets Apple block any registration form that forces a new user to fill in fields not directly relevant to the app's core functionality. According to the App Review Guidelines on Data Collection and Storage, the rule reads, "Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task." Removing the flagged fields, or marking them optional in the form schema, is the standard fix. A new binary upload is often not required when the form is fetched from a server.

What you should know

5.1.1(iii) is about data minimization, not privacy policy URLs. Different sub-clauses, different fixes; read the Resolution Center text closely.
The reviewer names the fields. Apple's reply usually quotes the exact form labels, so the punch list is given.
Optional satisfies the rule. Apple accepts a field as long as the form does not block submit when the field is empty.
A new binary is often unnecessary. Server-driven registration schemas can change without a code update.
Defensible fields stay. Birthdate for age-gated content, City for a regional directory, Phone Number for two-factor: each can be defended in the reply.
Marketing and analytics fields fail the test. Demographic data collected for segmentation does not survive Apple's reading of "core functionality."
The App Privacy questionnaire must match. A 5.1.1 win that leaves stale Data Type declarations sets up a 5.1.2 rejection on the next pass.

What does a 5.1.1 registration form rejection actually say?

The short answer is that the Resolution Center message names the form labels the reviewer hit during the test pass. Typical text reads along the lines of, "your app requires users to register with personal information that is not directly relevant to the app's core functionality. Specifically, your app requires users to provide City, State, and Date of Birth before accessing the main interface." That quoted list is the working punch list for the fix.

The mechanism is Apple's reading of Guideline 5.1.1(iii). Per the App Review Guidelines section on Data Collection and Storage, the data minimization clause is enforced most strictly at registration, because that is where the user has the least negotiating room. A field that blocks submit is treated as forced collection, even when the same data could be edited later in a profile screen.

In practice, reviewers reach the registration form during the test account flow. If the form will not accept a submit until five demographic boxes are filled, the rejection is mechanical. The size of the field list in the rejection message correlates with how many blocking fields the reviewer encountered, not with how strict the reviewer is feeling that morning.

The limit is that the wording sometimes blurs into 5.1.1(v). According to the Apple Developer forum discussion on 5.1.1(v) account requirements, 5.1.1(v) is the rule that gates whether login itself is allowed at all for an app's non-account features. Read the citation carefully; the sub-clause Apple references decides whether the fix is field-level or screen-level.

Which registration fields most often get flagged?

The short answer is the demographic and contact fields that builders and templates often switch on by default: City, State or Region, Country, Birthdate or Date of Birth, Phone Number, Gender, and any custom item like Industry or Company. Email and password (or whichever credential the authentication backend uses) are accepted as core; almost everything else is suspect.

The mechanism is that Apple's reviewer applies a strict reading of "directly relevant." A regional events app might survive a City field. A general productivity app will not. A health-tracking app might survive Birthdate. A photo editor will not. The test sits inside those two words, and the burden of proof rests on the developer to write the defense into the reply.

For a sense of scale, the 2024 NowSecure Mobile Security Report found that the majority of analyzed mobile apps over-collected personal data relative to declared purposes, a pattern Apple reviewers see at scale. The rejection is a pattern enforcement, not a single-app oddity.

In practice, six fields show up in 5.1.1 rejection messages more than any other:

Field	Defensible when...	Usual fix
City / State	The app is region-scoped (events, marketplace, directory)	Mark optional unless region scoping is in the binding
Birthdate	Age gating is required by an age rating, alcohol, or COPPA constraint	Keep required, declare in App Privacy and policy
Phone Number	Two-factor or a regulated identity flow needs it	Move to a post-sign-up settings flow if not blocking
Gender	A health, fitness, or insurance feature actually uses it	Mark optional; add "prefer not to say"
Country	Tax, shipping, or compliance routing depends on it	Use device locale instead of a required field
Industry / Company	A B2B feature requires routing on segment	Move to optional onboarding survey after sign-up

The limit is that "defensible when" still means defensible in the Resolution Center reply, not implicit in the build.

Where in the app or backend do you fix the form?

The short answer is on the layer that defines the form schema, not in the native binary. For most no-code builders (FlutterFlow, Bubble, Adalo, BuddyBoss), the registration schema is configured in the builder dashboard or in the connected backend (Supabase, Firebase, a WordPress install). For Expo, React Native, and Flutter apps fetching a profile schema from an API, the change happens on the server endpoint.

The mechanism has three small steps. First, identify the source of truth: open the registration screen in the app, find which API call returns the field list, and trace it back to the schema. Second, change the Required flag on each flagged field, or remove the field entirely if there is no plan to ever ask for it. Third, redeploy the schema; for most setups this is a single save or a single API publish, no rebuild needed.

According to the Supabase documentation on managing user data, profile fields stored in auth.users or a linked profiles table can be marked optional at the column level, so the registration handler accepts an insert with the column null. The same pattern applies to Firebase Authentication custom claims and to most no-code builder data tables.

In practice, the trap is hardcoded validation. A required attribute on an <input> tag inside a native form, a Yup schema in a React Native screen, or a "field cannot be empty" check inside a FlutterFlow custom action will keep blocking the user even after the database schema is relaxed. Inspect the form code, not just the schema, before claiming the change is live.

The limit is that some apps will need a rebuild. A native registration screen with field requirements baked into the binary cannot be fixed with a Resolution Center reply; the new build has to ship through App Store Connect.

How should the Resolution Center reply read?

The short answer is short and factual. Name each flagged field, state what changed (removed or made optional), and confirm the change is live on the backend the app talks to. Skip the argument about whether the field mattered. The faster the reply reads as a clean punch-list response, the faster the next pass clears.

A reply pattern that works in practice reads along these lines: "Thank you for the feedback. The registration form has been updated. The following fields are now optional: City, State, Date of Birth. The change is live on the backend the app connects to and takes effect on the next sign-up flow. No new binary is required."

If a field is genuinely required for core functionality, name the function and the legal or product reason in the same paragraph. A line such as, "The Date of Birth field is required because the app applies an age gate at 17 plus per the App Store age rating," gives the reviewer enough to clear the rejection without a follow-up round.

What to watch out for

Three traps appear in almost every 5.1.1 registration fix cycle.

The first is the App Privacy questionnaire. According to Apple's documentation on App Privacy details on the App Store, each Data Type the app collects has to be declared with the correct use category, the correct linkage to identity, and the correct tracking flag. A field made optional is still a field collected when the user fills it in, and the declaration in App Store Connect has to reflect that. A clean 5.1.1 win that leaves the privacy declaration stale invites a 5.1.2 rejection on a later submission.

The second is the privacy policy linked from the App Store listing. The policy text has to match the field list. If the registration form no longer asks for Birthdate but the policy still names it as collected at sign-up, the reviewer is reading inconsistent disclosures, which triggers its own follow-up question.

The third is the assumption that login itself is the problem. A 5.1.1(iii) rejection on field minimization is not the same as a 5.1.1(v) rejection on whether login is allowed for non-account features. Treating one as the other leads to rewriting the wrong screen. Cross-check the sub-clause Apple cites against the rejection text before changing anything on the sign-in flow.

Key takeaways

Read the sub-clause in the Resolution Center message: 5.1.1(iii) is a field-level fix, 5.1.1(v) is a screen-level one.
Apple accepts either optional or removed; both pass the data minimization test under 5.1.1(iii).
Server-driven registration forms can usually be fixed without a new binary upload to App Store Connect.
Defensible required fields need their defense written into the Resolution Center reply, not left implicit in the form.
For builders who want an outside read on what personal data their compiled build is actually collecting before the next submission, PTKD.com (https://ptkd.com) is one platform focused on pre-submission scanning aligned with OWASP MASVS for no-code and AI-coded apps.