What app store review actually checks, and how to not get rejected

A first-time app client asked us recently what app store review actually looks for, expecting a long, mysterious list of hidden requirements. The honest answer is less exotic than that: a fairly small, predictable set of issues causes the overwhelming majority of rejections, and most of them are avoidable with a careful pass before submission rather than a lucky one after.

We've submitted enough apps at this point to have a mental checklist that catches the common failure modes before a reviewer ever sees the build. None of it is secret. Most of it is published in the platform guidelines directly. It just takes actually reading them closely, which surprisingly few first-time submitters do.

The single most common rejection reason we see is simple: something breaks during the reviewer's actual testing session, a crash on a specific flow, a broken link, a form that doesn't submit correctly. These are usually not exotic edge cases. They're core flows that weren't tested thoroughly enough before submission, sometimes on a device or OS version the development team wasn't actively testing against.

We test every submission on the oldest supported OS version and the oldest supported device we can reasonably access, specifically because that's where these problems most often hide, not on whatever new device happened to be sitting on a developer's desk during the build.

Lorem ipsum text left in a screen, a broken image placeholder, a settings page with options that don't actually do anything yet: reviewers treat these as signs the app isn't actually finished, and they reject on that basis regardless of how minor the placeholder might seem to the team that built it.

We do a full content pass immediately before every submission, screen by screen, specifically hunting for anything that looks unfinished. It's tedious, and it catches real problems often enough that we've never once considered skipping it to save time.

Requesting camera, location, or contacts access without a clear, specific explanation of why the app needs it is a fast way to get flagged, and it's also, separate from review, a fast way to make real users distrust an app enough to delete it. We write specific, honest permission request text for every access point, tied to the actual feature that needs it.

We also make sure a permission request only fires at the moment it's actually needed, not immediately on first launch before a user has any context for why the app wants it. That timing alone changes both review outcomes and real user opt-in rates meaningfully.

Platform rules around in-app purchases versus external payment links are strict, specific, and change more often than most teams realize, and violating them is one of the more common causes of rejection we see in apps involving any kind of payment or subscription. We check the current guidelines fresh before every submission involving payments, rather than relying on what was true the last time we built one.

This is an area where "it worked for a similar app we saw" is a genuinely bad guide, because guidelines get enforced inconsistently across different reviewers and different points in time. We treat the official documentation as the only reliable source, checked immediately before submission rather than assumed from memory.

Screenshots showing features that don't exist yet, a description promising functionality that isn't in the current build, a title stuffed with keywords rather than describing what the app does: all of these get flagged, and all of them are fully within a team's control to get right before submission. We treat store listing accuracy as part of the build itself, not a marketing task handled separately at the end.

We also update screenshots and descriptions every time a significant UI change ships, not just at initial launch, because a mismatch between the store listing and the current build is exactly the kind of thing that erodes both review trust and real user trust over time.

A full manual walkthrough of every core flow on the oldest supported OS version. A content pass for placeholder text or broken images. A permissions audit confirming every request has a specific, honest, well-timed explanation. A guidelines check specifically for any payment or subscription features. A metadata review confirming screenshots and description match the actual current build precisely.

This checklist takes an afternoon, and it has caught something real on the overwhelming majority of submissions we've run it against, even ones the development team was confident were ready. That track record alone is why it's now a mandatory step, not an optional one, on every app we ship.

Read the specific rejection reason carefully rather than resubmitting immediately with a guess at a fix. Reviewers usually cite a specific guideline section, and addressing that exact issue, rather than making unrelated changes and hoping, is by far the fastest path back to approval. We've seen teams waste multiple review cycles by guessing instead of reading closely.

If the reason is genuinely unclear, the app review contact process exists for exactly this, and using it with a specific, polite, factual question gets a real response far more often than teams expect. We've resolved ambiguous rejections this way more than once, faster than a second blind resubmission would have.

None of this is exotic knowledge. It's a checklist, applied consistently, catching problems that are entirely foreseeable if someone actually looks for them before a reviewer does.

The teams that get rejected repeatedly are almost never the ones building genuinely complicated apps. They're the ones submitting without a careful final pass, assuming the build is ready because it worked on the one device someone happened to test it on.

We treat this checklist as a living document, updating it any time a guideline changes or a new rejection reason surfaces on a project, because the platforms themselves keep evolving what they check for, and a checklist that isn't maintained stops being useful fairly quickly.

We also share a version of this checklist with every client before their first submission, not just our own team, because a founder who understands what review actually looks for tends to make better product decisions well before submission day ever arrives.