Why Apps Get Rejected by App Store and Google Play Review
Every new app and every update goes through review before it reaches users, and a rejection can push a launch back by days. Apple publishes the issues it sees most often, and both stores document their rules: crashes and unfinished features, missing reviewer access, privacy gaps, misleading listings, payment rules and apps that offer too little. This guide covers them, and what to do when a rejection arrives. It draws on Apple's App Review pages and App Review Guidelines, and Google's Play Console Help, checked on 4 November 2026.
How review works on each store
Apple's App Review page says Apple reviews "all apps, app updates, app bundles, in-app purchases, and in-app events" against the App Review Guidelines. It adds that App Review typically reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours", and that incomplete submissions may be delayed or not pass.
Google's enforcement process page says Google uses "a combination of human and automated evaluation", looking at app metadata such as the title and description, the in-app experience, account history and "any third-party code in apps". You are responsible for making sure SDKs in your app comply with Google Play's Developer Program Policies. Our guide to publishing an app to the App Store and Google Play covers the accounts and the first submission; this guide is about getting through review.
Crashes, placeholders and missing information
Apple says that "on average, over 40% of unresolved issues are related to guideline 2.1: App Completeness", which "covers crashes, placeholder content, incomplete information, and more". Its list of common issues includes:
- Crashes and bugs: submit only when the app is complete, tested "on devices running the latest software".
- Broken links: all links must work, and every app needs a support link "with up-to-date contact information" and a link to the privacy policy.
- Placeholder content: unfinished images or text "cannot be approved".
- Incomplete information: the App Review Information section must contain what reviewers need.
The cure is a proper test round before submission, on real devices and current OS versions; see our guide to testing a mobile app before release.
Giving reviewers access
Reviewers cannot approve what they cannot reach. Apple says: "If some features require signing in, provide a valid demo account username and password". If features need special hardware or an environment that is hard to replicate, "be prepared to provide a demo video or the hardware". Without this information "the app review process may be delayed and your app may not pass review".
Google's Prepare your app for review page says that if all or part of an app is restricted by login, membership, location or other authentication, "you must provide all required details to enable access to your app" under Sign-in details on the App content page. It asks you to mention one-time passwords or multi-factor sign-in in the extra instructions. In practice, set up a dedicated review account with sample data that does not expire.
Privacy policy, permissions and accounts
- Privacy policy. Apple's common issues say the policy must identify the data the app collects and how it is used, confirm third parties give equal protection, and explain retention and deletion and how users can request deletion. Google requires a privacy policy link "on your store listing and within your app", on an active public URL, not a PDF, and specific to your app.
- Permission prompts. Apple requires a purpose string explaining "clearly and completely why your app needs the data" for every sensitive API the app uses.
- Sign-in and deletion. Apple's guideline 5.1.1(v) says: "If your app doesn't include significant account-based features, let people use it without a login", and "If your app supports account creation, you must also offer account deletion within the app".
- Declarations. On Google Play, the App content page also covers ads, target audience, content ratings, sensitive permissions and Data safety. Our guide to privacy labels and Data safety covers the forms, and our guide to age ratings and apps for children covers ratings and the Families rules.
Accurate listings
Apple's guideline 2.3 says your metadata, "including privacy information, your app description, screenshots, and previews", must accurately reflect the app's core experience. New features in an update must be described "with specificity" in the review notes, and "generic descriptions will be rejected". Screenshots should show the app in use, and the app "must perform as advertised". Our guide to app store listings covers writing a listing that is both accurate and findable.
Payments
Guideline 3.1.1 says that to unlock features or functionality in the app, such as subscriptions or premium content, "you must use in-app purchase", and apps may not use their own unlock mechanisms such as license keys or QR codes. The other side matters too: under guideline 3.1.3(e), physical goods or services consumed outside the app must use other purchase methods, such as Apple Pay or card entry. The rules on links to other payment methods differ by storefront, and Google Play has its own. Our guide to in-app purchases and subscriptions sets them out; decide the payment model before the build, because changing it late can mean rebuilding screens.
Apps that are just a website
Guideline 4.2, Minimum Functionality, says an app should "elevate it beyond a repackaged website", and that apps that are not "particularly useful, unique, or 'app-like'" do not belong on the App Store. Apple's common issues add that "websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app", and warn against submitting several near-identical apps (guideline 4.3) and copycat apps (4.1). If your plan is to wrap your website in an app, read our guide on mobile app or web app first.
Submitted by the wrong account
Apple says certain apps "must be submitted by the legal entity that provides the services rather than an individual developer", including apps in banking and financial services, cryptocurrency, healthcare, gambling and air travel, and apps that require sensitive user information. Some app types also need documents, such as regulatory clearance for apps that work with medical hardware, or authorization for third-party content. Publish under your own organisation's developer account from the start.
When a rejection arrives
On the App Store, App Store Connect shows the details, "including any specific App Review Guidelines that your submission didn't follow", and you can reply to App Review there before resubmitting. If you believe Apple misunderstood the app or treated you unfairly, you can appeal to the App Review Board, giving specific reasons, with one appeal per rejected submission. For apps already on the store, the guidelines say bug fixes "will not be delayed over guideline violations except for those related to legal or safety issues"; you can ask to use this and fix the issue in the next submission. Apple also offers expedited review requests for critical bug fixes and event-related releases.
On Google Play, the Policy status page in Play Console shows any rejection, removal or suspension and lets you appeal. Google's page on removed apps explains the difference:
- Rejection: does not affect your developer account's standing; for an update, the previous version stays available.
- Removal: the app is unavailable until a compliant update is submitted; multiple removals may lead to suspension.
- Suspension: counts as a strike against the account, and "repeated app rejections or removals" can cause one.
Google's advice in both places is the same: do not resubmit until the policy violation is fixed. Read the whole message, fix every point it names, check the rest of the app for the same issue, and explain the fix in the review notes.
Frequently asked questions
What is the most common reason for an App Store rejection?
Apple says that on average over 40% of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content, incomplete information and more.
Does a Google Play rejection hurt our developer account?
A rejection does not affect the standing of your account, and if it was an update, the previous version stays available. Removals can lead to suspension if repeated, and suspensions count as strikes against the account.
Can we appeal a rejection?
Yes. Apple lets you appeal to the App Review Board with specific reasons, one appeal per rejected submission. On Google Play you can appeal from the Policy status page in Play Console.
Can we wrap our website in an app?
Apple's guideline 4.2 says an app should be more than a repackaged website, and its common issues list says websites served in an iOS app and limited web interactions do not make a quality app. Plan app features that use the device, or consider a progressive web app instead.
Reviews usually take a short time but can take longer, and a rejection means a fix and a resubmission, so we plan launch dates with room for it. See our mobile app development service and all our services, or email [email protected].