How do I rework app login to pass Guideline 5.1.1?

If your iOS app was rejected for Guideline 5.1.1 and the Resolution Center note talks about a sign-in screen, login fields, or required registration, the fix is usually a few small reworks rather than a re-architecture. The trigger is almost always one specific pattern: the reviewer hit a screen that asked for an account before the app showed anything worth signing up for.

Short answer

Apple rejects under Guideline 5.1.1(v) when login is required to use features that are not account-based. The rework that passes on the next build is to expose a guest path to those features, mark non-essential registration fields as optional in both the form and the backend validation, and put working demo credentials in the App Review Notes field for the parts that are genuinely gated. Per the App Review Guidelines, an app whose core function is not account-based must allow access without a login.

What you should know

• Guideline 5.1.1(v) is the subsection that hits sign-in walls. Apple's wording is: if your app does not include significant account-based features, let people use it without a login.
• Reviewers test with no credentials and no account. A first-pass reviewer who reaches a hard sign-in screen with no skip option, no guest mode, and no demo credentials in the Review Notes will reject the same day.
• App Review Notes with working demo credentials is the cheapest path. For apps where every feature is genuinely account-bound, a working test account in App Store Connect Review Notes resolves most rejections without code changes.
• Optional must be optional in the backend too. A field marked (optional) in the UI that still fails server-side validation triggers a second rejection on the same guideline.
• Account deletion is a separate sub-rule inside 5.1.1(v). Per Apple's account deletion guidance, every app that supports account creation has had to offer in-app account deletion since June 30, 2022.
• Social-only login is a separate 5.1.1 trigger. An app whose only sign-in option is Facebook, X, or WeChat is rejected unless the core function is the social network itself.
• Apple does not publish 5.1.1 rejection rates. Numbers in third-party blog posts that read like "Apple rejects X percent of apps under 5.1.1" are estimates, not Apple data.

What part of Guideline 5.1.1 is actually triggered by a login wall?

The rejection note in Resolution Center cites the guideline but does not always say which subsection. The text body tells you the subsection. If the reviewer mentions registration, login, sign-in, or required fields, the subsection is 5.1.1(v). If the reviewer talks about a missing privacy policy URL, the subsection is 5.1.1(i). If they cite missing purpose strings or permission justifications, the subsection is 5.1.1(ii) or 5.1.1(iv).

For the login subsection, the reviewer almost always attaches a screenshot or a screen recording showing the screen they could not get past. That screenshot is the most specific signal you will get about which sign-in surface needs work. If no screenshot is attached, the safe assumption is that the very first sign-in prompt the app shows is the one to rework first.

A feature is account-based, in Apple's reading, if it cannot exist without storing per-user state on a server you control. A cloud sync of notes, a shopping cart tied to a user identity, a payment history, a friends list, a per-user usage quota that prevents abuse: those qualify. A static catalog, a news feed, an offline calculator, a free-tier read of public data, an onboarding tutorial: those do not. Apple treats browsing as the canonical example of a non-account-based feature, which is why an e-commerce app that gates the product catalog behind a sign-in wall is the textbook 5.1.1 rejection.

How do I add a guest mode without rebuilding the data layer?

The minimal-code-change pattern is to introduce an anonymous user identity at app launch that can be promoted to a real account later. The unauthenticated user gets a temporary identifier (a UUID stored in Keychain on iOS), and the parts of the app that do not need server state work against that identifier or against fully local data.

A pragmatic shape of this rework, for an app with a Supabase or Firebase backend, is:

1. On first launch, do not present the sign-in screen. Instead, call the anonymous sign-in API and store the returned token.
2. Render the home tab against public data or against an empty local state. Hide the parts of the UI that require a real account (cloud sync indicator, profile, paid history).
3. When the user taps a feature that genuinely needs an account, present the sign-in screen with a clear reason ("Sign in to save your notes across devices").
4. On successful sign-in, link the anonymous account to the real account so any local state migrates over.

Supabase's anonymous sign-in documentation and Firebase's anonymous authentication guide both describe this pattern. The change is usually a single API call at launch and a conditional render around the sign-in screen, not a data-layer rewrite.

For apps that cannot integrate anonymous sign-in (older codebases, custom backends), a simpler fix is a Browse as guest button on the sign-in screen that opens the home tab in read-only mode. The reviewer who can reach the home tab without an account usually does not pursue the rejection further.

How should I use App Review Notes when login is genuinely required?

For apps where login is genuinely required (regulated industries per 5.1.1(ix), enterprise apps, internal apps for a specific community), the App Review Notes field in App Store Connect is the lever. The pattern that consistently passes the second submission has three parts: a one-line explanation of why the app is account-based, working demo credentials, and a sample walkthrough.

A workable template:

This app is a client for a private workspace platform used by registered customers of [company]. Every feature requires authentication against the customer's workspace. Demo account: review-demo@[company].com / [password]. Once signed in, the home tab shows three sample projects. Tap any project to see the full feature set.

The credentials must work for the entire review window, must not be 2FA-protected, and must not have a single-use property. A common failure mode is that the demo account expires after seven days of inactivity, which is fine the first time and breaks on the second submission a month later.

Which registration fields trigger 5.1.1 most often?

The fields that most often trigger 5.1.1 rejections, per the BuddyBoss documentation on 5.1.1, are City, State, Country, Date of Birth, Phone Number, and Gender. The pattern is the same in every case: the reviewer asks whether the field is required by the core function. If the answer is no (the app does not ship physical goods, does not need age verification by law, does not call by phone), the field has to be optional or removed.

Optional means three things at once. The label in the form has to say (optional). The client-side validation has to skip the field if it is empty. The server-side validation has to accept a record with that field null or absent. If any of those three layers still requires the field, the next reviewer hits the same wall and rejects again on the same guideline.

The honest case for keeping a field required is narrow. Age verification for a regulated category (alcohol, gambling, financial services per 5.1.1(ix)) is acceptable. A phone number for an SMS-based identity flow is acceptable. A country for tax compliance is acceptable. Apple does not publish the full list of accepted justifications, but the pattern is that the field has to be defensible in one sentence in the App Review Notes.

How do AI-coded and no-code builder apps trip 5.1.1 differently?

Apps assembled with Cursor, Claude Code, or no-code builders like FlutterFlow and Bubble inherit a common pattern from the web template they start from: the sign-in screen is the first route in the navigation stack. The web version of the same app often shows a marketing page first and the sign-in screen on a button click, but the mobile shell drops the marketing page and starts directly on the sign-in route.

The specific patterns that produce 5.1.1 rejections in AI-coded mobile apps:

• A React Native app where App.tsx mounts the auth screen unconditionally as the root, with no anonymous path.
• A FlutterFlow app where the initial route is /login and there is no guest equivalent of the home page.
• An Expo app that ports a Next.js dashboard one-to-one, including the middleware that redirects every route to /sign-in when no session is present.
• A registration form copied from the web onboarding wizard, with City, State, and Birthdate fields that are required on the web for shipping but unused on mobile.

The compiled IPA contains these patterns as readable strings. PTKD.com (https://ptkd.com) runs pre-submission scans on compiled builds for AI-coded apps, and the repeat finding on the 5.1.1 cluster is a required-field validator inherited from the web template that the developer did not realize was still enforced server-side. The visible mobile form may show fewer fields than the web form, but the backend still rejects a record missing City or Birthdate.

What to watch out for

A few honest limits and traps when reworking login for 5.1.1:

• The demo-credentials fix breaks if the password is rotated or the account is locked. Set a calendar reminder to verify the demo account every time a new build is submitted.
• A guest mode that prompts for sign-in on every tap is still a sign-in wall. The reviewer counts the number of taps before the prompt; one is the same as zero.
• Account deletion under 5.1.1(v) has to actually delete. A flow that deactivates the account or sends an email to support to request deletion does not satisfy the rule outside the regulated-industries exception in 5.1.1(ix).
• A myth worth rejecting: if the privacy policy says login is required, 5.1.1 still applies. The privacy policy is checked under 5.1.1(i) and does not override the no-login-for-non-account-features rule in 5.1.1(v).
• A second myth: Sign in with Apple by itself satisfies 5.1.1. Sign in with Apple is required by Guideline 4.8 when other social logins are present, which is a different rule. Adding Sign in with Apple does not exempt the app from offering guest access for non-account-based features.
• The broader framing, per the OWASP MASVS, is that authentication should be applied where the asset model justifies it (MASVS-AUTH controls). An app that requires sign-in for assets that do not need it fails both the App Review test and the OWASP threat-model test.

Key takeaways

• The most common 5.1.1 trigger is a sign-in wall in front of features that do not actually need an account. Pull those features out from behind the wall or expose them in a guest state.
• For apps where login is genuinely required, working demo credentials in App Review Notes resolve the rejection on resubmission without a code change.
• Optional registration fields have to be optional in three places at once: the form, the client-side validation, and the backend.
• Account deletion under 5.1.1(v) is a separate gate from the login rework. A fix that adds guest mode but ignores account deletion will still fail.
• Some builders outsource the pre-submission audit to platforms like PTKD.com (https://ptkd.com) that scan a compiled IPA for required-field patterns and gated-access markers before the binary reaches App Review.

Published 2026-05-17. Last reviewed 2026-05-17. This article reflects the App Review Guidelines and the account deletion requirement in force as of May 2026.