What app store review actually rejects apps for

First-time app submissions get rejected more often than founders expect, and it's rarely because of the core idea. Apple and Google's review teams reject for a fairly predictable set of specific, checkable issues, and running a pre-submission checklist against them catches most of what would otherwise cost a week of back and forth with review teams.

Apps submitted with a feature that's visibly unfinished, a button that does nothing, a section that says "coming soon", get rejected as incomplete. Review teams treat this as a sign the app isn't ready, regardless of how minor the placeholder feels to the team that built it, and regardless of whether the missing piece is planned for a fast-follow update.

If an app requires an account to see anything, and there's no way for a reviewer to access a demo account or guest mode, review can't actually evaluate the app. We build in either a public demo account or a guest browsing mode specifically to keep this from stalling a submission, and we include the demo credentials directly in the submission notes so reviewers don't have to hunt for them.

Both platforms now cross-check the privacy labels a developer declares against what the app actually does. A mismatch, collecting analytics data not disclosed in the privacy manifest, for example, is an automatic rejection. We audit every SDK and analytics tool in the app against the declared data usage before submitting, since third-party SDKs frequently collect more than a team realizes without checking their documentation carefully.

Apps selling digital content or subscriptions outside the platform's own in-app purchase system get rejected on iOS specifically. This trips up teams porting a web-first business model without realizing the platform rules are different for digital goods sold inside the app itself, versus physical goods or services, which are generally exempt from this requirement.

We run a written pre-submission checklist covering all of the above before every single app store submission, regardless of how confident the team feels. It's a fifteen-minute process that has saved us far more than fifteen minutes of back-and-forth with review teams on every project where we've caught something the checklist flagged.

Subscription apps that don't clearly disclose pricing, billing frequency, and how to cancel before a user starts a free trial are a common rejection reason, and one that's gotten stricter over time as both platforms have cracked down on subscription practices that trap or confuse users.

A straightforward rejection with a clear fix typically means a one to three day delay for the fix plus a new review cycle, which itself can take anywhere from a few hours to a couple of days depending on platform load. We build this buffer into every launch timeline rather than assuming first-submission approval.

Every rejection reason gets logged into our internal pre-submission checklist, so a mistake made once on one client's app doesn't repeat on the next one. The checklist has grown substantially over the years purely from real rejections we've learned from, not from reading platform guidelines in the abstract.

Apps that closely resemble an existing popular app in name, icon, or core functionality can be rejected for platform confusion even without any actual trademark issue. We check a new app's identity against obvious existing competitors before submission, specifically to avoid this less obvious rejection category.

Apple's review process tends to be more subjective and design-focused, while Google's is more automated and policy-focused. This means the exact same app can sail through one store's review and get flagged by the other for a completely different reason, so a pre-submission checklist needs platform-specific sections rather than one generic list applied identically to both.

Review teams occasionally give a vague rejection reason that doesn't obviously map to a specific fix. In these cases we request clarification through the platform's official resolution center rather than guessing at a fix and resubmitting blindly, since a second guess-based resubmission that misses the actual concern just costs another full review cycle.

Review times and scrutiny both tend to increase around major iOS or Android version releases, as review teams handle a surge of app updates adapting to new platform requirements simultaneously. We avoid scheduling client launches during these known busy periods where possible, since both the review timeline and rejection risk are measurably higher during these predictable industry-wide crunch windows.

We also maintain a running internal document tracking review time trends by platform and by app category, since anecdotal reports across the industry suggest certain categories, health apps, financial apps, apps handling any kind of regulated data, tend to face longer and more thorough review regardless of how clean the submission is. Setting client expectations around this category-specific reality upfront, rather than promising a generic timeline that doesn't account for it, avoids an uncomfortable conversation later if a fintech or health app takes noticeably longer to clear review than a simpler content app would.

The review process feels opaque and high-stakes to a founder submitting an app for the first time, mostly because the consequences of a rejection, real or perceived, loom larger than they actually are. A rejection is rarely fatal to a launch timeline if it's caught and fixed quickly, and it's a normal, expected part of the process rather than a signal that something has gone seriously wrong with the app or the business behind it.

We set this expectation explicitly during planning, telling founders upfront that we budget for at least one resubmission cycle in every launch timeline, precisely so a routine rejection doesn't feel like a crisis when it happens. Founders who go in expecting a possible bump in the road handle it far more calmly than ones who assumed a clean first submission was the only acceptable outcome.

Google's review process tends to move faster and surface fewer subjective concerns than Apple's, which makes it a useful early signal. When schedules allow, we submit the Android build a few days ahead of iOS, since a rejection on Android often points to a genuine issue, missing disclosures, a broken flow, that would likely trip up the iOS review too, giving us a chance to fix it once rather than getting the same feedback twice, separately, from both platforms.

App store listings themselves, screenshots, descriptions, keyword fields, go through review too, and inconsistencies between what the listing promises and what the app actually does are a real rejection category on their own. We compare the submitted listing against the actual build one more time immediately before submission, since screenshots taken weeks earlier during development sometimes no longer match a feature that's since changed.