TL;DR: Four App Review guidelines account for most indie rejections: 2.1 App Completeness, 5.1.1 Privacy, 4.2 Minimum Functionality, and 3.1.1 In-App Purchase bypassing. Three more hit metadata and screenshots specifically: 2.3.3, 2.3.1, and 4.3. The split that matters for your week is not severity, it is whether the fix lives in your binary or in App Store Connect: metadata and screenshot rejections need no new build and no review queue for the asset itself, so they resubmit the same day. Binary rejections do not. Work out which one you have before you write a single line of appeal.
Most posts on this subject open with a rejection-rate statistic. We are not going to, because we could not source one. Apple's transparency reports cover government data requests, and its App Review figures appear in an annual fraud-prevention analysis that does not break rejections down by cause. Any post quoting "X% of submissions were rejected last quarter, Y% of those for screenshots" is quoting a number that does not have a published source. What follows is built instead on our App Store rejection codes reference, covering 20 guidelines, each linked to Apple's own text and tagged with how often it actually shows up.
The seven that actually hit indie apps
Four of the twenty are tagged very common. Three more are common and land specifically on metadata and screenshot work, which is where most solo developers get caught after the app itself is fine.
| Guideline | What triggers it | Fix lives in |
|---|---|---|
| 2.1 App Completeness | Crashes, placeholder content, a demo account that does not work | Binary |
| 5.1.1 Privacy: Data Collection | Privacy labels that do not match what the app actually collects | Both |
| 4.2 Minimum Functionality | App reads as a repackaged website or a thin wrapper | Binary |
| 3.1.1 IAP: Bypassing | Steering users to pay outside Apple's system | Binary |
| 2.3.3 Metadata: Screenshots | Screenshots showing something the app does not do | App Store Connect |
| 2.3.1 Metadata: Misleading | Description promising features that are not shipped | App Store Connect |
| 4.3 Spam | Too similar to an app you or someone else already shipped | Varies |
The same-day ones: 2.3.3, 2.3.1, and the privacy half of 5.1.1
This is the distinction worth internalising. A 2.3.3 screenshot rejection does not require a new build. You replace the assets in App Store Connect and resubmit. No archive, no upload, no waiting on processing. The same is true of a 2.3.1 description rejection and of the label half of a 5.1.1 privacy rejection, where the app's behaviour is fine and the declared labels were wrong.
A 2.1 or 4.2 rejection is the opposite. You are shipping a new binary, which means a build, an upload, processing time, and a fresh review. Treating these two categories the same way is what turns a one-day fix into a one-week fix. Teams write a careful appeal for a screenshot problem they could have simply corrected, and lose the review cycle waiting for a reply.
2.3.3 is worth dwelling on because it is the one most often misread. Reviewers are not judging whether your screenshots are attractive. They are checking whether the screenshots depict the app. A composited marketing image is fine; a screenshot showing a feature behind a paywall the reviewer cannot reach, or a screen that no longer exists after a redesign, is not. The most common version of this among indie apps isn't deception. It is a screenshot set that was accurate two releases ago.
Appeal, or fix and resubmit?
Fix and resubmit when the reviewer is factually right, even partially. It is faster than any appeal, and appealing a rejection you could have fixed in twenty minutes costs you the queue position for nothing.
Appeal when the rejection rests on a factual error about what your app does: a reviewer who could not find a feature, hit a login wall, or tested on a configuration you do not support. In that case give them a path rather than an argument: exact steps to reach the feature, working demo credentials, and a note about anything region- or device-specific. The App Review Board decides on evidence, so the appeal that wins is usually the one that makes the reviewer's next attempt succeed, not the one that explains why the first attempt was unfair.
One thing not to do: resubmit unchanged with a longer note. That reads as ignoring the rejection and tends to produce the same outcome more slowly.
The localization trap
Here is a failure mode that only appears once you ship to more than one market, and it catches people who did everything right in English.
App Store metadata limits are enforced per locale. The app name field is capped at 30 characters in every language you ship, not 30 characters for your English name and whatever the translation happens to need. German runs roughly 35% longer than English, so a 26-character English name that sits comfortably inside the cap projects to about 35 characters in German and will not be accepted as written. The same arithmetic bites the 30-character subtitle.
This is not a review rejection in the 2.3.x sense, but it lands in the same week and feels identical from your side: the submission does not go through, and you find out at the worst possible moment. It is also completely predictable in advance. Our App Store localization checker takes an English string and reports how many of the 41 App Store languages it still fits in, per field. If the answer is "39 of 41", you shorten two names before commissioning the translations instead of after.
The right-to-left languages carry a second, quieter version of the same problem. Hebrew barely expands, so a length check calls it safe. But the layout mirrors, and a screenshot set built left-to-right does not survive the flip. Arabic, Persian, Urdu, and Hebrew all need the layout rebuilt, not just the text swapped.
Preventing the next one
Two habits remove most repeat rejections. First, re-shoot screenshots whenever a release changes a screen you featured. The 2.3.3 rejections that hurt are almost always drift, not deception. Second, re-check privacy labels whenever you add an SDK, because analytics and crash-reporting libraries collect on your behalf and 5.1.1 is judged on actual behaviour rather than intent.
If you are building out multiple store listings, the same discipline applies per variant: each Custom Product Page carries its own screenshot set and its own exposure to 2.3.3. More variants mean more surfaces that can drift out of date. For the broader list of what to avoid before you submit at all, see our guide to App Store screenshot mistakes.
Frequently asked
How long does an App Store rejection take to resolve?
It depends entirely on whether the fix is in your binary or in App Store Connect. A metadata or screenshot correction can be resubmitted the same day, because you are not shipping a new build. A code fix means a new build, upload, processing, and a fresh review cycle. The rejection reason tells you which one you have.
Does a rejection hurt my app's ranking?
No. Rejections are a review outcome, not a ranking signal, and there is no published evidence that a rejected submission affects App Store search placement. What does cost you is time in the queue. A rejection you could have avoided is a release week you do not get back.
Can I appeal and resubmit at the same time?
You can, but it usually works against you: a new submission supersedes the one under appeal, so you lose the appeal you filed. Pick one. If the reviewer is right, fix and resubmit. If the reviewer made a factual error about the app, appeal and wait.
Why do App Store screenshot rejections keep happening after a redesign?
Because screenshots are static assets that do not update with the app. Guideline 2.3.3 requires screenshots to depict the app as it currently is, so a redesign silently invalidates every screenshot showing a changed screen. Reviewers do notice, and the fix (re-shooting and re-uploading) is a same-day one that most teams simply forget to schedule alongside the release.