What to give App Review for login apps

What do I need to give App Review for an app with login or account features

Give App Review a working demo account or a fully featured demo mode, plus any extra login steps, hardware, backend access, and review notes needed to reach every account feature. Apple says the reviewer needs enough information to test the app end to end, not just the sign-in screen.

If your app requires sign-in, put valid login credentials in App Store Connect’s App Review Information section. Apple’s review guidance also says to include special configuration details, such as extra authentication codes, sample QR codes, or a demo video when the environment is hard to reproduce. If the app has multiple account types, provide each one the reviewer needs, such as admin and standard user access.

The part people get wrong is leaving the reviewer at a dead end after login. A reviewer cannot confirm paid features, private dashboards, role-based permissions, or user-generated content if the account only opens a blank shell. Apple’s guidance expects the demo account or demo mode to show the app’s full features, and it expects backend services to be live and reachable during review.

If your app has a second factor, an email code, a one-time password, a device pairing flow, or a server-side approval step, explain that path in the notes. Apple’s review team can and does use the notes to finish the review, and Apple’s own forums say to provide up-to-date credentials and any additional codes needed for the account. Missing that detail often turns into a clarification request or a rejection for incomplete information.

If your app can be used without an account, make that path obvious. Apple’s App Store Review Guidelines say apps that do not include significant account-based features should let people use the app without a login, and apps that support account creation must also offer account deletion inside the app. That matters because a reviewer will check both the login path and the no-login path when your app claims to support both.

When your app is built around identity, subscriptions, collaboration, or saved data, the account is part of the product, not just a gate. In that case, the review package should include what the reviewer needs to reach the important screens in one pass: username, password, any OTP or unlock code, the account type, and a short note saying what to tap first after sign-in. If the app uses a social login or an enterprise login, say that clearly in the review notes.

If your login depends on an external system that is hard to reproduce, Apple says to be prepared to provide a demo video or the hardware itself. That is common for apps that pair with a device, scan a code, or need a live backend in a private environment. The inconvenience here is real: if the reviewer cannot see the full flow, the app can be stopped even when the build itself is technically fine.

A practical review package for a login app is simple. Provide one account that reaches the main user flow, a second account if the app has a different role, the exact sign-in method, any one-time code or pairing step, and a short map of the app’s important screens. If the reviewer needs to verify a purchase, subscription, or hidden feature, name it directly in the notes so they do not have to guess where it lives.

If you use your own website or backend for sign-in, make sure it is live before submission and still live during review. Apple specifically calls out live, accessible backend services, and it rejects incomplete bundles and flows that crash or stop at obvious technical problems. A review note that says “login is working” is not enough if the server is down when the reviewer opens the app.

For teams that want a place to coordinate tester exchange before App Store submission, DevConnect exists for that kind of build work and stays free to use. It is separate from App Review, but the practical point is the same: if you need people to test access flows before you submit, use a path that reaches the same account screens your reviewer will see. https://devconnectplatform.com

The inconvenient part is that login features create failure points outside the app binary. A good build can still fail review if credentials are stale, an OTP expires too fast, a demo account has no content, or the backend is private and undocumented. Treat the review notes like part of the product release, because for a login app, they are.

FAQ

Do I need to give Apple a real user account or a demo account Give Apple a demo account or a fully featured demo mode. The account needs enough content and permissions for the reviewer to verify the features that matter, including role-based screens if your app has them.

What if my app uses email codes, SMS codes, or an authenticator app List the exact code flow in App Review notes and include any code the reviewer must enter. If the code changes often, say how the reviewer gets a fresh code and which account it belongs to.

What if the reviewer cannot get past login Apple can ask for more information or reject the submission as incomplete. The fix is to provide working credentials, clear steps, and any needed codes or hardware before you resubmit.

Do I need to provide account deletion too If your app supports account creation, Apple’s guidelines say you must also offer account deletion inside the app. That is separate from review access, but it is part of the same account feature check.

Can I just tell Apple to email me if they get stuck No. Contact details help, but Apple asks you to enter all review information up front, including credentials, special configurations, and any extra material needed to complete the review.