The five app store rejections we see most often

App store review feels unpredictable from the outside, but in our experience the actual rejection reasons cluster around a small, predictable set of issues. Knowing them in advance turns a potential two-week delay into a non-event, and we build a pre-submission checklist against exactly these five categories on every mobile project.

The unpredictability clients perceive usually comes from encountering app review for the first time, without a sense of what reviewers are actually looking for. Once you've been through enough submissions to see the same handful of rejection reasons repeat across completely unrelated apps, the process stops feeling arbitrary and starts feeling like a checklist you can simply satisfy before submitting, which is exactly the shift we try to give a first-time client early.

Submitting a build with lorem ipsum text, broken links, or features that clearly aren't finished is an automatic rejection on both platforms. Reviewers test the actual app, not a description of what it will eventually do. We treat "submission-ready" as a distinct milestone from "feature-complete" for exactly this reason.

This distinction matters because teams under deadline pressure sometimes submit a build the moment core features work, without a final pass checking for leftover placeholder text or a settings screen that still says "coming soon." A reviewer encountering even one obviously unfinished screen will often reject the whole submission rather than evaluate the rest of the app on its merits, which makes a careful final pass genuinely worth the extra day it takes.

If your app requires an account to use anything, and you haven't provided working demo credentials in the submission notes, reviewers can't evaluate the core functionality and will reject it. This is one of the most avoidable rejections we see and one of the most common, simply because it's easy to forget while focused on the app itself.

We keep a standing demo account, pre-populated with realistic data rather than an empty new signup, specifically for submission notes on every client app that requires login. An empty account with no data still leaves a reviewer unable to properly evaluate core functionality that depends on existing content, a populated feed, a history of past orders, so the demo account needs to look like a real, active user's account, not just a technically working login.

Both platforms require an accurate, accessible privacy policy and, on iOS specifically, a detailed data collection disclosure through App Store Connect's privacy nutrition label. Disclosures that don't match what the app's actual code does, including third-party SDKs you might not have audited closely, get flagged more often than developers expect.

The third-party SDK piece is the part teams most often get wrong, since a development team can accurately describe their own code's data practices while having no idea what an embedded analytics or advertising SDK is quietly collecting in the background. We audit every third-party SDK's actual data collection behavior specifically before finalizing a privacy disclosure, rather than relying on the SDK vendor's own marketing description of what it does.

Apps offering digital goods or subscriptions have to use the platform's own in-app purchase system for those specific transactions, with narrow exceptions. Trying to route digital subscription payments through an external payment processor to avoid platform fees is one of the more common and most strictly enforced rejection categories on iOS specifically.

This one comes up most often with founders who are understandably frustrated by platform commission rates and looking for a legitimate way around them. We walk through the actual exceptions that do exist, certain categories of physical goods, services consumed outside the app, and steer clients firmly away from anything that resembles routing digital-good payments externally, since the rejection risk and potential account-level consequences far outweigh the commission savings being chased.

A build that works fine on your test devices can still crash on a reviewer's specific device and OS version. We test on the oldest officially supported OS version and a lower-end device profile before every submission, since that's a more realistic worst case than testing exclusively on the newest flagship hardware.

Development teams naturally test on whatever hardware they personally have on hand, which is usually a current-generation device, and that habit quietly excludes exactly the conditions most likely to expose a crash: an older OS version, less available memory, a slower processor handling an animation-heavy screen. We treat testing on genuinely older hardware as a required step, not an optional extra, specifically because it's the gap most likely to produce a review rejection nobody saw coming.

We maintain a small physical device lab specifically for this purpose, a handful of older iPhones and mid-range Android phones running the oldest OS versions still officially supported, rather than relying entirely on emulators. Emulated testing catches most issues, but device-specific quirks in memory handling and hardware-accelerated rendering occasionally only show up on real, aging hardware, and that gap has been worth the modest cost of keeping the physical devices around.

We run a dedicated pre-submission review against all five categories, treat it as a hard gate before clicking submit, and keep a running log of any rejection we've ever received across all client apps so the checklist keeps growing with real experience rather than staying static. Most of our submissions now clear review on the first attempt because of this discipline.

The running log has become one of our more useful internal documents precisely because app store review guidelines shift over time, and a rejection reason that wouldn't have applied two years ago sometimes becomes a live risk after a policy update. Reviewing that log before every new submission, not just relying on institutional memory, catches guideline changes a team might otherwise miss until they've already been burned by them once.

We also share a condensed version of this checklist directly with clients ahead of their first submission, not to make them do the review themselves, but so they understand why a build that looks finished to them still needs a specific pre-submission pass before it's actually ready to go to the store. That shared understanding has prevented more than one client from pushing to submit a day earlier than the checklist allowed for.