Store rules and why apps get rejected
Rejection is not a technical problem but a planning problem: you have a launch date, the campaign is ready, then the app fails review and everything slips. So knowing the rules in advance is marketing work, not legal work.
The clauses in Apple's App Review Guidelines that most often hit vibe-coded apps:
- 2.1 App Completeness — what you submit must be a final version: all metadata present, URLs functional. Placeholder text, empty websites and temporary content must be scrubbed. The app must be tested on-device; if it has a login you must include demo account info and turn your backend on
- 4.2 Minimum Functionality — the app must be more than a repackaged website. Apple states plainly: if your app is not particularly useful, unique or "app-like", it does not belong on the App Store
- 4.3 Spam — multiple Bundle IDs of the same app, or apps indistinguishable from what is already widely available, are not allowed
- 2.3.7 — choose a unique app name and keywords that accurately describe your app; do not pack metadata with trademarked terms, popular app names or irrelevant phrases. App names are limited to 30 characters
- 5.1.1 — the privacy policy link must be in the App Store Connect metadata field and inside the app, easily accessible
| Typical mistake | Which rule it touches | How to prevent it |
|---|---|---|
| There is a login but no demo account given | Apple 2.1 | Include a demo account in the submission and verify the backend is up |
| The privacy policy URL does not open | Apple 5.1.1 | Open the URL on a different device before submitting |
| The app just shows a page from your website | Apple 4.2 | Add at least one real app capability (offline, notifications, device features) |
| A competitor's brand in the keywords | Apple 2.3.7 | Use only words that describe your own app |
| Declared data does not match what the app collects | Both stores' privacy policies | Fill the questionnaire by reading the code, not from memory |
| Screenshots showing a feature the app lacks | Apple 2.3 (accurate metadata) | Build screenshots from real screens |
Clause 4.2 matters especially for vibe coding. A large share of apps built quickly with AI send one request to one API and display the answer. For Apple that is often not enough — the phrase "repackaged website" in the guidelines means exactly this.
That does not mean scrapping the app. The practical fix: add something only an app can do — offline behaviour, notifications, integration with the device camera or microphone, a widget, hooking into the share sheet. One of these is usually enough.
Clause 4.3 points at a different risk: shipping dozens of near-identical apps from one template. Vibe coding makes that technically easy and therefore tempting, but Apple forbids it directly.
The first reaction to a rejection is to argue. In practice the faster route is: read the rejection literally, find which clause it cites, read that clause in the guidelines, and fix only that problem. You can add an explanation in the review notes — but an explanation does not substitute for a fix.
Practice. Read clauses 2.1, 4.2 and 5.1.1 of the App Review Guidelines and grade your own app "passes / fails / not sure" against each. Done means: every clause graded "not sure" has a corresponding fix task written down.
📚 Sources and documentation
- App Store Review Guidelinesofficialdeveloper.apple.com
2.1, 2.3.7, 4.2, 4.3, 5.1.1 — the source for every clause named above.
- Google Play Developer Program Policyofficialplay.google
Content, metadata and data policies on the Play side.
- Prepare your app for reviewofficialsupport.google.com
The steps Play requires before review.
- User Data policyofficialsupport.google.com
Matching your declaration to actual behaviour — the area that causes the most trouble.