App Store rejection: Guideline 2.1 app completeness, and how to fix it

What App Store Guideline 2.1 says

Apple's Guideline 2.1 (App Completeness) says submissions to App Review should be final versions with all necessary metadata and fully functional URLs included. Placeholder text, empty websites, and other temporary content should be scrubbed before submission.

Apple also asks you to make sure your app has been tested on-device for bugs and stability before you submit, and to include demo account info, with your back-end service turned on, if your app includes a login. If you cannot provide a demo account for legal or security reasons, Apple allows a built-in demo mode in lieu of an account, with prior approval, and the demo mode must show the app's full features and functionality.

Apple states plainly that it will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems. The full text is on the App Store Review Guidelines page.

Why apps get rejected under 2.1

Common triggers:

• The app crashes on launch or during a core flow on the reviewer's device.
• A login screen with no demo account, or a demo account that does not work, or a back-end that was switched off during review.
• Placeholder text such as "Lorem ipsum," empty screens, "coming soon" sections, or buttons that do nothing.
• Broken links, including a privacy policy or support URL that returns an error.
• Features that work in the simulator but break on a real device or a different iOS version.

Apple frames 2.1 around finishing the app. If the reviewer hits a dead end, a crash, or a blank screen, the app reads as incomplete.

How to fix it

1. Reproduce the crash. Read the rejection and any attached crash logs, then reproduce the issue on a physical device, not only the simulator. Fix the underlying cause and confirm stability across a full run of the app.
2. Provide a working demo account. If there is a login, add demo credentials in the App Review Information section, and make sure your back-end is running for the entire review. Confirm the account can complete the core flows.
3. Scrub placeholder content. Remove "Lorem ipsum," empty sections, dummy data, and any "coming soon" state. Every screen the reviewer can reach should be real.
4. Check every URL. Verify the privacy policy, support, and marketing URLs all load. Fix or remove dead links.
5. Test across devices and iOS versions. Run the core flows on more than one device and on the iOS versions you support, then beta test through TestFlight before submitting.

Submitted is not approved. Even a clean resubmission is reviewed again, so the goal is an app that holds up on the reviewer's device.

How AppFlight helps

AppFlight runs your app in a live iOS simulator as it builds and puts it through an automated test gate before you submit, which catches a class of crashes and broken states that lead to 2.1 rejections. When Apple returns a 2.1 rejection, AppFlight reads the rejection reason, works on the fix, and resubmits the build. Because 2.1 often comes down to a crash or a broken flow in the code, this is where reading and re-fixing the build is most direct. AppFlight does not guarantee approval. Apple reviews every app and every resubmission on its own devices, so on-device testing and a working demo account still matter.