App rejected for broken links or placeholder content: 2.1 fix
What App Store Guideline 2.1 says
Guideline 2.1, App Completeness, asks you to submit a final, complete version of your app, with all necessary metadata and fully functional URLs. Apple is explicit that it does not accept apps that are demos, betas, trial versions, or otherwise incomplete, and that placeholder text, empty websites, and other temporary content should be removed before submission.
Broken links and placeholder content are the most concrete forms of an incomplete app. A link that fails, a screen of sample data, or a "coming soon" section tells the reviewer the build is not finished. The official text lives on the App Store Review Guidelines page.
Why apps get rejected under 2.1
Common triggers:
- An in-app link returns an error, points nowhere, or leads to an unfinished page.
- A metadata link, such as the support URL or the privacy policy URL, does not resolve.
- Screens contain lorem ipsum, sample data, or stock placeholder images.
- Buttons or features are visible but do nothing, or lead to a dead end.
- A section is labeled "coming soon" or is empty in the submitted build.
- The app behaves like a demo or beta rather than a finished product.
The thread is that the submitted build is not the complete, working app, which is exactly what 2.1 is written to catch.
How to fix it
- Test every link. Tap every in-app link and confirm it resolves, and check the metadata links, including the support and privacy policy URLs, in App Store Connect.
- Replace all placeholders. Swap lorem ipsum, sample data, and temporary images for the final content the app will ship with.
- Remove dead ends. Make sure every visible button and feature works, or remove it from this build until it is ready.
- Cut "coming soon" sections. Either finish the section or remove it, since unfinished areas signal an incomplete app.
- Test the shipping build. Use TestFlight to run the exact build you will submit, walk every screen, and confirm there are no placeholders, broken links, or crashes before you resubmit.
Remember that submitted is not approved. A resubmission goes back through review, and Apple walks the app again to confirm it is complete.
How AppFlight helps
AppFlight builds your native iOS app from your prompt and runs it in a live simulator with an automated test gate, so broken links, dead buttons, and obvious placeholder states can surface before you submit rather than during Apple's review. Because AppFlight runs the submission flow, it also sets the metadata links, like the support and privacy policy URLs, that 2.1 checks. When Apple returns a 2.1 rejection, AppFlight reads the rejection reason, works on the broken link or the placeholder content, and resubmits the build. AppFlight does not guarantee approval. The app still has to be genuinely complete, and Apple reviews every app and every resubmission.
FAQ
What counts as placeholder content?
Lorem ipsum text, empty screens, "coming soon" labels, sample or stock data left in the app, buttons that do nothing, and temporary images all count. Guideline 2.1 expects the submitted build to be the finished app, not a work in progress.
Do broken links really cause a rejection?
Yes. A link that returns an error, points nowhere, or leads to an unfinished page is a common 2.1 rejection. That includes in-app links and the links Apple checks in your metadata, such as the support and privacy policy URLs.
How do I make sure my app is review-ready?
Walk every screen and tap every link before you submit, on a real device or simulator, and use TestFlight to test the build you will ship. Confirm there are no placeholders, dead buttons, broken links, or crashes, since all of these fall under 2.1.