Remove or finish anything that presents the submitted app as temporary: placeholder copy, blank states, dead links, disabled promises, sample data that looks broken, and beta or test language.
The short version
- Remove or finish anything that presents the submitted app as temporary: placeholder copy, blank states, dead links, disabled promises, sample data that looks broken, and beta or test language.
- First locate whether the unfinished material is inside the app or only in editable metadata. That decides whether you need a build.
- Search visible copy and code for placeholder tokens.
- Do not promise approval; give App Review a testable path.
Locate the unfinished surface
First decide whether Apple saw a temporary artefact or a legitimate empty state that lacked explanation. Name the screen, visible words, disabled control, dead link, or absent data that made the product appear unfinished.
Inspect the app with a brand-new production-like account. Walk every tab and modal, including permission denial and zero-data states. Search every submitted localisation for placeholder, sample, test, beta, coming soon, TODO, and example domains.
Audit a zero-data production account
Tap support, privacy, legal, restore, and external links over a public connection. A finished-looking main screen does not offset a dead destination elsewhere in the path Apple must evaluate.
- Search visible copy and code for placeholder tokens.
- Walk every tab from a clean account with no data.
- Tap every link and disabled-looking control.
- Review all App Store localizations for beta or temporary language.
- Remove, finish, or explain legitimate empty states.
Keep a removal list tied to screenshots or paths: what appeared, where it lived, and what replaced it. For a legitimate empty state, record the explanatory copy and the action that lets a user continue.
Separate bundled placeholders from editable copy
Bundled text, controls, and resources require a new build. App Store Connect copy or public URLs can often be corrected without one. Server-delivered content can use the existing build only after you verify the exact reviewed client now presents a complete state.
| Situation | Next action | New build? |
|---|---|---|
| Placeholder in bundled UI | Remove it and upload a build | Yes |
| Blank but legitimate empty state | Add useful empty-state guidance | Usually yes |
| Beta wording only in description | Edit App Store Connect metadata | Usually no |
| Dead support or privacy URL | Publish the final page and save the URL | Usually no |
| Coming-soon feature entry point | Remove or finish the entry point | Yes |
Route the correction by where the unfinished material lives: bundled UI changes need a binary, while an editable listing or public URL may not.
Audit what a new user sees
Use an account with zero records. Open every top-level destination and try each visible action. A blank canvas that makes sense to you can look broken to a reviewer who has no context.
Give legitimate empty states a plain explanation and a next action. Do not seed misleading content merely to fill space.
Search for temporary language
Search the production code and localized resources for lorem ipsum, placeholder, coming soon, TODO, sample, test, beta, early access, and example domains. Review server-delivered content too.
Then inspect the app name, subtitle, description, promotional text, What’s New copy, support URL, and marketing URL in every submitted localization.
Remove promises you did not ship
A future roadmap does not need a disabled button in the current release. Remove unfinished entry points until the feature works end to end. If a partial area is essential, finish the user-facing state and its failure handling before review.
Test links over a normal public connection without employee authentication.
Choose metadata edit or build
Bundled UI, resources, and controls need a build when changed. App Store Connect text and URLs may be editable without rebuilding. A remote-content correction sits between those cases: verify that the existing binary now presents a complete, stable experience.
Tell App Review exactly which temporary items were removed or completed.
If the reviewer note crosses failure classes, use the App Store rejection map to separate the placeholder content rejection symptom from unrelated issues.
Distinguish empty from unfinished
A legitimate empty state explains why no content exists and offers a real next action. An unfinished state shows temporary copy, a dead control, an unexplained blank region, or sample data that cannot be created by a user. Review the zero-data experience before adding artificial records merely to make the screen look full.
Check onboarding, every top-level tab, settings, purchase surfaces, error screens, and links. Also test an existing account whose remote objects have been deleted; that transition often exposes placeholders hidden from a brand-new account.
Audit localised and remote content
Search source strings and built resources, then inspect server-managed copy and each App Store localisation. Temporary words may exist only in one language or behind a feature flag. Confirm that review configuration points to production-ready content and that public URLs do not require employee access.
Keep future roadmap claims outside the submitted experience unless the current version can deliver them. A disabled “coming soon” control still tells the reviewer that the shipped product is incomplete.
Also inspect transition states: after deleting the last record, cancelling onboarding, restoring an account, and returning from a failed request. These moments often reveal raw identifiers, debug labels, empty containers, or disabled actions that a simple first-launch audit misses.
Review accessibility labels and VoiceOver order on the corrected empty state as well. A visually filled screen can still expose unlabeled temporary controls or unreachable actions that make the production path appear incomplete.
Verify the final zero-data journey
After correcting the surface, reinstall the release build, create a new account, deny optional permissions, and walk the route without seeded data. The user should understand the state, have a usable action, and never encounter test language or a dead end.
List each removed or completed item in the reply and identify whether the correction is in a new build, metadata, or remote content. Return to the 2.1 diagnosis if Apple also reported crashes or inaccessible functionality.
Repeat the audit with the device language changed and the network unavailable. Placeholder strings often survive in a secondary localisation, while remote examples can disappear into an empty container when the seed service cannot respond. Both states belong in the submitted experience and need intentional copy or a usable fallback.
Verify against Apple before resubmitting
Rules and App Store Connect interfaces can change. Reopen the Apple pages that support this decision before you act: App Review Guidelines, 2.1 App Completeness. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026.
FAQ about placeholder content App Store rejection
Does an empty app always violate Guideline 2.1?
No. A data-empty state can be legitimate, but it should explain why it is empty and how the user proceeds.
Can I mention future features?
Avoid presenting unfinished functionality as part of the current app. Public metadata should describe what the reviewed version provides now.
Is beta language enough to cause a rejection?
Apple’s guidelines direct beta distribution to TestFlight. Remove wording that makes a production submission read like a test version.
Can I fix placeholder metadata without a build?
Often yes, when the only issue is editable App Store Connect text or a public URL.
Conclusion
Remove or complete every temporary surface in the reviewed route, verify a legitimate zero-data journey, and state exactly where each correction now lives.
Sources and references
- App Review Guidelines, 2.1 App Completeness (accessed 2026-08-04)