You submitted a free utility, the App Store Connect notice cites Guideline 3.2.2(ii), and the rejection reason is that the build asks for an email on first launch. The unusual part: pull up the current App Review Guidelines, find 3.2.2(ii), and the line reads 'Intentionally omitted'. This article explains what reviewers actually mean when that number appears, how the request maps to the rule Apple is enforcing in substance, and how to redesign onboarding so the resubmission clears review.
Short answer
The short answer is that 3.2.2(ii) is a placeholder slot in the current published text, but reviewers still cite the broader 3.2.2 (Unacceptable business practices) or 5.1.1 (Data Collection and Storage) when a free utility demands personal information for features that are not tied to a user account. According to Apple's App Review Guidelines, mandatory registration is only allowed when the gated feature is account based, and any data collection requires informed consent.
What you should know
- The line is blank. The current Guideline 3.2.2(ii) reads 'Intentionally omitted' and carries no rule of its own.
- The substantive rule lives in 5.1.1. Reviewers most often invoke Guideline 5.1.1 (Data Collection and Storage) when registration is required for non-account features.
- Free utilities are the most exposed. Calculators, converters, flashlights and similar apps have no account-based reason for an email gate at first launch.
- Email-only signup still creates an account. It triggers the account deletion requirement under Guideline 5.1.1(v).
- Sign in with Apple becomes mandatory once any third-party login is present. Per Guideline 4.8 of the App Review Guidelines.
- The privacy policy URL must match. Both the App Store Connect metadata field and the in-app link must point at the same reachable URL.
What does Apple's Guideline 3.2.2(ii) actually say?
The honest answer is that the current text is one sentence: 'Intentionally omitted'. Apple has kept the numbering structure stable across years of revisions, and several subsections have ended up empty as rules were retired or moved. Historical drafts assigned 3.2.2(ii) to a different rule about monetizing built-in hardware capabilities and Apple services, but that text is no longer in the published guidelines.
The parent guideline 3.2.2 (Unacceptable business practices) is active. It lists items like building an interface to another developer's app, artificially boosting ad impressions, and other practices Apple treats as out of bounds. None of those subsections directly target requiring an email for a free utility, which is why most rejection notices that mention 3.2.2 in a personal-info context also reference 5.1.1 within the same Resolution Center message.
The practical effect for a developer is that the cited guideline number is a label for a broader objection. Read the full review notice carefully, not just the heading.
Why does my rejection mention a guideline that is intentionally omitted?
The short answer is that App Review uses the closest available heading when a rejection sits at the intersection of business model and privacy. If your onboarding screen blocks the user from the core feature behind a 'create an account' or 'enter your email' wall, the pattern can be filed under unacceptable business practice (3.2.2), data collection (5.1.1), or both.
The mechanism is documented in Apple's own developer forum threads. In one Apple Developer Forums thread, the rejection notice reads: 'The app requires users to register with personal information prior to accessing non account-based features'. The resolution Apple suggests in that thread is to revise the app to allow access to app content and features before registration or login, and only present the registration form when the user reaches an account-based feature.
The evidence shows up in the metadata Apple attaches to the notice: a screenshot of the gate, the path the reviewer took, and the feature that was blocked. The fix is structural, not cosmetic. Renaming the gate does not change the rejection.
Which features can require a sign-up, and which cannot?
The short answer is that an account is only allowed to be mandatory when the feature itself depends on a per-user record. A cloud library, a personal history, a paid subscription, or social posts qualify. A calculator, a one-off converter, a static reference list, or a generated PDF do not.
The mechanism is a per-feature test, not a per-app test. App Review walks the build the way a new user would, and any non-account feature that sits behind a sign-up wall is grounds for a rejection. The boundary question is whether the feature would change behaviour if the user were anonymous.
| Feature pattern | Account required? | Reason |
|---|---|---|
| Free utility with no per-user state (calculator, converter) | No | Nothing to attach to a user record |
| One-off generation (PDF, QR code, image filter) | No | Output is local and ephemeral |
| Saved history or favourites synced across devices | Yes | Identity is needed to sync |
| Paid subscription tied to entitlements | Yes | The receipt needs an owner |
| Social or community feature | Yes | Posts and replies need attribution |
| Push notifications scoped per device | No | Device-scoped works without account |
| Analytics or crash reports | No | Anonymous identifiers are sufficient |
How do I redesign onboarding to clear this rejection?
The honest answer is to invert the flow. The default first-launch experience should expose the core feature directly. The account prompt arrives only when the user attempts an action that genuinely needs identity, such as saving across devices or starting a paid subscription.
The mechanism comes down to four screens at most: a brief value preview, the main feature accessible immediately, an inline prompt at the point of need ('Save this to your account?'), and an optional settings entry for users who want to create an account on their own schedule. According to Apple's Sign in with Apple documentation, if you offer any third-party login service such as Google, Facebook, or email-based magic links, Apple requires Sign in with Apple as a peer option in the same UI, with equal visual weight.
The evidence reviewers look for is whether the home tab works without an account. If the answer is yes, the rejection clears in most cases. If the answer is no, the rest of the redesign does not matter.
The limit is that some apps genuinely need an account from the first screen because the whole purpose is account based, such as a banking app or a private workspace tool. In those cases, the response to App Review should explain why, with documentation that the account is the product, not a marketing capture.
What does the resubmission reply to App Review need to include?
The short answer is three short paragraphs: what changed, where the change is in the build, and which guideline the change addresses.
The mechanism is straightforward. App Review responses run through Resolution Center in App Store Connect, and the reviewer who picks up the resubmission sees the previous notice plus your reply. A clear reply with a screenshot of the new onboarding (account prompt no longer at first launch, plus the path to the feature that was blocked) shortens the round trip.
A pattern I have seen work is to quote the original rejection sentence verbatim ('app requires users to register with personal information prior to accessing non account-based features'), then explain in one sentence which screen has been removed or moved, then point at the build number that contains the change. Vague replies tend to draw a second rejection that asks for the same detail in different words.
For builders who want a second read on a compiled archive before the next submission, PTKD.com (https://ptkd.com) is one of the platforms that scan an IPA against OWASP MASVS controls and flag App Store submission patterns, including registration gates that fire before the core feature is reachable. It runs on the actual archive uploaded to App Store Connect, not the source code, which catches gates the developer forgot were enforced inside a third-party SDK.
What to watch out for
The most common mistake is to treat the rejection as a copy-edit task. Moving the 'Sign up' button down the screen, renaming the title to 'Continue', or adding a 'Skip' link in a small font are all patterns App Review has seen before. The reviewer's question is whether the non-account feature is reachable without identity, and a half-hidden skip link is treated as still requiring registration in practice.
A second pattern: assuming an email magic link is not an account. From Apple's perspective, any persistent identifier the app stores after the session is an account, and the same 5.1.1 rules apply, including the account deletion requirement.
A third pattern: starting analytics or telemetry before the consent screen. Per Apple's documentation on protecting user privacy, data collection must follow informed consent, and a session of analytics that runs before the consent dialog fails the timing test even if the user later opts in.
A fourth pattern: a privacy policy URL that is reachable from the App Store metadata field but returns a 404 from the in-app link, or the other way around. Both must resolve, and both must point at the same document, per the privacy section of the App Review Guidelines.
Key takeaways
- The number 3.2.2(ii) is currently blank in the published text. The objection in your rejection notice is almost always 5.1.1 in substance, even when 3.2.2 is the heading the reviewer typed.
- The structural fix is to expose the non-account feature on first launch, and to surface the account prompt only at the point of genuine need.
- Sign in with Apple becomes mandatory once any third-party social login is offered, per Guideline 4.8. Confirm the button is present and visually equal to the others.
- The privacy policy URL must resolve from both the App Store Connect metadata field and the in-app link, and both must point at the same document.
- Some teams outsource the pre-submission pass to a service like PTKD.com (https://ptkd.com), which scans a compiled IPA against OWASP MASVS controls and flags onboarding gates that App Review tends to catch.
