If your app has a login, App Review needs a way in, and guideline 2.1(a) is the line that says so.

Which guideline requires a demo account?

Guideline 2.1(a), under the heading App Completeness. The sentence is short and it covers two things at once. Submissions should be final versions with all necessary metadata and working URLs, and you should include demo account info, and turn on your back-end service, if your app includes a login. Apple puts an exclamation mark after the back-end part, which tells you how often it happens. A reviewer who reaches a sign-in screen backed by a sleeping server cannot tell a disabled service from a broken app, and 2.1(a) ends by saying Apple will reject binaries that crash or show obvious technical problems.

The same page asks for slightly more than 2.1(a) alone does. The Before You Submit checklist at the top says to provide App Review with full access to your app, and that if your app includes account-based features you should provide either an active demo account or a fully-featured demo mode, plus any other hardware or resources that might be needed, giving login credentials and a sample QR code as the examples. Account-based features is a wider test than a login wall. An app where signing in is optional still has account-based features, so the reviewer still needs an account to see them.

App Store Connect draws the line more narrowly than the checklist does. In the Platform version information reference, read on 21 October 2026, the Sign-in required field is marked required if your app requires a login to use it. So the console will let you submit without credentials when the login is optional, and the guidelines will still expect the reviewer to get at those features. Treat the console as the floor and the checklist as the standard you are actually graded against.

Apple, App Review Guidelines, guideline 2.1(a), page updated October 16, 2026, read 21 October 2026

What exactly goes in the App Review Information fields?

App Store Connect gives you three things in that section, and App Store Connect Help describes each one. A Contact block with a name, an email and a phone number, for the person App Review should reach. The phone number has to be in international format, a plus sign then the country code, because the field does not accept a numbers-only entry. A Notes field, which holds up to 4000 bytes and can be written in any language. And Sign-in required, which takes the username and password of a demo account. All three were read on 21 October 2026.

App Review Help is more specific about what the credentials have to be. Enter a username and password that work at the time of submission, because credentials that expire or change before your review starts may get the submission rejected. If your app has multiple account types, such as administrative and general user accounts, use the Notes field to add credentials for each type. If your app offers auto-renewable subscriptions, provide a demo account with an expired subscription, so the reviewer can see the whole purchase flow instead of arriving in the middle of it. And if your app needs an authentication code as well as or instead of a password, include it in the Notes field in advance. Apple is blunt about the cost of leaving it out: a call may be required to continue the review, and calls are typically completed within three to five business days.

Two more things live in the same section, and both get missed. The first is a general description of the app, which App Review Help asks for by parts: the concept and business model for a new app, what changed and where to find it for an update, the purpose and audience, the device models and operating systems you tested on, the external services the app depends on, and any regional differences. The second is a video, required when the app needs hardware. It has to be a video rather than a screen recording, and it has to show the app running on a physical Apple device as it pairs and interacts with the hardware.

Google Play wants the same access, asked for in a different place. Play Console Help lists providing and managing instructions on how to access restricted parts of your app among the jobs on the App content page, so the credentials sit with the app rather than with a version. The field names and the rules around them are not Apple's, which is why the google play app access instructions are worth doing separately rather than pasting across.

Apple, App Review Help, provide information for a complete review, read 21 October 2026, no last-updated date on the page

What if the account cannot be shared, like a bank?

Apple documents this, in two places, with two different triggers. Guideline 2.1(a) says that if you are unable to provide a demo account due to legal or security obligations, you may include a built-in demo mode in lieu of a demo account, with prior approval by Apple, and that the demo mode has to show your app's full features and functionality. App Review Help carries a section headed Use a demonstration mode when appropriate, which says that if your app handles sensitive user information, or operates in a highly regulated industry, you can implement a demonstration mode instead of providing a demo account, and that it should show full features and functionality using demonstration data. So the premise of the question holds. There is a documented alternative, and a bank or a health app is the kind of case it exists for.

The gap is the approval. The guidelines attach prior approval by Apple to the demo mode. The App Review Help page that describes a demonstration mode never uses those words, and offers no step for asking. The only pre-submission conversation Apple documents is a one-on-one App Review appointment, booked through the Meet with Apple schedule page, a 30-minute video call subject to availability on Tuesdays and Thursdays, and that page says the appointment is informational and that App Review cannot preapprove apps or specific features. Three Apple pages, read on 21 October 2026, and none of them says where the prior approval comes from. In practice that leaves one move: build the demonstration mode, say in the Notes why an account cannot be shared, and let the review settle it.

A bank app has a second obligation on the same screen, and it has nothing to do with logins. App Review Help publishes a table of documentation typically requested per guideline. Against 3.2.1, Financial Apps, it asks for documentation showing your partnership with the financial institution or bank providing the underlying service. Against 3.2.1 and 3.2.2, apps offering loans, it asks for a loan license, a business license, and partnership documentation showing the formal agreement between you and a licensed lender. The page is flat about what happens if you skip it: incomplete submissions will be rejected.

The same table covers content you did not create. Apps using another party's intellectual property are asked for trademark or rights documentation, such as a signed contract or email correspondence showing you have permission, under guidelines 4.1, 5.2.1 and 5.2.3. That is a separate pile of paperwork from the login, and it is the one that trips up anyone shipping a feed of somebody else's material, so read up on the app store content rights question before you attach anything.

Apple, App Review Help, use a demonstration mode when appropriate, read 21 October 2026

What gets a submission rejected on this one?

Credentials that stopped working is the first one, and it is the easiest to cause by accident. A trial account that lapses, a password rotated by policy, a seeded test user wiped by a database reset between submitting and being picked up. Apple says credentials that expire or change before your review starts may result in the submission being rejected, which puts the risk on the window you do not control. Make the review account permanent and leave it alone.

A back end that is off is the second. The guideline asks you to turn on your back-end service, and the Before You Submit list repeats it: enable backend services so they are live and accessible during review. Staging environments that sleep overnight and feature flags left closed both look like a broken app from the outside.

Purchases hidden behind the login are the third. Guideline 2.1(b) says that if you offer in-app purchases, they must be complete, up-to-date, visible to the reviewer and functional, and that if a configured item cannot be found or reviewed in your app you have to explain why in your review notes. The fourth is the notes themselves. Guideline 2.3.1(a) says all new features, functionality and product changes must be described with specificity in the Notes for Review section of App Store Connect, and that generic descriptions will be rejected. The field App Store Connect labels Notes is the one the guideline is talking about.

If one of these does land on you, the fix is usually a resubmission with the missing line filled in rather than an argument. Keep the argument for a decision you think is wrong on the merits, and read how to appeal app store rejection before you write anything. A dead password is not a decision worth appealing.

Apple, App Review Guidelines, guidelines 2.1(b) and 2.3.1(a), page updated October 16, 2026, read 21 October 2026