Did Apple change App Review rules around sign-in?

Did Apple change App Review rules around sign-in or account access

Yes. Apple’s App Review guidance now states more clearly when an app may require sign-in, when it must let people in without a login, and when a third-party login also requires an equivalent option. The practical effect is stricter wording, not a free pass to add account gates.

The part people get wrong is simple: Apple does not let you require account creation just because it is convenient for your product team. If the core functionality does not need an account, Apple says to let people use the app without one. If the app does require an account, Apple says to explain why, and to include the details in App Review Information.

Apple’s current App Review Guidelines also draw a line around account-based features. If the app includes account-based features, Apple says to provide either an active demo account or a fully featured demo mode, plus any hardware or resources the reviewer needs. That is a review-access requirement, and it is different from your production sign-up flow.

For apps that use a third-party or social login service to create or authenticate the primary account, Apple requires another equivalent login option unless the app fits one of the listed exceptions. The equivalent option must limit data collection to name and email, let users keep email private, and avoid collecting app interactions for advertising without consent.

Apple’s own account guidance matches that direction. The Human Interface Guidelines say to ask people to create an account only when core functionality requires it, and to prefer passkeys when you are not using Sign in with Apple. That is not a new idea, but Apple now documents it more plainly in the review and design docs people use to get through submission.

The inconvenient part is that “my app works better with login” is not the same as “my app needs login.” Apple’s rule is about necessity, not preference. If your app can show content, let people browse, or complete a core task without an account, Apple expects that access path to exist. If you hide those basics behind registration, review can reject the app under the account sign-in guidance.

Another thing people miss is the review packet. If access depends on a special account, a test user, a demo mode, or a device setup, you need to tell App Review exactly how to get in. Apple’s review page says to include special instructions, account information, and any required settings in App Review Information. Review failures often come from missing access, not from the product itself.

The Sign in with Apple rules are also easy to misread. Apple does not say every app must use Sign in with Apple. It says that if you use a third-party or social login service for the primary account, you need an equivalent option unless an exception applies. If your app only uses your own account system, that specific equivalent-login rule does not apply.

Here is the safe reading for shipping apps. If your app truly needs an account, make that need obvious in the sign-in screen, give App Review a working path, and provide a demo account or demo mode. If the account is optional, keep the first-run experience usable without one. If you already use Google, Facebook, X, LinkedIn, Amazon, or another social login as the main account, add an equivalent sign-in path or expect a rejection.

If you are building a product around account access, the shortest rule is this: Apple has moved toward clearer enforcement of access, disclosure, and alternate sign-in paths, not toward allowing more friction. The review docs now say the quiet part out loud.

For teams shipping through App Store review, the concrete next step is to audit three screens: first launch, sign-in, and reviewer access notes. First launch should not block users unless the account is essential. Sign-in should explain why login is needed. Review notes should include the exact credentials or demo path Apple asked for. That is the part that keeps getting missed.

If your app needs testers for closed testing or account-gated review flows, keep the process on owned infrastructure and document the access clearly. A simple reviewer-ready setup on your own site, such as the one described on devconnectplatform.com, can help you control who can test and what they can see, without changing Apple’s rules.

FAQ

Does Apple require Sign in with Apple for every app No. Apple requires an equivalent login option only when you use a third-party or social login service for the primary account, unless one of Apple’s listed exceptions applies. Apps that only use their own account system are not in that rule.

Can I force sign-in before showing any content Not if the app’s core functionality does not require an account. Apple says to let people use the app without a login when no significant account-based features are involved. If the account is essential, explain why in the sign-in view and in App Review Information.

What should I send App Review when login is required Send a working demo account or a fully featured demo mode, plus any special steps, settings, or hardware needed to reach the content. Apple says reviewers should not have to guess how your account system works.

Is this a new rejection reason The account and login rules are not new, but Apple’s current docs are clearer about how they are applied. The practical change is that teams now get fewer excuses for hiding core features behind a login screen.

Does Apple care if the login is only for analytics or marketing Yes. Apple’s guidance is about whether the account is necessary for the app’s core functionality. A login that mainly helps marketing, tracking, or analytics does not satisfy that requirement.