Why Apple rejected your first app

“Rejected four times” and “every time I fix one thing they find another” are the two most common sentences in forums for first-time iPhone developers, usually followed by the conclusion that review is random. It is not. Apple publishes the reasons, and the same handful catch almost every first app. Here they are, in the order they will catch you.

1. It was not finished (guideline 2.1)

Apple says the single most common reason apps fail review is completeness: the app crashed, had placeholder content, a link that went nowhere, a feature that did nothing, or a sign-in the reviewer could not get past. Reviewers are people with a phone and about a quarter of an hour. Anything a stranger can break in that time, they will.

The fix is boring: submit the smallest app that works all the way through. Five screens that all do what they say beat twelve where two are “coming soon”. Delete every placeholder. Click every link. If there is a sign-in, provide a demo account in the review notes, or let the reviewer in without one.

2. It needs a privacy policy, and a real one

Every app needs a privacy policy URL, in the store listing and inside the app, that describes what the app actually collects. “We don’t collect anything” is a valid policy if it is true; a missing page is an automatic rejection. Match it to the privacy questions you answer in the console, because reviewers compare them.

3. It looked like a template (guideline 4.2.6)

Apps built from the same template, submitted by a service on behalf of many clients, are rejected unless the content owner submits their own app from their own account. If you started from a starter or a template, that is fine, provided you submit it yourself and it is clearly your app: your content, your name, screens that do your job. A starter with the sample content still in it is both unfinished and a template, and fails twice.

4. It looked like a thousand others (guideline 4.3)

In June 2026 Apple rewrote its spam rule to say, plainly, do not submit apps that are indistinguishable from what is already widely available. This is the rule that AI-generated apps run into: a generic to-do list, a generic calculator, a generic quote-of-the-day. The defence is specificity. An app for your swim club’s fixtures is not indistinguishable from anything. Make the specific job visible on the first screen and in the store description.

5. It was really a website (guideline 4.2)

An app that is a web page in a shell, with no behaviour you could not get in a browser, falls under minimum functionality. Use the phone’s own controls, make it work offline where it can, and give it a reason to be an app.

6. The checklist, before you press submit

• Every screen reachable, every tap does something, no placeholder text anywhere.
• A demo login in the review notes, or no login wall.
• A privacy policy URL that matches your privacy answers.
• Your own content and name, submitted from your own account.
• One sentence in the description that says the specific job the app does.
• Release set to manual, so an approval does not publish before you are ready.

Apple reviews about nine in ten apps within a day, so a clean first submission can be live by the weekend. The rounds come from skipping the list.

If you are designing in the App Builder, the review step before handover already refuses to send an app with incomplete screens to your agent, which is the first item on this list enforced before any code exists. The rest of the list is still yours.