What actually goes into an App Store rejection, and how to avoid the common ones

A rejected App Store submission can cost a week or more of back-and-forth correspondence with Apple's review team, which is genuinely painful when a client has already publicly announced a specific launch date to their own audience. Most of the rejections we've dealt with directly, across a range of client apps, trace back to a small, fairly predictable set of causes, and checking for them deliberately before submission has saved multiple client launches from slipping past their announced date.

Apple rejects apps containing obvious placeholder text, broken navigation links, or features that don't fully function yet more often than almost any other single cause we've tracked. "We'll finish that part after approval, it's just a small remaining piece" doesn't work as a strategy here, and reviewers treat it as a genuine reason to reject rather than a minor oversight.

Every screen a reviewer can plausibly reach during a normal test needs to function as if it were already fully live in production, not as a demo or a work-in-progress preview of what's coming next.

If your app requires an account to see anything meaningful at all, Apple's reviewer needs working, currently valid demo credentials included directly in the submission notes, every single time, without exception. We've watched otherwise genuinely solid, well-built apps get rejected purely because the reviewer hit a login screen with no way forward, and the whole app got treated as unreviewable rather than as a small technical oversight in the submission process.

Digital goods and subscriptions sold inside an iOS app generally must route through Apple's own in-app purchase system, not an external payment processor, or the submission gets rejected outright, often with a fairly terse explanation. Physical goods and services that are consumed outside the app itself are typically fine with an external payment method instead.

Getting this specific distinction wrong is one of the more expensive mistakes to discover late, because it usually means restructuring the entire payment flow after a rebuild timeline has already been scheduled and communicated to the client's own stakeholders.

Apple's privacy nutrition label has to accurately reflect exactly what data the app collects and why, cross-referenced by the reviewer against the actual behavior of the code, including any third-party SDKs bundled into the build for analytics, crash reporting, or advertising purposes. A mismatch between the declared label and the app's real, observed data collection, even a genuinely accidental one introduced by a third-party analytics SDK nobody fully audited, is a rejection reason we now check explicitly, line by line, before every single submission.

Beyond functional rejections, Apple also rejects submissions for metadata issues: screenshots that don't accurately represent the actual app, a description that overstates functionality, or keywords stuffed unnaturally into the app name field. These rejections are usually faster to resolve than functional ones, but they still cost a full review cycle, typically a day or two.

We keep screenshots and descriptions updated alongside every functional change now, specifically so this category of rejection doesn't stack on top of a launch that's already tight on time.

We keep a running internal checklist of every rejection reason we've personally encountered across all our client apps, updated after every submission, because Apple's own guidelines shift often enough that institutional memory from real recent rejections is more reliable than the published documentation alone.

By a client's second or third app, we've usually built a project-specific pre-submission checklist informed directly by whatever caused friction the first time around, on top of our general list. This tends to make later submissions noticeably smoother, since the specific issues that tripped up one particular app or one particular reviewer's interpretation of a guideline rarely repeat once they've been documented and checked for explicitly.

Not every rejection is correct, and Apple's own review guidelines acknowledge that reviewers make judgment calls that sometimes miss context a developer has and the reviewer doesn't. When a rejection reads as a genuine misunderstanding of the app's actual functionality rather than a real guideline violation, we file a specific, evidence-based appeal through Apple's formal resolution process rather than simply resubmitting and hoping a different reviewer sees it differently.

A well-written appeal that directly addresses the reviewer's specific stated concern, with a screen recording or clear written explanation attached, succeeds more often than most developers expect, and it's almost always faster than the alternative of quietly reworking a feature that didn't actually need to change in the first place.

For apps we build for both platforms, we've learned that Google Play's automated and human review process catches a genuinely different set of issues than Apple's does, weighted more heavily toward permissions usage, target API level compliance, and policy violations around sensitive categories like financial services or health data. An app that sails through Apple review can still get flagged on Play for requesting a permission the listing doesn't clearly justify.

We now run separate, platform-specific pre-submission checklists for iOS and Android rather than one shared list, because treating the two review processes as interchangeable is exactly the kind of assumption that produces an unexpected rejection on whichever platform's specific quirks got less attention during final testing.

Apple's review times fluctuate, and a client who's already booked a press announcement, an email blast, or a paid launch campaign for a specific date needs real buffer built in before that date, not an optimistic assumption that review will clear in the typical 24 to 48 hours. We now recommend submitting at minimum a full week before any externally announced launch date, specifically to absorb a possible rejection-and-resubmission cycle without it becoming a visible, public delay.

This buffer has saved more than one client from an awkward public walk-back of an announced date, and it costs nothing beyond building the submission schedule around the review process's real, honest variability instead of its best-case timeline.