What is the most common reason apps get rejected?

Incomplete or broken submissions lead the list: a build that crashes on launch, a demo account that does not work, or a feature the reviewer cannot reach. Privacy disclosure problems and payment rule violations are close behind, and all of them are preventable before submitting.

How long does app review usually take?

Both major stores typically review within a day or two, though it varies with volume and with the sensitivity of the app category. The real risk is not a single review cycle but a sequence of them, since each rejection restarts the clock and a few rounds can cost a week or more.

Can I appeal an app store rejection?

Yes. Both Apple and Google provide an appeal or clarification channel. Appeals work best when a reviewer has misunderstood how a feature behaves and you can supply specific steps, a short screen recording and a reference to the guideline you believe applies.

Do I have to use the store's in-app purchase system?

For digital goods and subscriptions consumed inside the app, generally yes, subject to each store's current rules and regional regulations. Physical goods and genuine real-world services are treated differently. Verify the current policy before building any payment flow, because the rules change.

Will adding AI features trigger extra review scrutiny?

Often, yes. Apps that generate content need moderation controls, accurate age ratings and clear disclosure of what data leaves the device. Expect reviewers to test whether your app can be prompted into producing content that violates store policy.

App Store Rejections: Why Apps Get Refused and How to Fix It

A rejection email on launch week is a particular kind of pain. The marketing is scheduled, the investors have been told, and suddenly the release depends on a reviewer in another timezone and a guideline nobody on the team had read. The frustrating part is that most rejections are not judgement calls. They are predictable failures against published rules.

This guide covers the app store rejection reasons that catch teams most often on both iOS and Android, and how to prepare a submission that passes the first time.

Why rejections cost more than they look

A single rejection appears to cost a day. The real cost compounds. Each resubmission goes back into the queue, so three rounds can mean a week of delay. Meanwhile a scheduled campaign either runs against an app that is not live or has to be postponed, which may carry its own costs.

There is a second, quieter cost. Teams rushing to clear a rejection often ship a hasty workaround, and those workarounds become permanent. Preparing properly before the first submission is cheaper than fixing things under deadline pressure.

The rejection reasons teams hit most often

Broken or incomplete submissions

The largest category is also the most avoidable. Reviewers reject builds that crash on launch, show placeholder content, contain features that visibly do not work, or lock them out behind a sign-in they cannot pass. If your app requires an account, you must supply working credentials, and someone must verify those credentials on the exact build you submitted.

Privacy disclosures that do not match behaviour

Both stores require a declaration of what data your app collects and why, and both check it against observed behaviour. Mismatches are common because the declaration is usually written by one person while the data collection comes from third-party SDKs added by another. An analytics or advertising SDK that collects an identifier you did not declare is enough to trigger a rejection.

Your privacy policy must also be reachable from a working public URL and describe the app accurately. A generic policy copied from a template, or one that references a different product, is an easy rejection.

Payment and subscription rule violations

Payment rules are strict and evolving. Digital goods consumed in the app generally must go through the store's purchase system, and steering users to an external payment page is restricted in ways that differ by region. Subscription screens have their own disclosure requirements: price, billing period, renewal terms and a link to the terms must all be visible before purchase.

Because the specifics change, verify the current rules rather than relying on what was true for a previous launch. Our guide to in-app purchases and subscription billing covers the mechanics in more detail.

Permissions requested without justification

Asking for location, contacts, microphone, camera or background activity without a clear in-app reason is a frequent refusal. Each sensitive permission needs a purpose string that explains, in plain language, what the user gets in return. Requesting a permission that no visible feature uses is treated as overreach, and a permission requested at launch before any context is given is worse than one requested at the moment of need.

Minimum functionality and web wrappers

An app that is a thin shell around a website, or that offers little more than a page of links, risks rejection for insufficient functionality. Reviewers look for native value: offline capability, notifications, device integration, or an experience genuinely built for the platform. If your product is essentially a responsive website, consider whether a progressive web app is the better route, a trade-off we examine in PWA versus native apps for startups.

Metadata, screenshots and age ratings

Store listing problems are easy to fix and easy to overlook. Screenshots must show the actual app rather than marketing collages or devices that do not match. Descriptions must not include competitor names or claims you cannot support. Keyword stuffing in the title is a rejection. And the age rating must reflect what the app really contains, including anything user-generated.

User-generated content without moderation

If users can post content that others see, you need a moderation plan: a reporting mechanism, a way to block users, published terms, and evidence that someone acts on reports. This increasingly applies to AI features too, since a generation feature is a content pipeline from a reviewer's perspective.

A real-world example

Consider an illustrative scenario. A fitness startup submits its first iOS build two weeks before a planned launch. It is rejected three times over nine days.

The first rejection is procedural: the demo account provided had expired, so the reviewer could see only the login screen. The second concerns permissions, because the app requests location at launch with a vague purpose string, before the user has seen the route-tracking feature that needs it. The third concerns privacy, because an analytics SDK collects an advertising identifier that was not declared in the data disclosure.

None of these are design flaws. All three were findable with a pre-submission review: verify the demo credentials on the submitted build, move the permission request to the moment the feature is used and rewrite the purpose string, and audit every SDK for what it actually collects. The team now runs a submission checklist before every release, and later rounds pass first time. That checklist sits naturally alongside the automation described in our guide to mobile app release automation with CI/CD.

Step-by-step process for a clean submission

Read the current guidelines. Skim the full list for your category before you build payment, permission or content features, not after.
Audit your SDKs. List every third-party library and what data it collects, then reconcile that against your privacy declaration.
Review permission requests. Each one should fire in context, with a purpose string a non-technical person would find reasonable.
Test on the submitted build. Install the exact archive you are uploading, on a clean device, and complete every core flow.
Verify the demo account. Log in with the credentials you are providing, on that build, and confirm the reviewer can reach every feature.
Check the listing assets. Screenshots from the real app, accurate description, honest age rating, no keyword stuffing.
Publish the legal pages. A live privacy policy and terms URL that describe this app specifically.
Prepare review notes. Explain anything unusual, including how to test features behind specific conditions, and attach a short recording if a flow is hard to find.
Submit with buffer. Allow at least a week before any announced launch date to absorb a rejection cycle.
Respond precisely. If rejected, address the exact guideline cited, state what you changed, and resubmit without bundling unrelated changes.

How to handle a rejection well

Read the message carefully and identify the specific guideline referenced. Reviewers cite rules, and the cited rule tells you what evidence will resolve the issue. Resist the temptation to argue in the first reply if the problem is genuine; fix it and resubmit.

When a reviewer has misunderstood your app, appeal with specifics: the exact steps to reach the feature, a short screen recording, and a clear explanation of why the guideline does not apply as interpreted. Keep the tone factual. The person reading your response has a queue and a policy, and the fastest path through both is clarity.

Never bundle unrelated changes into a resubmission. A build that fixes the cited issue and also introduces a new feature invites a fresh round of scrutiny on something that was not previously in question.

Platform differences worth knowing

The two stores have converged on many rules but still differ in ways that affect planning. Treating them as identical is a reliable way to be surprised late.

Review style. Apple's process involves more human testing of your actual flows, so broken demo accounts and hard-to-find features hurt more there. Google relies more heavily on automated policy checks, which catch declaration mismatches and SDK behaviour.
Staged rollout. Google Play lets you release to a percentage of users, which limits the blast radius of a bad build. Plan your launch to take advantage of it rather than pushing to everyone at once.
Testing tracks. Both offer internal and closed testing, and using them properly means your first production submission is not the first time the build has been installed from a store.
Policy change cadence. Both publish updates with deadlines for existing apps, which means an app that passed review a year ago can fall out of compliance without any code change.

That last point is the one teams forget after launch. Someone should own watching developer policy announcements, because the consequence of missing one is an app removed from sale with little warning.

Build the checklist into your release process

A checklist that lives in someone's memory is not a process. Put it where the work happens: as a template in your issue tracker, as a required step in your release pipeline, or as a short document reviewed in the release meeting. Each item should be verifiable by someone other than the person who wrote the code.

The highest-value items are the cheapest to check. Confirming the demo account works on the submitted build takes two minutes and prevents one of the most common rejections outright. Reconciling SDKs against the privacy declaration takes an hour and prevents another. Neither requires special expertise, only the discipline to do them before upload rather than after refusal.

Key benefits of a pre-submission review habit

Predictable launch dates. Marketing and sales can commit to a date without a hidden dependency on review luck.
Fewer rushed workarounds. Issues found before submission get fixed properly rather than patched under pressure.
Better privacy hygiene. An SDK audit usually surfaces data collection nobody intended, which is worth knowing regardless of review.
Stronger user trust. Contextual permission requests and honest listings improve conversion as well as passing review.
A reusable checklist. Every release after the first costs less, because the work is already encoded in the process.

App review is not an adversary. It is a published set of rules applied by someone with limited time, which means your job is to make compliance obvious at a glance.

Conclusion

Store rejections feel arbitrary from the inside and are usually anything but. The frequent causes cluster into a small set: broken submissions, undeclared data collection, payment rule violations, unjustified permissions, thin functionality and inaccurate listings. Each one can be checked before you upload a build.

Build the checklist once, run it before every release, and keep a week of buffer before any date you announce publicly. If you want a team that handles submission and compliance as part of delivery, explore our mobile app development services or see examples of shipped work in our case studies.

Frequently Asked Questions

What is the most common reason apps get rejected?: Incomplete or broken submissions lead the list: a build that crashes on launch, a demo account that does not work, or a feature the reviewer cannot reach. Privacy disclosure problems and payment rule violations are close behind, and all of them are preventable before submitting.
How long does app review usually take?: Both major stores typically review within a day or two, though it varies with volume and with the sensitivity of the app category. The real risk is not a single review cycle but a sequence of them, since each rejection restarts the clock and a few rounds can cost a week or more.
Can I appeal an app store rejection?: Yes. Both Apple and Google provide an appeal or clarification channel. Appeals work best when a reviewer has misunderstood how a feature behaves and you can supply specific steps, a short screen recording and a reference to the guideline you believe applies.
Do I have to use the store's in-app purchase system?: For digital goods and subscriptions consumed inside the app, generally yes, subject to each store's current rules and regional regulations. Physical goods and genuine real-world services are treated differently. Verify the current policy before building any payment flow, because the rules change.
Will adding AI features trigger extra review scrutiny?: Often, yes. Apps that generate content need moderation controls, accurate age ratings and clear disclosure of what data leaves the device. Expect reviewers to test whether your app can be prompted into producing content that violates store policy.