Guideline 2.1 Rejection: How to Fix App Completeness Issues and Resubmit
Guideline 2.1 — Performance: App Completeness — is the single most common App Store rejection. It is Apple's catch-all for "the app didn't work when we tried it": crashes on launch, obvious bugs, placeholder content, broken links, or a login screen the reviewer couldn't get past. It also covers the milder "information needed" message, where Apple pauses the review and asks you a question instead of rejecting the build outright.
What Apple's rejection email says
"Guideline 2.1 — Performance — App Completeness. We discovered one or more bugs in your app when reviewed on iPhone running iOS 18. Specifically, the app displayed an error message after we tapped the Sign In button. Next Steps: Test your app on devices to identify and resolve bugs and stability issues before submitting for review."
A common variant: "We are unable to complete the review of your app because we need a demo account to fully assess its features. Please provide a demo account with full access in the App Review Information section."
Typical App Review wording for Guideline 2.1. Exact text varies per app.
Why apps get rejected under 2.1
Almost every 2.1 rejection comes down to one of these root causes:
- Crash or error under review conditions. The reviewer's environment is not yours: a clean install, often on an IPv6 NAT64 network, sometimes on an iPad even when your app is iPhone-only (iPhone apps are reviewed for iPad compatibility too). Backend outages during the review window count as your bug.
- Login the reviewer can't pass. No demo account provided, an expired demo account, SMS/2FA verification the reviewer can't receive, or social-only login with no test path.
- Placeholder or incomplete content. Lorem ipsum text, "coming soon" screens, empty states with no data, dead buttons, or beta/test labels left in the UI.
- Broken links. The support URL or privacy policy URL in App Store Connect returns a 404, or in-app links go nowhere.
- Server-side features not live yet. If your backend gates features by version or region and the review build hits an empty API, the reviewer sees a broken app.
"Information needed" messages under 2.1 are not failures — Apple is asking how a feature works, where hidden functionality lives, or for credentials or documentation. The review clock is paused until you reply in App Store Connect.
Step-by-step fix
- Read the rejection in App Store Connect, not just the email. Open App Store Connect → your app → App Review. Apple often attaches screenshots and, for crashes, a
.crashlog you can download. - Reproduce with a clean install. Delete the app from a device, install the exact review build via TestFlight, and run it on a first launch with no cached state. Test on both iPhone and iPad.
- Symbolicate any crash log. Drag the attached crash log into Xcode's Devices and Simulators window, or check Xcode → Organizer → Crashes for the same signature, then fix the underlying bug.
- Test on an IPv6 network. On a Mac, enable Internet Sharing with "Create NAT64 Network" (hold Option when opening Sharing settings) and run the app through it. Hard-coded IPv4 literals and some legacy networking code fail here.
- Fix the demo account. In App Store Connect → App Review Information, enable "Sign-in required" and provide a working username and password with access to every feature. Disable 2FA/SMS verification for that account, or add a reviewer bypass code, and confirm it works from a logged-out state.
- Sweep for placeholders and dead ends. Search the build for lorem ipsum, empty screens, disabled buttons and "beta" labels. Verify the support URL and privacy policy URL load in a normal browser.
- Keep the backend up. If features are server-gated, make sure the review build's API responses are fully populated for the entire review window.
How to resubmit
If Apple asked for information, reply directly in App Store Connect → App Review (the thread under the rejection message) — no new build needed, and the same reviewer usually continues within a day or two. If you fixed a bug, upload a new build with an incremented build number, select it on the version page, and click "Add for Review" / "Submit to App Review". Resubmissions typically get reviewed within 24–48 hours. Appeals to the App Review Board are only worth it if you believe the rejection is factually wrong — roughly 85% of appeals are denied, so fixing and resubmitting is almost always faster.
How AscAuto handles 2.1 rejections
When you forward a 2.1 rejection to AscAuto, it classifies the sub-case first. For "information needed" requests it drafts a complete reviewer reply — including demo credentials from your app profile — and holds it for your one-click approval before posting. For crash and bug rejections it produces a diagnosis (guideline, likely root cause, affected flow) and, if you've connected GitHub, proposes the fix as a pull request you review and merge yourself. Nothing is sent to Apple without your approval.
FAQ
How long does a resubmission take after a 2.1 rejection?
Most resubmissions are reviewed within 24–48 hours. Replies to "information needed" messages are often handled even faster because the same reviewer picks the thread back up without restarting the queue.
Apple says my app crashed, but it works fine on my devices. What now?
Test a clean install of the exact review build, on both iPhone and iPad, and on an IPv6 NAT64 network. Also download the crash log Apple attached in App Store Connect and symbolicate it in Xcode — it usually points at the exact frame. Backend downtime during review is another common culprit.
Do I need a new build to answer an "information needed" message?
No. If Apple only asked a question or requested credentials, reply in the App Review thread in App Store Connect. You only need a new build if you actually changed code.
Where exactly do I put the demo account?
App Store Connect → your app → App Review Information (on the version page). Turn on "Sign-in required" and enter a username and password that reach every feature, with no SMS or 2FA challenge in the way.