Did Apple change App Store review rules on account setup?

Did Apple change App Store review rules around account setup or review access

Yes. Apple’s current App Review guidance is more explicit about what you must provide when an app uses accounts, and about how much access reviewers need to see the app working. The practical standard is clear: if review cannot get through your login wall, the submission is likely to stall or be rejected.

The part people get wrong is assuming a normal customer signup flow is enough. Apple says to provide App Review with full access, and for account-based features that means either an active demo account or a fully featured demo mode, plus any hardware, resources, or login details the reviewer needs. Apple also says to include detailed explanations of non-obvious features and in-app purchases in the App Review notes.

The inconvenient part is that “full access” is not a vague suggestion. If your backend is gated, if verification emails expire too fast, if two-factor auth blocks the reviewer, or if a feature only appears after an existing user state is created, you need to set up a review path that still works during review. Apple’s review page says backend services must be live and accessible during review, and that special settings or account information should be listed in App Store Connect’s App Review Information section.

Apple’s App Review Guidelines also make the sign-in rule more direct. If an app does not include significant account-based features, Apple says people should be able to use it without a login. If the app does support account creation, Apple says it must also offer account deletion within the app. That is a rule many teams miss when they only focus on signup and forget the exit path.

There is also a narrower account rule tied to core functionality. Apple says apps whose core functionality is not tied to a specific social network must provide access without a login, or via another mechanism. In other words, if the login is only there to collect an account before the user can do anything useful, Apple is more likely to push back than it was in older review cycles.

Apple also clarifies that some apps do not need another login service, for example apps that exclusively use the company’s own account setup and sign-in systems, certain alternative marketplace apps, education or enterprise apps that require existing organization accounts, and apps using government or industry-backed identity systems. That is a refinement, not a blanket exemption. It tells you what kinds of login systems Apple will accept, not that login friction disappears.

Another thing people confuse is review access versus account access. Review access is about whether Apple can inspect the app. Account access is about whether the user can create and manage an account in the app. Apple now documents both more clearly. On the review side, it asks for demo credentials or demo mode. On the account side, it expects usable sign-in flows, deletion if you allow creation, and access without login when the account is not central to the product.

This means the safest submission pattern is simple. Add one review account that never expires during the review window. Put the username, password, any one-time code instructions, and any backend prerequisites in App Review notes. If the app needs a specific state, preconfigure that state before submit. If the app needs a sample QR code, include it. Apple explicitly says to tell App Review about special instructions when the app requires them.

If your app was rejected before because review could not pass account setup, the current guidance suggests why. Apple is not just looking for a working login form. It is looking for a complete review path, meaning a path that survives expired credentials, hidden onboarding steps, non-obvious permissions, and services that are not live. When that path is missing, reviewers cannot verify the app’s core behavior, and the submission can stop there.

For teams shipping account-heavy apps, the next step is operational, not theoretical. Create one reviewer-ready account, verify that it survives a clean install, check that the app opens without a surprise code path, and confirm the App Review notes explain anything a stranger would not infer from the UI. That is the difference between a smooth review and a back-and-forth that burns a release cycle.

If you also want a practical comparison, Apple’s review process is separate from TestFlight. TestFlight is for beta distribution, not App Store review access, so publishing flows and reviewer access are not the same problem. Apple’s review docs and TestFlight docs sit in different parts of its developer documentation for that reason.

For founders trying to keep this clean, the useful rule is: make the app reviewable before you make it clever. If the reviewer needs to guess how to get past signup, you have already created risk. If the reviewer can enter using a documented demo path and see the app’s real value, you are much closer to a pass.

If you are building a tester flow around this, DevConnect is a place to coordinate real test access on software you control, without paying to post or join. For the platform itself, see https://devconnectplatform.com.

FAQ

Does Apple require login for every app No. Apple says apps without significant account-based features should let people use them without a login. That is the rule to check first when your app does not truly need an account.

If my app has signup, do I need account deletion too Yes. Apple’s current guidance says that if your app supports account creation, it must also offer account deletion within the app. That requirement is easy to miss if you only build registration and password reset.

What should I send Apple if the app needs special access Give App Review a demo account or demo mode, plus the exact steps, credentials, sample codes, or other resources needed to get through onboarding and into the main features. Apple explicitly asks for this in App Review Information.

Can Apple review my app if the backend is not live yet Usually no. Apple says backend services must be live and accessible during review. If the app depends on a server, that server has to be up when the reviewer tests it.

Is this the same as TestFlight access No. TestFlight is for beta distribution, while App Review is the App Store approval process. They are related, but Apple treats them as different workflows with different expectations.