App Store rejections that cite Guideline 2.1 usually mean something crashed or a link went nowhere. This one is different — Apple has marked it "Information Needed," and there's no crash log to chase, just a message sitting in a queue.
If you build approved-looking apps, this rejection lands strange. You tested the build. It doesn't crash. Every screen loads. Then the review comes back rejected under Guideline 2.1 — App Completeness — and the message doesn't describe a bug at all. It asks a question, or several: what does this permission do, how does a subscription work, why does this screen require a login the reviewer couldn't get past. You're left checking your own code for something broken that isn't there.
The confusion is understandable. Guideline 2.1 covers a wide range of rejection reasons, most of which really are bugs: crashes on launch, broken links, placeholder content left in a build. "Information Needed" is a narrower sub-case buried inside that same guideline number, and it behaves nothing like the others. The reviewer isn't telling you the app is broken. They're telling you they couldn't finish the review because something you submitted didn't answer a question they needed answered — and until you answer it, the app stays in limbo.
Treating this like a standard 2.1 bug rejection is the single fastest way to burn a review cycle. Developers resubmit the same build, sometimes with a version bump and nothing else, and get rejected again for the identical reason — because the fix isn't code, it's information.
This article shows how to read an "Information Needed" request for what it actually is, figure out exactly what the reviewer needs from you, and answer it once, correctly, so the app clears review on the next pass instead of bouncing back a third time.
Key takeaways
- App Store rejections marked "Guideline 2.1 – Information Needed" are not bug reports — they mean the reviewer couldn't verify something and needs clarification, not a code fix.
- The reviewer's actual, specific request lives in the Resolution Center thread in App Store Connect, not in the shorter rejection email notification.
- Resubmitting an unchanged binary does not resolve this rejection type, since the build was never the problem — the missing information is.
- The most common triggers are broken or expired demo account credentials, generic permission-usage strings that don't match app behavior, and incomplete subscription/IAP metadata in App Store Connect.
- A compliant reply restates the reviewer's question in one sentence, answers it directly within two sentences, and attaches only what was requested (credentials, licensing proof, or a short screen recording).
What Guideline 2.1 'Information Needed' Actually Means
Guideline 2.1, App Completeness, is Apple's catch-all for apps that aren't ready for the public: crashes, dead links, bugs, missing content, placeholder text. Most 2.1 rejections fall into that bucket, and the fix is what you'd expect — patch the bug, rebuild, resubmit. "Information Needed" is a different animal wearing the same guideline number. It doesn't mean anything is technically wrong with your build. It means the reviewer sat down with your app, hit a point where they couldn't verify something — a claim in your metadata, the purpose of a permission, how a paywall behaves, what a specific feature does — and stopped the review rather than guess. The rejection is a request for clarification, not a bug report.
This distinction matters because it changes what "fixing" the rejection looks like. There's no stack trace to read, no crash to reproduce, no broken screen to patch. The reviewer has told you, in plain language, what they need — and the entire fix is answering that question clearly enough that the next reviewer doesn't hit the same wall.
Where This Rejection Differs From a Standard 2.1 Bug Rejection
A standard 2.1 bug rejection comes with something you can act on directly in code: a crash log, a screenshot of a broken link, a note that a screen is blank. You fix the underlying issue, verify it yourself, and resubmit the corrected build. The reviewer's next pass is checking whether the bug is gone.
"Information Needed" comes with no code-level defect to point to. The build the reviewer tested is the build that's still on your device, unchanged, working fine. What's missing is context: a demo account that lets them past a login wall, a plain-English explanation of why your app needs Bluetooth access, clarification on what a specific in-app purchase unlocks. Resubmitting the identical binary changes nothing, because the binary was never the problem. If your app uses RevenueCat for subscriptions and the reviewer couldn't figure out what a purchase actually grants, that's a metadata and disclosure gap — see Revenuecat Missing Metadata App Store for how that specific request tends to be worded and answered. Reviewers also frequently stall on permission prompts that don't explain themselves — if you're on Expo, Expo App Store Permission Description covers what the usage-description strings need to say to avoid this exact hold.
Where to Find the Actual Request in App Store Connect
The rejection notification itself is often terse — a line or two, sometimes just "Guideline 2.1 - Information Needed." The actual question lives in the Resolution Center, not the notification banner. Log into App Store Connect, open the app version under review, and look for the Resolution Center thread attached to that submission. The reviewer's message there is the real spec for what you need to provide: it might be a specific question ("Please provide a demo account with pre-loaded data"), or a broader ask ("Explain how users can access the features described in your app description").
Read that message closely before touching anything. Developers regularly skim it, assume it means "something crashed," and resubmit an unchanged build — which just restarts the queue with the same unanswered question sitting in Resolution Center. The reply goes back through the same thread, not through a new build note or a support email. Whatever you send has to speak directly to the specific line the reviewer wrote, in the same place they wrote it.
The Most Common Reasons Apple Asks for More Information
Guideline 2.1 rejections aren't random. Reviewers cite it when they hit a wall trying to verify something in your app, and the same five walls show up again and again.
Demo Accounts and Login Credentials
This is the single most common trigger. If your app requires a login, App Review needs a working account that gets them past it — every time, on the first try. Common failure modes: credentials that expire, a test account that got deleted from your database during a migration, 2FA or email verification blocking sign-in with no way for the reviewer to receive the code, or a demo account that works but drops into an empty state with no data to review. Apple's own instructions ask you to supply this in the App Review Information section of App Store Connect — not in the app description, not in a support email. If the reviewer can't log in, you'll get a 2.1 rejection asking for "a demo account" even if you thought you provided one.
Third-Party Content, Licensing, and API Usage
If your app pulls in content you don't own — sports scores, financial data, video libraries, maps, AI models — reviewers sometimes can't verify you're licensed to use it. This shows up as a 2.1 information request when the source isn't obvious from the app itself, and can escalate to a 5.1.1 or intellectual-property concern if it looks unauthorized. Apps built on RevenueCat for subscriptions run into a related but distinct issue: reviewers flag missing subscription metadata as unverifiable pricing, which is covered in detail in our RevenueCat missing metadata writeup. The fix is the same pattern either way — document your data source or licensing arrangement directly in reviewer notes.
Permission Usage Descriptions That Don't Match Behavior
Guideline 5.1.1 governs this, but it's frequently bundled into a 2.1 request when the reviewer just wants clarification rather than a hard rejection. Your NSCameraUsageDescription or NSLocationWhenInUseUsageDescription string has to describe what the app actually does with that permission — not a generic template string. This trips up Expo and React Native apps constantly, since default templates ship with placeholder permission text that never gets customized before submission. We cover the exact fix for this in our Expo App Store permission description guide.
Subscription and In-App Purchase Metadata Gaps
Guideline 3.1.2 requires subscription apps to have complete, accurate metadata: price, duration, and a functional link to your terms of use (EULA) reachable from both the app binary and the App Store listing. Missing any of these — a broken terms link, no auto-renewal disclosure, or a paywall reviewers can't screenshot because it's gated behind onboarding — generates a 2.1 request asking you to clarify pricing or provide documentation.
Health, Finance, or Legal Claims Needing Documentation
Apps that touch regulated categories — medical advice, investment guidance, tax or legal help — draw extra scrutiny under 2.1 when the app makes a claim reviewers can't verify from the binary alone. If your app says it's "HIPAA compliant" or "FDA cleared," be ready to produce the documentation on request, since reviewers won't take the claim at face value.
How to Read the Rejection Message So You Don't Waste a Review Cycle
The fastest way to burn a review cycle is to answer the wrong question, or answer it in the wrong place. Read the whole message before you touch a single line of code.
Resolution Center vs. Email Notifications
Apple sends two things when your app is flagged: an email notification and a Resolution Center message inside App Store Connect. They're not always identical. The email is often a shorter summary; the Resolution Center thread is where the reviewer's specific, literal ask usually lives, and it's the only place you can reply directly to the reviewer. Always open Resolution Center and read the full thread before doing anything else — replying to the email, or not replying at all and just pushing a new build, sends your response nowhere useful and leaves the actual question unanswered.
Decoding Reviewer Shorthand
App Review messages are templated, and reviewers often paste a boilerplate paragraph followed by one or two sentences that are actually written for your app. Skim past the generic guideline text — "Your app was found to be in violation of App Store Review Guideline 2.1" — and look for the specific line, usually near the end, naming what they couldn't do: "we were unable to locate the subscription terms," "the demo account provided did not work," "we could not verify your login credentials." That sentence is the entire ask. Everything else is copy-paste. If you genuinely can't tell what they need, reply in Resolution Center and ask for clarification rather than guessing — a wrong guess costs another full cycle. And don't resubmit a new binary before you've replied; a fresh build doesn't answer the question, it just re-enters the queue with the same unresolved information gap. For a sense of what a fully documented, reviewer-ready submission looks like, see our sample report.
Step-by-Step: Writing a Reply That Passes on Resubmission
Apple's Resolution Center gives you one shot to answer a question before the reviewer moves on to the next app in the queue. Treat every reply like a support ticket to someone who has 90 seconds and no memory of your app.
What to Include in Every Response
Open by restating what was asked, in your own words, in one sentence. This isn't filler — it proves to the reviewer you understood the question, which matters when the original message was vague or templated. Then answer it directly in the next one to two sentences. Don't build up to the answer with context about your app's history or your development timeline. If they asked "how do users restore a purchase," sentence two should say exactly how, not why you built the feature that way.
After the direct answer, attach exactly what was requested — nothing more:
- Working test credentials if the app requires login. Use an account that's actually active on your current build, not a demo account you set up eight months ago.
- Licensing or rights proof for third-party content, API access, or trademarked names — a PDF or screenshot of the agreement, not a link to a page that requires its own login.
- A short screen recording (30–60 seconds) showing the exact flow in question, especially for anything involving subscriptions, account deletion, or permission prompts. A recording settles ambiguity a paragraph can't.
Skip anything not asked for. Extra screenshots, marketing language, or "while you're at it" context makes the reviewer hunt for the actual answer and increases the odds they miss it.
Formatting Notes and Attachments the Reviewer Will Actually Read
Keep the reply under 150 words. Use short paragraphs or a numbered list if you're answering more than one question — reviewers scan, they don't read prose top to bottom. Name file attachments so they're self-explanatory ("restore-purchase-flow.mp4," not "IMG_4021.mov"). If you're referencing a specific screen, say which one by name, matching the label shown in the app, not an internal codename only your team recognizes.
When to Use the Resolution Center vs. a New Build
A Resolution Center reply alone is enough when the fix is informational — you're providing credentials, clarifying a business model, or pointing to an existing feature the reviewer missed. Nothing in the binary needs to change.
You need a new build when the answer requires a code or metadata change the reviewer can't see yet — a permission string that's too vague, a missing restore-purchase button, an account deletion flow that doesn't exist. In that case, reply briefly acknowledging the issue, state what you're changing, and submit the new build. Don't argue that the current build is fine if the fix is trivial; it costs you a review cycle either way, and reviewers notice when developers push back on things they later fix anyway. Our Sample Report shows what a pre-submission check catches before it becomes a Resolution Center conversation at all.
Two Real Patterns: Missing Subscription Metadata and Permission Descriptions
Most Guideline 2.1 "information needed" rejections aren't random. They cluster around a small number of setups. Two show up constantly in apps built with RevenueCat and Expo.
Pattern 1: Subscriptions Missing Required Metadata
You wire up RevenueCat, test the purchase flow end to end, confirm receipts validate, and ship. What gets missed isn't the code — it's the App Store Connect metadata Apple requires alongside the subscription: localized pricing display, terms of use linked in the app, a working restore-purchases path, and subscription duration stated clearly in the purchase screen. RevenueCat handles the transaction layer; it doesn't fill in ASC metadata fields for you, and reviewers check those fields directly, not your code.
The rejection message usually reads generic ("we need more information about your in-app purchases") because the reviewer is asking you to confirm several things at once. Answering with "here's my subscription price" when they also flagged a missing restore link gets you rejected again. We've mapped the specific fields Apple checks and the order reviewers check them in on the RevenueCat missing metadata App Store page — worth a direct read before you reply, since guessing which field triggered the request wastes a cycle.
Pattern 2: Permission Strings That Trigger Info Requests
The second pattern hits Expo apps specifically. You add NSCameraUsageDescription or NSLocationWhenInUseUsageDescription to app.json, the build compiles, and Apple doesn't reject for a missing string — it asks for more information because the string that's there is too generic. "This app uses your camera" tells a reviewer nothing about what the camera is for or whether the use matches what the app actually does.
Apple wants the description to name the specific feature and the user benefit: "Camera access lets you scan receipts to log expenses," not "App needs camera access." Expo's default templates and most starter boilerplate ship placeholder text that never gets replaced — it's an easy thing to miss because the app still builds and runs fine. Our breakdown on writing permission descriptions Expo reviewers approve covers the wording pattern for each permission type, including the ones — like location and tracking — where a vague string almost guarantees a Resolution Center message instead of a straight rejection.
How to Stop Getting This Rejection Before You Submit
A 2.1 "Information Needed" rejection almost never comes from something exotic. It comes from a small set of gaps that show up in nearly every rejected build: no working demo account, permission strings that don't explain themselves, subscription metadata Apple can't find, or no way to delete an account from inside the app. Once you've seen the pattern across a few submissions, you stop treating each rejection as a surprise and start treating it as a checklist you skipped.
The fix isn't "write better replies." It's catching these gaps before you hit submit, so there's no reply to write.
A Pre-Submission Checklist for Metadata, Permissions, and Account Deletion
Before you submit, verify each of these directly in the build — not from memory of what you meant to do:
- Demo account works right now. Log out, log back in with the credentials in your review notes, and confirm nothing requires a second factor the reviewer can't complete.
- Every permission prompt has a specific, honest purpose string. "Access your photos to let you upload a profile picture" passes. "This app needs access to your photos" gets flagged. If you're on Expo, the permission strings live in
app.json/app.configand are easy to leave at their scaffold defaults — see our breakdown of Expo App Store permission descriptions for the exact fields Apple checks. - Subscription metadata is complete in App Store Connect, not just in code — display name, price, and a working screenshot for every IAP product, especially if you're on RevenueCat where the product can be live in your dashboard but still missing pieces on Apple's side. Our RevenueCat missing metadata writeup covers this exact mismatch.
- Account deletion is reachable from inside the app, not just via a support email. Guideline 5.1.1(v) requires in-app deletion for any app that supports account creation, and reviewers check this as part of a 2.1 pass too. If you built with Expo, the deletion flow has a few platform-specific gotchas — see App Store account deletion for Expo apps for what a compliant flow actually looks like.
Where a Preflight Check Catches These Issues First
Running this checklist by hand works, but it's easy to skip a step under deadline pressure — which is exactly when these gaps slip through. A structured preflight check runs the same list against your actual build instead of your memory of the build: it walks the metadata, screenshots, permission strings, and account flows the way a reviewer will, and flags what's missing before you hit submit.
You can see exactly what that output looks like — the specific checks run and how findings are reported — in a sample report. It's the same shape of information a 2.1 rejection gives you, just delivered before Apple sends it.
Turn Your Next Submission Into a First-Time Pass
You've fixed this rejection once. The real win is not seeing it again — on this app's next update or on the next app you ship.
Before your next submission, run the build through a structured preflight check rather than eyeballing it against memory. SubmitPreflight checks the same things a 2.1 review looks at — demo account access, permission string wording, subscription metadata completeness, account deletion reachability — and surfaces gaps while you can still fix them for free, instead of after a rejection costs you a review cycle. If you want to see exactly what gets checked and how results are reported before committing to anything, the sample report shows the real output on a real build.
Most Information Needed rejections aren't bad luck and they aren't Apple being arbitrary. They're a specific, checkable gap that existed in the build before you hit submit — you just didn't have a way to see it. Close that gap once with a proper preflight pass, and 2.1 mostly stops being something that happens to you.
Frequently asked questions
What does App Store Guideline 2.1 Information Needed actually mean?
It means Apple's reviewer couldn't finish testing your app and needs something from you before they can render a verdict — not a bug rejection. Guideline 2.1 lives under "App Completeness" in the App Store Review Guidelines, and this specific flavor usually means the reviewer hit a wall: a login screen with no valid credentials, a paywall with no way to verify what's behind it, or a feature they couldn't reach. Read the Resolution Center message carefully — it names the exact screen or flow they got stuck on.
Is a Guideline 2.1 Information Needed rejection the same as a bug rejection?
No. A bug rejection (crash, broken feature) means something in your app is actually wrong. Information Needed means the app is likely fine, but the reviewer lacked what they needed to confirm that — usually demo credentials, a missing explanation of a gated feature, or context on how to reach a specific screen. You're not fixing code in most cases; you're answering a question. Treating it like a crash bug wastes a review cycle re-submitting a build when a Resolution Center reply would've closed it in hours.
How long do I have to respond before Apple closes the review?
Apple doesn't publish a hard deadline for Information Needed replies, but the review ticket goes idle after prolonged inactivity and you'll need to resubmit from scratch if it times out. Don't sit on it — reply within a day or two while the reviewer's context is fresh. Post your answer directly in the Resolution Center thread attached to the rejection, not as a new submission, and don't touch your build unless the reviewer specifically asked for a code change.
What demo account details does Apple need to complete review?
A full username and password that logs straight into a working account with real data already populated — no email verification step, no OTP, no "check your inbox" loop the reviewer can't complete. If your app has server-side gating (subscriptions, invite codes, geofencing), pre-configure the demo account to bypass it entirely. Put these credentials in App Store Connect's App Review Information notes field, not just the Resolution Center reply, so they persist across future submissions too.
Will my app go through full review again after I reply, or just a re-check?
Usually just a re-check. When you reply in the Resolution Center with the requested information (credentials, clarification, a screen-recording), the same reviewer typically picks the ticket back up rather than routing you into a fresh full review queue. That's the whole point of Resolution Center replies over resubmitting a new build — you keep your place in line. If the reviewer asks for a code change, that does require a new build submission, which resets the clock.
Can I appeal a Guideline 2.1 Information Needed rejection instead of replying?
You can, but it's the wrong tool here. App Review Board appeals exist for disputing a guideline interpretation you disagree with — not for cases where the reviewer just needs a login or a clarification. Filing an appeal instead of answering the question adds days to your timeline for no benefit, since the board will likely just tell you to provide the information. Save appeals for genuine guideline disputes; answer Information Needed requests directly in the Resolution Center.