What a Guideline 2.1 Information Needed rejection means
Guideline 2.1 Information Needed means App Review started your review, hit something they could not get past or could not evaluate, and stopped to ask you for it. Apple files 2.1 in the Performance chapter under the heading App Completeness. It is not a judgement that your app is bad or non-compliant. It is a blocked review, and the fastest resolution is usually a reply in Resolution Center rather than a new build.
That distinction matters because it changes what you do next. A design or spam rejection asks you to change the app. An Information Needed message asks you to supply working credentials, a demo mode, a video, or a written explanation of where a feature lives. Most of the time the binary sitting in App Store Connect is fine.
Why 2.1 is the rejection you are most likely to get
Apple publishes the number itself. On its App Review page Apple states that on average over 40 percent of unresolved issues are related to guideline 2.1 App Completeness, which covers crashes, placeholder content, incomplete information and more. No other guideline gets called out with a figure like that.
For an indie developer shipping a first app, this is good news. The single most likely reason your submission stalls is not a subjective call about whether your idea deserves to exist. It is a mechanical, fixable gap in what you handed over. Guideline 4.3 rejections are the ones that hurt, and those are covered separately in [the guideline 4.3 rejection breakdown](/blog/app-store-rejection-guideline-4-3). A 2.1 is the cheap one.
The demo account is the usual cause
If your app has a login and you got a 2.1, assume the reviewer could not sign in. Apple's 2.1(a) text is explicit: include demo account info, and turn on your back-end service, if your app includes a login. The parenthetical about the back-end is in Apple's own wording, which tells you how often it is the problem.
- The demo account fields were left blank because sign-in only guards part of the app. The reviewer still has to get past it, so it still needs credentials.
- The credentials were right when you typed them and wrong by review time, because you rotated a password or the account expired.
- The account exists but the data behind it is empty, so the reviewer signs in and sees a blank app with nothing to evaluate.
- The back end was on a free tier that sleeps, or a staging environment you turned off after the build, so sign-in fails with a network error.
- The login requires a one-time code sent to your phone or email, which the reviewer has no access to.
- Sign in with Apple or a social provider is the only route in, and the reviewer's test device cannot complete that flow.
Two-factor is the one people underestimate. If your auth flow sends a code to a device only you hold, no demo account in the world lets the reviewer in. Either add a bypass path for the review account, or ship a demo mode. The auth patterns behind this are in [how to add authentication to your Expo app](/blog/how-to-add-authentication-to-your-expo-app).
What guideline 2.1 actually requires, clause by clause
2.1 has two clauses and they cover different failures. Read them against your own submission before you write a reply, because the rejection message names the guideline and leaves you to find which part you tripped.
Guideline 2.1 App Completeness, in Apple's terms
| Clause | What Apple asks for | How it fails in practice |
|---|---|---|
| 2.1(a) final versions | Submissions should be final versions with all necessary metadata and fully functional URLs | A support URL that 404s, or a privacy policy link pointing at a page you never published |
| 2.1(a) no placeholder | Placeholder text, empty websites and other temporary content scrubbed before submission | Lorem ipsum in a settings screen, a Coming Soon tab, a stub About page |
| 2.1(a) tested on device | Tested on-device for bugs and stability before you submit | Simulator-only testing, then a launch crash on real hardware |
| 2.1(a) demo access | Demo account info included, and your back-end service turned on | Blank credentials, expired account, sleeping back end, unreachable second factor |
| 2.1(a) demo mode | A built-in demo mode instead of an account, with prior approval by Apple, showing full features | A cut-down demo mode shipped without approval and without full functionality |
| 2.1(b) in-app purchases | Purchases complete, up-to-date, visible to the reviewer and functional | Products still unattached to the version, or a paywall the reviewer never reaches |
Apple closes 2.1(a) by saying it will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems. That sentence is why a crash on launch and a missing password arrive under the same guideline number.
The Blank Slate Pass: catching 2.1 before you submit
The Blank Slate Pass is our name for the pre-submission run that catches almost every 2.1 in one sitting. The rule is simple: use your app the way App Review will, with none of the context you carry around in your head. No saved password, no seeded account, no local dev server, no knowledge of where anything is.
- Install the exact build you submitted from TestFlight on a device that has never run your app, not from your development machine.
- Sign out of everything. Delete the keychain entry, clear the app data, and forget the account you use every day.
- Sign in using only the demo credentials you typed into App Store Connect, copied and pasted from that field rather than from memory.
- Reach every feature you named in your release notes, tapping only what a stranger would find. If it takes you more than a minute, it needs a note.
- Trigger the paywall and confirm the products render with real prices instead of blank rows or a spinner.
- Open every URL in your metadata: support, marketing, privacy policy. Load each one in a browser that is not signed into anything of yours.
- Kill the app and cold start it three times. Launch crashes are 2.1 territory and they are the most expensive kind to discover after submission.
Do this from a real TestFlight build rather than a local run. A development build talking to a server on your own machine proves nothing about what the reviewer will see. [The TestFlight beta testing guide for Expo apps](/blog/testflight-beta-testing-guide-for-expo-apps) covers getting that build into testers' hands, and the Blank Slate Pass is what you do with it before you hit submit.
Where App Review Information lives and what goes in each field
App Review Information sits in App Store Connect on the version page for the build you are submitting, below your metadata. Apple documents these fields as not visible to customers and editable at any time, which means you can correct a bad demo account without uploading a new binary.
App Review Information fields
| Field | What Apple documents | What to actually put there |
|---|---|---|
| Sign-In Required | Toggle plus User Name and Password for a demo account | On for any app with a login, even a partial one. A real, permanent, populated account |
| Notes | Optional, up to 4000 bytes, can be written in any language | Navigation path to every new feature, plus anything non-obvious about setup |
| Contact Information | Name, email and phone number, phone in international format with country code | A number and inbox you will actually answer during the review window |
| Attachment | Where Apple asks you to attach documentation, with descriptions or links in the review notes | A demo video, or authorisation paperwork for regulated or partnership features |
The 4000 byte limit on Notes is generous and almost nobody uses a fraction of it. If you are wondering whether a piece of context is worth including, it is. If you have not set the version page up before, [how to set up App Store Connect for your first app](/blog/how-to-set-up-app-store-connect-for-your-first-app) walks the whole screen.
How to write Notes for Review that pre-empt the question
Write your notes as directions for a stranger holding a device in a country you have never been to. Apple's 2.3.1(a) is direct about the standard: all new features, functionality and product changes must be described with specificity in the Notes for Review section, generic descriptions will be rejected, and those features must be accessible for review.
Specificity here means tap paths, not adjectives. Improved the export flow is a generic description. Settings, then Data, then Export creates a CSV and opens the share sheet is a specific one. The second version survives a reviewer who has a queue of other apps to get through.
- Name the exact screens in order for every feature you want reviewed, using the labels as they appear on screen.
- Say what the demo account already contains, so an empty-looking screen reads as expected rather than broken.
- Flag anything that needs a permission prompt, hardware or a second device, and say what to do when it appears.
- Explain any region-locked or feature-flagged behaviour, and how the reviewer can see it from wherever they are.
- If a feature genuinely cannot be demonstrated, say so plainly and explain why, rather than leaving the reviewer to find nothing.
In-app purchases the reviewer cannot see
2.1(b) is its own trap. Apple requires that in-app purchases are complete, up-to-date, visible to the reviewer and functional, and that if any configured item cannot be found or reviewed in your app you explain the reason in your review notes. A paywall showing blank rows because the products were never submitted alongside the build is a textbook 2.1.
- Confirm each in-app purchase is attached to the version you are submitting rather than sitting on its own waiting to be submitted.
- Confirm the paywall renders live prices on a real device, not placeholder strings, before you submit.
- Tell the reviewer in the notes exactly how to reach the paywall, because a purchase behind onboarding is often never seen.
- If a product is intentionally hidden, for a specific cohort or a later release, write down why in the notes rather than leaving it unexplained.
Test the purchase itself before submitting, not just the screen. A paywall that renders and then fails on tap is worse than one that never loads, because it looks finished. The setup for that is in [how to test in-app purchases in sandbox mode](/blog/how-to-test-in-app-purchases-in-sandbox-mode), and the screen design side is in [the paywall screen that converts](/blog/paywall-screen-that-converts).
How to reply in Resolution Center
Resolution Center is where the exchange happens, on the App Review page inside your app in App Store Connect. Apple describes it as the place to manage submissions and communicate with App Review, and it keeps a history of the messages. Treat each reply as the whole answer, because every round trip costs you a review cycle.
- Answer the exact question asked, first, in the first two sentences. Not context, not apology, not a summary of your app.
- If credentials were the problem, paste the working ones in the reply and update the demo account fields on the version page as well.
- Give tap-by-tap directions for anything they could not find, using the on-screen labels.
- Attach a screen recording if the answer is easier to show than to write.
- Say clearly whether they need to do anything to see the fix, such as reinstalling or waiting for your back end to warm up.
- Ask one direct question if the message is ambiguous, rather than guessing and burning a cycle on the wrong fix.
When it is a crash, not missing information
Sometimes the 2.1 message is not asking for credentials. It is telling you the app crashed or misbehaved on the reviewer's device, often with a crash log attached and a device and OS version named. That is still 2.1, because Apple's text puts binaries that crash or exhibit obvious technical problems in the same clause, but the fix is code rather than a form field.
- Read the attached log and the stated device and iOS version. Reviewers frequently test on hardware or an OS release you have never run.
- Reproduce on a real device before changing anything. A crash you cannot reproduce is a crash you cannot confirm you fixed.
- Check the cold-start path specifically, since a launch crash on a first install after a clean download is the kind that ends a review immediately.
- Wire up crash reporting so the next one arrives from your own users rather than from a reviewer. [How to add crash reporting to your Expo app](/blog/how-to-add-crash-reporting-to-your-expo-app) covers the setup.
This is the one 2.1 variant where a new build is the right answer. Fix it, run the Blank Slate Pass again, and note in Resolution Center what the cause was and which version resolves it.
Expedited review and appeals: when each one applies
Neither is the right tool for an ordinary 2.1. Apple documents expedited review for two situations: a critical bug fix, where you include steps to reproduce the bug, and an event-related app, where you include the event name, the date and your app's association with it. Being behind schedule is not one of them.
Appeals are narrower still. Apple's route to the App Review Board is for when you believe your app's concept and functionality were misunderstood, or that you were treated unfairly during review. It asks for specific reasons why you believe the app complies, one appeal per submission that did not pass, and that you respond to any requests for additional information before submitting an appeal. A 2.1 message is a request for additional information, so appealing one is answering the wrong door.
Making 2.1 impossible on the next submission
Once you have been through one of these, it becomes a checklist item rather than an event. Keep a permanent review account that you never delete and never rotate, seed it with realistic data, and check it the day you submit.
- One dedicated review account per app, kept alive between releases and populated with enough content that every screen has something in it.
- A note in your release checklist to verify the credentials in App Store Connect against the live account, by pasting rather than reading.
- A saved Notes for Review template you edit per release, so the tap paths get updated instead of forgotten.
- A Blank Slate Pass on every submission, not just the first one. Updates get rejected under 2.1 as readily as launches do.
- Back-end uptime confirmed for the whole review window, including any staging service the build points at.
The broader review picture, including the guidelines that judge your app rather than your paperwork, is in [how to pass Apple App Review](/blog/how-to-pass-apple-app-review). And if the rejection you got was about privacy answers rather than access, [App Privacy details in App Store Connect](/blog/app-privacy-details-app-store-connect) covers that form line by line.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
What does Guideline 2.1 Information Needed mean?
It means App Review could not complete your review and needs something from you before they can continue. It is filed under 2.1 App Completeness and is a request rather than a rejection of your app's concept. The most common trigger is a login the reviewer could not get past, but it also covers placeholder content, broken metadata URLs, in-app purchases the reviewer could not see, and crashes.
Do I need to upload a new build to fix a Guideline 2.1 rejection?
Usually not. App Review Information fields, including the demo account user name and password, are editable at any time and are not visible to customers, so you can correct them and reply in Resolution Center without a new binary. Upload a new build only when the code genuinely changed, such as when the message reports a crash. A new build starts a new review cycle.
What do I put in the demo account fields if my app has no login?
Leave Sign-In Required off and use the Notes field instead to describe how to reach the features you want reviewed. If any part of your app sits behind a login, even an optional one, turn the toggle on and supply working credentials, because the reviewer will still try that path.
How long can the Notes for Review field be?
Apple documents the Notes field as optional with a limit of up to 4000 bytes, and it can be written in any language. That is a lot of room, and most submissions use almost none of it. Guideline 2.3.1(a) requires new features to be described with specificity there, and states that generic descriptions will be rejected.
Can I use a demo mode instead of a demo account?
Apple allows a built-in demo mode in lieu of a demo account if you are unable to provide an account due to legal or security obligations, but only with prior approval by Apple, and the demo mode has to exhibit your app's full features and functionality. Prior approval is part of the rule, so shipping a demo mode on your own initiative and hoping it satisfies 2.1 is not the path.
Should I appeal a Guideline 2.1 rejection?
No. Apple's appeal route to the App Review Board is for cases where you believe your app's concept and functionality were misunderstood or that you were treated unfairly, and it asks you to respond to any requests for additional information before submitting an appeal. A 2.1 Information Needed message is precisely such a request, so the correct response is a reply in Resolution Center.
Last reviewed by David on August 21, 2026
