If your build came back with Resolution Center text quoting "required fields not relevant to core functionality" and a list that reads city, state, birthdate, the rejection is the standard Guideline 5.1.1 over-collection pattern, and a BuddyBoss-powered community app is one of the most common places it shows up. The fix lives in the BuddyBoss Platform Profile Fields screen, not in a code change or a new binary upload.
Short answer
Guideline 5.1.1 rejects a BuddyBoss registration form when it asks users for personal data that the core community feature does not need. The remediation is to open BuddyBoss Platform > Profiles > Profile Fields in the WordPress admin, edit each non-essential field, and uncheck Required. Republish, retest the signup flow on a fresh device, and reply in App Store Connect Resolution Center stating that the fields are now optional. A new binary upload is usually not needed for the change to clear.
What you should know
- Guideline 5.1.1 is the Data Collection and Storage clause that prohibits requiring personal information beyond what the core feature needs, in the App Review Guidelines.
- BuddyBoss exposes the registration form through xprofile, the same data layer BuddyPress uses, configured under the Profiles menu in WordPress admin.
- The fields that trigger rejection most often are birthdate, city, state, gender, and phone number, the exact list reproduced in BuddyBoss's own Guideline 5.1.1 resolution doc.
- The fix is usually a setting change, not a patch or a binary rebuild; the reviewer tests the live signup against the WordPress backend the app calls.
- A privacy policy edit is only needed when the policy itself names the removed fields by category.
- The xprofile required flag applies to both the in-app form and the website form, so the test surface for review can be the public website.
What exactly does App Review test when 5.1.1 hits a BuddyBoss build?
The 5.1.1 test on a BuddyBoss app is a live signup attempt. The reviewer launches the build on a clean device, taps Sign Up, and tries to reach the main community feed without filling fields that look unrelated to the core feature. When the form refuses to submit because Birthdate or City is empty, the rejection is written, and the Resolution Center reply quotes the exact field names.
The clause being applied is part (iii) Data Minimization of Guideline 5.1.1, which states that apps should only request data relevant to core functionality, plus part (v) Account Sign-In, which says apps cannot require personal information except when directly relevant to that core feature. The two sub-clauses are read together, and the rejection message usually lists the fields by name.
What makes BuddyBoss apps a recurring target is the default behaviour of the xprofile component. Profile Fields added through BuddyBoss Platform appear on registration by default, and the Required toggle is set per field. A site admin who marks Birthdate as required because the website tracks birthdays has unknowingly created an App Store rejection condition the next time the mobile build is submitted.
Which BuddyBoss profile fields trigger a 5.1.1 rejection?
The table below covers the fields that show up most often in 5.1.1 Resolution Center replies for BuddyBoss apps, the trigger condition, and the pattern that has cleared review in recent submissions.
| Field | Triggers rejection when | Safer pattern |
|---|---|---|
| Birthdate | Required at signup for a community with no age-gated content | Optional, or asked only when an age-restricted area is entered |
| City | Required at signup for a community or membership app | Optional, or asked when a location-tagged action is taken |
| State or region | Required for browsing, posting, or messaging | Optional, or asked at checkout for a paid membership |
| Phone number | Required for account creation in a community app | Optional 2FA after the account exists |
| Gender | Required outside a health, fitness, or dating context | Optional with a prefer-not-to-say choice |
| Full legal name | Required for a content or community app | Display name only, with legal name asked at invoice |
| Home address | Required before reaching the main feature | Asked only at checkout or shipping |
The pattern in the right column is consistent: move the field behind the action that actually needs it, or make it optional with a clear label. The trigger column is what App Review reads as the app gating the core community feature behind personal data collection.
How do I make a BuddyBoss xprofile field optional?
The setting lives in the WordPress admin under BuddyBoss Platform > Profiles > Profile Fields. Each field has a Required checkbox in its edit screen, separate from the field type and the visibility rules. Unchecking Required is enough to clear the validation on both the website form and the in-app form, because the app calls the same WordPress backend.
The sequence is:
- Sign in to the WordPress admin for the site the BuddyBoss app points at.
- Open BuddyBoss Platform > Profiles > Profile Fields.
- Click each non-essential field in turn (Birthdate, City, State, Gender, Phone Number) and uncheck Required in the right sidebar.
- Update the label to add (optional) so the reviewer sees the change on the form itself.
- Save each field, then clear the site cache if a caching plugin is active.
- Open the public registration page in a private browser window and confirm the form submits with those fields blank.
- Open the same registration in the mobile app on TestFlight or a sideloaded build and repeat the test.
If a third-party plugin extends the registration form (custom membership plugins, marketplace add-ons, course platforms), the same Required attribute usually exists in that plugin's settings or has a filter hook that overrides the xprofile flag. The BuddyBoss profile fields documentation covers the field-type and visibility model, and is the right reference when the field appears in the form but not in the Profile Fields list.
For builders who want an external automated read of the compiled IPA before resubmitting, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning of community-app bundles for over-collection patterns, undisclosed SDKs, and the Privacy Manifest gaps that often surface alongside a 5.1.1 reply.
What should the Resolution Center reply look like for a BuddyBoss app?
The reply is metadata-only in most 5.1.1 cases. Apple does not need a new build to verify a registration form change, because the app talks to the live WordPress backend the reviewer can hit from the same form. The reply in App Store Connect Resolution Center should state the change in plain language, name the fields, and offer to demonstrate the new signup flow on the same build under review.
A reply that has cleared review in BuddyBoss cases reads roughly like this: "Thank you for the feedback. The Birthdate, City, State, and Phone Number fields are now optional in the registration form. They are still available for users who want to fill them in, but the form accepts submissions without them. The change is live on the site the app points at, so the new flow can be tested directly from the build under review."
Two notes on phrasing the reply. First, avoid promising future changes; the reviewer is checking whether the build under review now passes. Second, do not claim to have removed the fields when they are still present but optional, because the next reviewer pass may read both the form and the policy together and flag the inconsistency.
Do I need to update the privacy policy after removing required fields?
A policy edit is only needed when the policy itself names the removed categories. If the existing text says the developer collects city, state, and birthdate in plain words, those sentences should come out or be qualified as optional once the fields move. If the policy was already written in generic categories (contact information, demographic information, usage data), no edit is required.
Apple's App Privacy details taxonomy is the right reference for what the App Privacy questionnaire in App Store Connect should say. The categories that matter for a BuddyBoss community app are Contact Info, Identifiers, and Usage Data, plus Health and Fitness or Sensitive Info when the community has those features. The questionnaire should reflect what the build can collect once linked into the binary, not only what the user fills in on signup.
The companion check is the App Privacy questionnaire itself. If the questionnaire still claims Birthdate is collected, but the registration form no longer asks for it and the policy no longer names it, the three are out of sync, and a future review pass may surface a separate 5.1.1(i) disclosure rejection on top of the data-minimisation one.
What to watch out for
The biggest trap on a BuddyBoss 5.1.1 resubmission is a custom membership or marketplace plugin that re-adds the required attribute after the xprofile change. Some plugins copy the registration form for their own checkout, then enforce the original Required flag from the plugin's own settings. Search the plugin's options page for a Registration Fields or Checkout Fields tab and apply the same edit there.
A second trap is Profile Types. BuddyBoss Profile Types lets the admin show different fields to different member groups (Teacher, Student, Member). A field that is optional on the default profile may still be required on a specific Profile Type if the admin set it that way in the Profile Type edit screen. The reviewer will not see the Profile Type selector, only the default signup form, but the inconsistency causes confusion when the team later tests across user roles.
A third issue is the Privacy Manifest file. Apple's PrivacyInfo.xcprivacy requirement for SDKs on the published required-reason list since 2024 is enforced separately from 5.1.1, but the same review pass often surfaces both, especially when the BuddyBoss app bundles push notification, analytics, or crash reporter SDKs. Check the manifest at the same time as the registration form.
A fourth issue, less common but real, is caching. If a CDN or WordPress caching plugin holds the old required-field markup, the reviewer may load the cached page and still see the validation error. Clear the cache after the field edits, and confirm the new form is what the public URL serves.
Key takeaways
- A Guideline 5.1.1 rejection on a BuddyBoss app almost always points at the xprofile registration form requiring fields the core community feature does not need.
- The remediation is a setting change in BuddyBoss Platform > Profiles > Profile Fields, not a code patch or a new binary; the Required checkbox is the toggle that controls validation on both the website and the in-app form.
- The Resolution Center reply names the fields, states they are now optional, and offers to demonstrate the change on the same build the reviewer is testing; an IPA upload is usually unnecessary.
- The privacy policy and App Privacy questionnaire only need editing when they explicitly name the removed fields; otherwise the existing wording is already generic enough to stay aligned.
- Some teams send the compiled IPA through an external pre-submission scan with platforms like PTKD.com (https://ptkd.com) to detect over-collection patterns, undisclosed SDKs, and Privacy Manifest gaps before the next 5.1.1 reviewer pass.
