On this page (11 sections)
What 2.1 covers
Apple asks for final builds with complete metadata, no placeholders, and full functionality available to the reviewer — including demo accounts where the app needs sign-in. A 2.1 message may cite one of these:
- Crashes and bugs — with the device and OS listed, often with a crash log attached.
- Broken or unfinished features — buttons that do nothing, empty screens, “coming soon” labels.
- Backend or API unavailable — the app loaded but its content did not.
- Login / demo account — the reviewer could not sign in or reach gated features.
- In-app purchases not reviewable — products missing, not loading, or not submitted with the build.
- Placeholder content and broken URLs — lorem ipsum, dead support or privacy links.
- Information Needed — the reviewer has questions before deciding.
Crashes: reproduce on the cited configuration
- Read the device model and OS version in the message. Test on that class of device (or the simulator plus a physical device) with that OS.
- Use the release build from App Store Connect (TestFlight), not a debug build — optimisations, missing entitlements and configuration differences cause release-only crashes.
- Symbolicate any attached crash log. Look for third-party SDK frames, missing usage descriptions (privacy-related crashes on permission access), and network calls to staging hosts.
- Test with a fresh install, no cached data, on a device that has never signed in.
Backend and API availability
Reviews happen at times and from locations you do not control. Staging servers, expired TLS certificates, IP allow-lists, rate limits and maintenance windows all produce blank screens and “bugs” from the reviewer’s side. The build under review must talk to a backend that is up, reachable worldwide and populated with data for the duration of the review.
Demo account and SSO
Provide a demo account in App Review Information that never expires, is entitled to every feature, and does not require an OTP the reviewer cannot receive. If the app uses SSO only, add an email/password path for the review account or provide a pre-authenticated review flow. Update the credentials in App Store Connect every time they change — many repeat 2.1 rejections are simply stale credentials.
IAP reviewability
If your app offers in-app purchases, submit the products with the build, make sure they load in the sandbox, and say in the review notes where to find them. Guideline 2.1 requires in-app purchases to be complete, up to date, visible to the reviewer and functional, and asks you to explain in the review notes why a configured product cannot be found or reviewed — so a product the reviewer cannot reach can lead to a Guideline 2.1 rejection even though the cause is StoreKit configuration. Which rule Apple actually applied is decided by the notice you received, so respond to its wording rather than to an assumed guideline. If the products do not load for you either, work through in-app purchases not showing or failing before resubmitting.
Placeholders, broken URLs and unfinished features
Search the build for “lorem”, “TODO”, “coming soon”, “test” and empty screens. Check that every URL in the app and the listing (support, privacy policy, terms) opens. Hide or remove features that are not ready rather than shipping them disabled.
Review notes that prevent the second rejection
Use the notes field to explain anything a stranger would not know: how to reach gated features, what needs hardware, what the demo account already has, and any behaviour that might look like a bug but is intended. Include a video link for flows that depend on external devices or real-world actions.
The cold reviewer test
Install the exact TestFlight build on a clean device, hand it to someone who has never used the app together with your review notes, and ask them to reach every feature. If they cannot, fix the path or the notes before resubmitting.
Fix, reply or new build?
| Situation | Response |
|---|---|
| Crash, bug, broken feature, missing content | Fix and upload a new build; describe the fix in the notes |
| Reviewer could not sign in | Provide working credentials in App Store Connect; a new build is needed only if the login itself is broken |
| Backend was down during review | Confirm availability, reply in the thread and ask for a re-review; keep the same build if nothing else changed |
| Information Needed | Answer each question in the thread before doing anything else |
| Reviewer misunderstood intended behaviour | Reply with an explanation and screenshots; add it to the review notes for next time |
Resubmission checklist
- Release build tested on the cited device class and OS with a fresh install
- Crash logs symbolicated and the defect fixed, not just retried
- Backend reachable from outside your network; certificates valid; test data present
- Demo account works, never expires, and reaches every feature; OTP bypassed for that account
- IAP products submitted and loading in sandbox
- No placeholders; every URL opens
- Review notes updated; cold test passed
What we can implement
Crash diagnosis and fixes on iOS native, Flutter, React Native and Unity; release-build QA on real devices; review-account and OTP bypass logic; StoreKit configuration; backend reachability and environment fixes; and review notes written from a verified test script.