Why did my app get rejected from the App Store?
The four reasons behind most App Store and Google Play rejections: broken or incomplete functionality (Apple's Guideline 2.1), missing or inaccurate privacy disclosures (Guideline 5.1.1), misleading metadata (Guideline 4.3), and over-broad permission requests. First submissions get rejected more often than resubmissions because the four causes above are easy to miss once and hard to miss twice. Each rejection costs a resubmission cycle, and Apple's own review queue alone can run 24 hours to two weeks depending on the flag. Fix the four causes before you submit and most of that delay disappears.
A rejected build is not a technical failure. It is a missed line item in the submission checklist, surfacing three days before demo day instead of three weeks before it.
What actually gets an app rejected?
Four categories cover most of it, on both stores.
Broken or incomplete functionality. Apple's Guideline 2.1 exists to catch crashes on launch, dead buttons, and placeholder screens that shipped by accident. Google's equivalent flags ANRs (app-not-responding errors) and broken core flows the same way. Reviewers test on real devices, not simulators — a feature that works on your M-series laptop and fails on a three-year-old Android phone is a rejection, not an edge case.
Missing or inaccurate privacy disclosures. Apple's Guideline 5.1.1 and Google's Data Safety section both ask the same question in different words: what does this app actually collect, and does the on-screen disclosure match the code. An analytics SDK that reports device identifiers while the privacy label says "we collect nothing" is one of the fastest-growing rejection categories on Google Play, and it is entirely avoidable — the mismatch is caught by reading your own SDK list against your own form.
Misleading metadata. Screenshots that show a feature not in the build, a description that promises functionality still on the roadmap, a title stuffed with unrelated keywords — Apple's Guideline 4.3 catches this at the marketing layer, not the code layer. It is the rejection reason with the least engineering fix and the most product-copy discipline required.
Over-broad permissions. Requesting camera, contacts, and location access on first launch for an app that uses none of them at startup reads as a red flag to both review teams — not because the permission is disallowed, but because the request has no visible justification in that screen.
How long does app store review actually take?
Apple's own queue runs roughly 24 to 48 hours for a clean submission. The delay is never the queue — it is the resubmission cycle a rejection forces. Google's first-submission review for new developer accounts commonly runs 7 to 14 days, per Google Play's own published Console review-time guidance; a rejected resubmission restarts that clock. A single Guideline 2.1 rejection on Apple, caught and fixed in one day, still costs another 24-to-48-hour queue pass — and developer forums are full of first-time submitters reporting three-plus weeks stuck in "waiting for review" with no explanation, because the flag landed on a borderline case instead of a clean one.
That is the real cost: not the review itself, but the demo-day date that moved because nobody ran the submission past the four categories above before hitting submit.
The pre-submission checklist
| Check | Catches | Typical delay avoided |
|---|---|---|
| Fresh install on a three-year-old device, not just a simulator | Guideline 2.1 crashes | 1 review cycle (1-14 days) |
| SDK list cross-checked against the privacy form | Guideline 5.1.1 / Data Safety mismatch | 1 review cycle |
| Screenshots match the shipped build exactly | Guideline 4.3 metadata | 1 review cycle |
| Every runtime permission has an on-screen reason before the prompt fires | Permission rejection | 1 review cycle |
| TestFlight or internal-testing track run 48 hours before submission | Any of the above, caught pre-review | The entire cycle |
What do we do differently?
We run every build through a private TestFlight or internal-testing track at least 48 hours before the public submission — on a physical low-end device, not a simulator. We treat the privacy form as code review, not marketing copy: whoever wrote the SDK integration signs off on the Data Safety form line by line. We do not set the demo date against the submission date. We set it a review cycle later, because a clean submission is the exception you plan for, not the rule you assume.
The founders who get burned by review delays are not unlucky. They submitted the build they had, not the build they checked.
Frequently asked questions
How long does Apple App Store review take in 2026? Roughly 24 to 48 hours for a clean first submission. The number that matters more is the resubmission cost — a rejection restarts the queue, so a borderline build can cost a week or more even though the queue itself moves fast.
What is the single most common reason apps get rejected? Broken or incomplete functionality under Apple's Guideline 2.1 — crashes, dead buttons, or a feature that works on the developer's device but fails on a real, older phone the reviewer actually tested on.
Can Google Play reject an app after it is already live? Yes. Policy enforcement runs continuously, not just at submission — a permission change, an SDK update, or a new Data Safety mismatch can trigger a takedown of a previously approved app. The checklist above is worth re-running on every release, not just the first one.
If the review delay is landing inside a launch window you already scoped tight, the fix usually isn't the submission — it's the timeline you built the launch around.
Written 2026-10-01 by Naman Barkiya.