If you shipped an app from Lovable, Bolt, v0, or Replit and got a Guideline 2.1 rejection that just says "Information Needed," the good news is that it's usually not a bug. It's a question. The reviewer could not get far enough into your app to judge it, and in most cases that means they hit a login screen with nothing to sign in with.
This one is worth fixing carefully, because it's avoidable in a way crashes aren't. A crash needs debugging. A missing demo account just needs you to fill out a form correctly before you submit.
Why this happens with AI-built apps specifically
Builder-tool apps tend to get tested by exactly one person: the person who built it, already signed in, on their own phone, with their own data already in the app. The reviewer is the opposite of that. They are a stranger, on a device you probably didn't test on (iPad shows up a lot), with a brand-new account and zero saved state.
That gap between "works for me" and "works for a stranger with nothing" produces most of the Information Needed findings we've seen. The App Review Information section in App Store Connect is supposed to close that gap, but it often gets left half-filled when you're rushing a submission out.
What the reviewer actually needs from you
Five things, roughly in the order they'll hit them:
1. A demo account that works on a fresh device, right now. Not the account you used six weeks ago. Not an account behind email verification or an SMS code. A reviewer cannot check their own phone or a shared inbox for a code, so any account that requires one is functionally the same as no account at all.
2. Where the paid features are. If your app has a subscription or in-app purchase, tell the reviewer how to reach it. Don't make them guess through five screens to find the paywall, and don't assume they'll stumble into it the way an ordinary user might.
3. How to reach account deletion. This is a separate guideline (5.1.1(v)) but reviewers often check it in the same pass, and if your demo account doesn't have visible access to whatever menu holds it, that's a second rejection stacked on the first one.
4. What any hardware feature does, and how to test it without the hardware. If your app uses a barcode scanner, Bluetooth device, or camera-based feature tied to physical equipment the reviewer doesn't have, explain in the notes what the feature does and, if possible, provide a way to see the result without the hardware (a demo mode, sample data, a video isn't a replacement but a clear text description is better than silence).
5. A sandbox purchase path that actually completes. If you have in-app purchases, the reviewer may try to buy one. Make sure the sandbox product IDs match what's in App Store Connect and that a purchase completes end to end, since a paywall that errors out or spins forever produces a related but separate rejection (2.1(b)), and it's worth ruling out before you submit.
A copy-paste notes template
Fill in the brackets and delete anything that doesn't apply to your app. Keep it to three to five lines if you can; a wall of text gets skimmed, not read.
Demo account:
Username: [demo email or username]
Password: [current password, tested today]
After signing in, tap [screen/tab name] to see [the main feature].
Paid features are under [path, e.g. "Settings > Upgrade"]. The demo
account is on the [free / trial / active subscription] plan.
Account deletion is under [path, e.g. "Settings > Account > Delete
Account"].
[If applicable] This app uses [hardware, e.g. a Bluetooth scale /
barcode scanner]. Without the hardware connected, [what the reviewer
will see instead, or how to see sample results].
Before you submit, log in with that exact account on a device you haven't touched in a while, in a fresh browser session or after signing out completely. If anything in the notes is stale, the reviewer will find it before you do.
Four mistakes that cause this rejection even when the notes exist
The demo password expired. A lot of these accounts get created once, at launch, and never touched again. If your backend expires passwords or sessions after 90 days, or if the account got swept up in a "clean up test users" script, the reviewer hits a login error and reports it as Information Needed even though notes were technically provided.
Two-factor authentication is on for the demo account. If your auth provider defaults to requiring 2FA for new accounts, that setting can quietly apply to your reviewer account too. The reviewer has no way to receive that code, and there's no field in App Store Connect for you to hand it to them. Turn 2FA off for this one account specifically, or build a separate reviewer role that bypasses it.
The notes describe a screen that moved. You wrote the notes for version 1.0, and by the time review actually happens you're on 1.3 with a redesigned nav bar. "Tap the third icon on the bottom" is now wrong. Notes describing paths through the UI go stale fast if you're shipping frequently, so it's worth a thirty-second check on every submission rather than assuming last time's notes still apply.
Marketing copy pasted into the notes field. The App Review Information notes field is not the App Store description. A reviewer reading "Revolutionary AI-powered productivity for everyone!" instead of "tap Projects to see the main feature" has to guess where to click, and guessing is exactly what produces the rejection you're trying to avoid. Write the notes like you're handing a stranger a set of directions, because that's what they are.
One more thing worth knowing
Not every Information Needed rejection requires a new build. Once you fix the App Review Information (demo account, notes, whatever was missing), you can usually reply in the Resolution Center without resubmitting a build at all. Save the new-build cycle for actual bugs; a missing or broken login is a paperwork fix, not a code fix.
If you want the fuller breakdown of what a 2.1 rejection can mean beyond Information Needed, including crashes, broken flows, and purchases the reviewer couldn't reach, I wrote a longer reference here: https://neumax-labs.github.io/guideline/guideline-2-1-app-completeness.html
