If you shipped your app with an AI builder, there's a good chance you've only ever opened it as yourself: same phone, same account, already signed in, always online. That's exactly the situation App Review never tests. A reviewer is a stranger with a fresh device, no history, and a habit of doing the one thing your happy path never expects.
Most rejections we've seen for AI-built apps aren't about missing features. They're about a two-minute scenario nobody ran before hitting submit. Here are seven of them, each cheap enough to run tonight.
1. First launch in airplane mode
What to do: Delete the app, reinstall it, turn on airplane mode, then open it for the first time.
What failure looks like: A blank white screen, an infinite spinner, or a crash. Nothing tells the person what happened or what to do next.
Why it matters: A reviewer sometimes tests on a poor or absent connection, and a failed first fetch that leaves a blank screen reads as a crash, not a network hiccup. This is a fast, common failure in apps built by wrapping a web app in a native shell, because the shell's first load usually depends on a network call that has no fallback. The fix is small: catch the failed request and show a message with a retry button. A reader pointed out this exact test after reading our full checklist, and it's now one of the fastest ways to fail an app that otherwise works fine.
This falls under Guideline 4.2, minimum functionality: whether the app is "sufficiently different from a mobile browsing experience" and behaves like a native app rather than a website with no error handling.
2. Fresh install on an iPad
What to do: If you built for iPhone, install the app on an iPad (a simulator is fine) and check both orientations.
What failure looks like: Layouts that overlap, buttons cut off at the edge, text that doesn't reflow, or a screen that only works in portrait when the reviewer tries landscape.
Why it matters: Review often runs on an iPad even for apps that were designed and tested only on iPhone. Many builders assume the reviewer uses the same device class you developed on. They frequently don't, and a broken iPad layout is treated the same as a broken iPhone layout: an app that doesn't work is an app that doesn't work, regardless of which guideline number ends up on the rejection.
This can land under Guideline 2.1, app completeness, the umbrella category for "the app doesn't function as submitted."
3. Sign up as a stranger on the free plan
What to do: Create a brand-new account using an identity you've never used with the app before, ideally a fresh Apple ID with "Hide My Email" turned on, and go through the free tier, not your own admin or test account.
What failure looks like: The sign-in call succeeds, but the screen doesn't change until you force-quit and relaunch. Or the account lands in a state your team never designed for, like a plan with no default data.
Why it matters: We've seen a real case where sign-in technically worked but the UI stayed frozen on the login screen until the app was restarted, and Apple reported it simply as "not responsive." Your own account has weeks of history and cached state that hides this. A stranger's account has none of that, so it exposes the empty states you never built a screen for.
If the app offers Google or another third-party login, this test also covers Guideline 4.8: Sign in with Apple needs to be offered as an equal option, using Apple's button style, and it needs to actually respond when tapped.
4. Delete the account from inside the app
What to do: Find the account deletion option and use it, end to end, on a real device, then confirm the account is actually gone rather than just logged out.
What failure looks like: There's no deletion option at all, or it only signs the user out, or it's buried three menus deep in a place nobody would look, or it just deactivates a flag in the database without deleting anything.
Why it matters: Guideline 5.1.1(v) requires that any app supporting account creation must let users initiate deletion from inside the app, and Apple sometimes asks for a screen recording of the flow on a physical device. AI builders generate sign-up and log-out by default because those are the common tutorial flows; deletion is rarely part of the template, and when someone adds it later, it tends to end up in the wrong place or short of "actually delete the data."
5. Restore purchases
What to do: If you sell anything through In-App Purchase, buy it on a sandbox account, delete and reinstall the app, then tap "Restore Purchases" instead of buying again.
What failure looks like: Nothing happens, the button doesn't exist, or the restored state doesn't match what the person actually paid for.
Why it matters: This sits close to Guideline 3.1.1, in-app purchase. Product IDs need to match exactly between App Store Connect and your billing code, and a mismatch is what makes a paywall come up empty or a restore silently fail for the reviewer. It's also good practice: a real user who reinstalls and can't get back what they paid for is a fast route to a one-star review and a refund request.
6. Deny every permission prompt
What to do: Go through the whole app and tap "Don't Allow" on every permission request: camera, photos, location, microphone, contacts, notifications, whatever the app asks for.
What failure looks like: A feature that just silently does nothing, a crash, or a dead-end screen with no way to grant the permission later without deleting the app.
Why it matters: This connects to Guideline 5.1.2 privacy questions and general completeness. Every prompt is supposed to explain, in a full sentence, why it's asking, something like "Used to attach photos you choose to your notes," not just the OS default text, and only when the user reaches that feature, not all at once at launch. Beyond the wording, the app still needs to work, or at least fail gracefully, when someone says no. Reviewers deny prompts more often than typical users do, since it's a standard part of how they test.
7. Demo account from the review notes, on a fresh device
What to do: Take the demo credentials exactly as you wrote them in App Review Information, and log in with them on a device or simulator you haven't touched before, following only what the notes say.
What failure looks like: The password has expired or was tied to a test environment that got reset, the account triggers an SMS or email verification step nobody mentioned, or the notes describe a screen that no longer exists because the app changed since you wrote them.
Why it matters: A missing or broken demo login is one of the more common causes of an "Information Needed" hold under Guideline 2.1, and it's entirely self-inflicted. The credentials were fine when written, but nobody rechecked them against the build actually being submitted. If the account needs email or SMS verification to get past login, it isn't a working demo account, and reviewers won't chase down a second factor to get in.
None of these take longer than a coffee break, and together they catch the failures that show up disguised as random-looking guideline numbers on a rejection. The full pre-submission list these came from, with plain-language explanations of each guideline, is free here: https://neumax-labs.github.io/checklist.html
