Why Apps Get Removed From App Stores: Top Reasons and How to Avoid It
Getting pulled from the App Store or Google Play can stop your downloads overnight. This guide covers why apps get removed or rejected, the exact policy triggers, how to avoid them, and what to do if it happens.
An app removal can stop your downloads overnight, and it usually comes down to a policy you did not realise you were breaking. Apps get removed either at review, before they ever go live (a rejection), or after launch (a takedown), and the same handful of causes, policy violations, privacy and data issues, crashes, misleading metadata and payment rule-breaking, account for almost all of them. This guide explains why apps get removed from the App Store and Google Play, the exact guideline categories each store enforces, the fastest-growing triggers around privacy and metadata, how to avoid a rejection, and what to do if your app is pulled. Building an app you want to keep live? Get started free with Appy Pie AI.
What This Guide Covers
- Removed vs rejected vs suspended
- The top removal & rejection reasons
- Apple’s 5 guideline pillars
- Google Play’s policy triggers
- Privacy, metadata & quality
- How to avoid it & how to recover
Build store-compliant apps with no code. Rated 4.7/5 on G2 from 1,388 reviews.
Get Started FreeTL;DR Quick Summary
Apps get removed from the App Store and Google Play for breaking store policy, either rejected at review before launch, or taken down after. The biggest causes are policy and content violations, inaccurate privacy disclosures or a missing privacy manifest, crashes and thin functionality, misleading metadata and screenshots, and bypassing the store’s payment system. Apple cites a guideline number (2.1, 2.3, 3.1.1, 4.3, 5.1.1); Google names a Developer Program Policy and scans live apps automatically. Avoid removal by testing on real devices, disclosing data accurately, keeping metadata honest, using store payments and staying updated. If it happens, read the exact reason, fix the root cause, and resubmit or appeal, never try to evade, which risks your whole account.
Build a Compliant App →Table of Contents
Jump to any section: what it means when an app is removed, rejection vs removal vs suspension, the top removal reasons, Apple’s five guideline pillars, Google Play’s policies, privacy and data, metadata and store listing, crashes and functionality, how to avoid removal, what to do if your app is removed, how no-code lowers the risk, and the mistakes to avoid, plus an FAQ.
- What It Means When an App Is Removed From a Store
- Rejection vs Removal vs Account Suspension
- The Top Reasons Apps Get Removed or Rejected
- Apple App Store: The Five Guideline Pillars
- Google Play: The Policies That Get Apps Pulled
- Privacy and Data: The Fastest-Growing Removal Reason
- Metadata and Store Listing Violations
- Crashes, Bugs and Minimum Functionality
- How to Avoid Getting Removed or Rejected
- What to Do If Your App Is Removed
- How No-Code Platforms Reduce Removal Risk (and What They Do Not)
- Common Mistakes That Get Apps Pulled
- Frequently Asked Questions
What It Means When an App Is Removed From a Store
An app is “removed” when it disappears from the App Store or Google Play so new users can no longer find or download it. It can happen at two moments: at review, before the app ever goes live (a rejection), or after it has been published (a takedown). Either way the effect is the same, your store traffic and new installs stop.
Removal is almost always a policy decision. Apple and Google both publish detailed rules, the App Store Review Guidelines and the Google Play Developer Program Policies, and every app is checked against them both at submission and, increasingly, by automated scanning after launch. When an app crosses a line, whether that is a privacy disclosure that does not match its behaviour, a payment that bypasses the store, or content that breaks a policy, it gets pulled.
One important detail: a removed app usually stays installed on the phones of people who already downloaded it, but nobody new can get it and you cannot ship updates until it is reinstated. This guide breaks down exactly why apps get removed, the specific policy triggers on each store, how to avoid them, and what to do if it happens to you. Building an app you want to keep compliant from day one? Get started free with Appy Pie AI.
Rejection vs Removal vs Account Suspension
These three outcomes get used interchangeably, but they are different in severity and in what you can do about them. Knowing which one you are facing tells you how worried to be.
Rejection (at review, before launch)
Your submission did not pass review, so the app never went live. This is the most common and the least serious outcome: you get a reason from the reviewer, fix it, and resubmit. Most first submissions get rejected at least once, and it is a normal part of publishing.
Removal or takedown (after launch)
A live app is pulled from the store, either for a policy violation flagged by a scan or report, a legal or IP complaint, or because it went stale under an app-improvement sweep. You usually get a notice, a window to fix the issue, and a path to resubmit.
Account suspension or termination (the serious one)
Repeated or severe violations, fraud, malware, or repeatedly re-uploading a banned app can get your entire developer account terminated, taking every app with it. This is hard to reverse, which is why treating early rejections seriously matters.
The Top Reasons Apps Get Removed or Rejected
Across both stores, the same handful of categories account for the overwhelming majority of rejections and takedowns. If your app is going to have a problem, it is almost certainly one of these.
- Policy and content violations, the app or its content breaks a store rule (restricted content, illegal activity, IP infringement, impersonation).
- Privacy and data issues, missing or inaccurate privacy disclosures, unjustified permissions, or a privacy manifest that does not match behaviour.
- Crashes, bugs and minimum functionality, the app crashes, has broken flows, placeholder content, or is too thin to be useful.
- Misleading metadata, screenshots, description or keywords that do not reflect what the app actually does.
- Payment and monetization violations, bypassing the store’s in-app purchase system for digital goods, or deceptive ads and subscriptions.
- Security and malware, malicious code, unwanted behaviour, or using private or non-public APIs.
The rest of this guide takes each store in turn and then the biggest cross-store triggers, privacy, metadata and quality, in detail.
Apple App Store: The Five Guideline Pillars
Apple organises its entire App Store Review Guidelines into five sections. Almost every rejection maps to one of them, and the reviewer usually cites the exact guideline number.
| Pillar | What it covers | Common trigger |
|---|---|---|
| 1. Safety | Objectionable or harmful content, user-generated content moderation, physical harm | No way to report or filter offensive user content |
| 2. Performance | Completeness, no crashes or bugs, accurate metadata, no placeholder content | 2.1 crashes on launch; 2.3 misleading screenshots |
| 3. Business | Payments and in-app purchase, subscriptions, acceptable business models | 3.1.1 selling digital goods outside Apple’s IAP |
| 4. Design | Minimum functionality, no spam or duplicates, native experience | 4.2 too thin; 4.3 spam or duplicate app |
| 5. Legal | Privacy, data collection, legal compliance, permissions | 5.1.1 collecting data without consent or a policy |
The most-cited rejections are 2.1 (the app crashed or was incomplete during review), 2.3 (metadata does not match the app), 3.1.1 (payments), 4.3 (spam or duplicate) and 5.1.1 (privacy). Fix the cited number, respond in Resolution Center, and resubmit.
Google Play: The Policies That Get Apps Pulled
Google Play groups its rules into the Developer Program Policies. Play also relies heavily on automated scanning after launch, so takedowns of live apps are more common here than on the App Store.
| Policy area | What it covers | Common trigger |
|---|---|---|
| Restricted content | Illegal, sexual, hateful, violent content, gambling, unapproved financial services | Content that breaks a restricted-content rule |
| Privacy, deception & device abuse | Data safety, permissions, deceptive behaviour, background data use | Data safety form does not match actual data use |
| Monetization & ads | Play Billing for digital goods, ad behaviour, disruptive ads | Full-screen or deceptive ads, or bypassing Play Billing |
| Store listing & IP | Metadata, ratings, impersonation, copyright and trademark | Keyword stuffing or using another brand’s assets |
| Spam & minimum functionality | Repetitive or low-value apps, broken or non-functional apps | Thin, duplicate, or broken app |
| Malware & mobile unwanted software | Malicious code, unwanted behaviour, security holes | Flagged SDK or malicious code in the build |
Play also removes apps that stay abandoned and out of date under its target-API-level requirement, so an app you never update can quietly vanish from search even without a policy strike.
Privacy and Data: The Fastest-Growing Removal Reason
Since 2024, privacy is the category that catches the most developers off guard, because the rules got stricter and much of it is now checked automatically. If your disclosures do not match what your code and SDKs actually do, expect a rejection.
Inaccurate privacy disclosures
Apple’s privacy “nutrition labels” and Google’s Data safety form must accurately describe every type of data you and your third-party SDKs collect. A mismatch between what you declare and what the app does is a fast rejection on both stores.
Missing or invalid privacy manifest
Apple now requires a privacy manifest and, for many popular SDKs, a signature. A flagged API used without a valid manifest gets your upload rejected. See our full guide to the Apple privacy manifest.
Unjustified or excessive permissions
Requesting a permission you do not clearly need, or asking for it before you show why, is a common flag. Request only what you use, and ask at the moment it makes sense.
Metadata and Store Listing Violations
Your store listing is part of what gets reviewed, not just your build. Reviewers reject apps whose metadata oversells or misrepresents the product, and both stores treat listing manipulation as a policy issue.
Misleading screenshots or description
Screenshots that show features the app does not have, or a description promising more than it delivers, is Apple guideline 2.3 and a Play store-listing violation. Show the real app.
Keyword stuffing
Cramming unrelated keywords, competitor names or repeated terms into the title, subtitle or description is treated as spam. Write for humans and use the dedicated keyword field. Our app store optimization guide covers doing this the safe way.
Wrong category, rating or incomplete info
An inaccurate age rating, the wrong category, or placeholder text and broken links in the listing all cause rejections. Complete every field honestly before you submit.
Crashes, Bugs and Minimum Functionality
The single most common rejection reason is simple: the app did not work well enough during review. Reviewers open the app on real devices, and if it fails, it does not ship.
Crashes and broken flows
A crash on launch, a sign-up that fails, or a core feature that does not work is an instant rejection (Apple 2.1). Test every flow on real devices and reach review with a high crash-free rate.
Placeholder or incomplete content
Lorem ipsum text, empty screens, broken links or “coming soon” features signal an unfinished app. Everything the reviewer can reach must be real and working.
Too little functionality
An app that is just a repackaged website, a single static screen, or offers almost nothing beyond a bookmark gets rejected for minimum functionality (Apple 4.2, Play spam). Give users a genuine reason to install.
How to Avoid Getting Removed or Rejected
Most rejections are preventable with a pre-submission pass. Run this checklist before you ever hit submit, and you will avoid the large majority of problems.
- Read the guidelines for both stores and check your app against each relevant section.
- Test on real devices until crashes and broken flows are gone.
- Match your privacy disclosures to reality, including every third-party SDK, and ship a valid privacy manifest.
- Request only the permissions you use, and justify each one in context.
- Make metadata honest, real screenshots, an accurate description, no keyword stuffing.
- Use the store’s payment system for digital goods, and follow the ad and subscription rules.
- Keep the app updated to meet current target-API and OS requirements so it is not swept for being stale.
Submit one to two weeks before any hard launch date so a rejection does not blow your timeline.
What to Do If Your App Is Removed
A rejection or takedown notice is not the end. Both stores give you a clear path back, if you respond calmly and fix the actual issue.
Read the exact reason
Apple cites a guideline number in Resolution Center; Google names the policy in the Play Console. Do not guess, the notice tells you precisely what to fix.
Fix the root cause, then resubmit
Address the specific violation, not a surface symptom. Reuploading the same build without a real fix leads to repeat rejections and, eventually, harsher action.
Appeal if you believe it is wrong
Both stores let you appeal. If you think the reviewer misunderstood, reply in Resolution Center or file a Play appeal with a clear, factual explanation and evidence. Be professional, appeals are read by people.
Do not try to evade
Re-publishing a removed app under a new name or account to dodge a ban is the fastest way to get your whole account terminated. Fix and reinstate the legitimate way.
How No-Code Platforms Reduce Removal Risk (and What They Do Not)
A managed no-code platform removes a whole class of technical rejection reasons for you, but it cannot make policy-breaking content compliant. Being honest about both halves is important.
What a no-code platform handles
Platforms like Appy Pie AI generate builds that are already signed correctly, ship a valid privacy manifest, keep SDKs current, target the required API levels, and produce stable native apps, which removes the most common technical rejections (crashes, signing, manifests, stale APIs) before you ever submit.
What is still on you
No platform can approve your content. If your app itself breaks a policy, restricted or infringing content, misleading metadata, selling digital goods outside the store’s payment system, or a privacy disclosure you filled in inaccurately, it will still be rejected or removed. The builder handles the plumbing; you are responsible for what the app does and claims.
So no-code meaningfully lowers your risk and your review friction, but you still have to follow the rules. Build compliant from the start with Appy Pie AI app builder.
Common Mistakes That Get Apps Pulled
Almost every removal traces back to a short list of avoidable mistakes. Steer clear of these and you are ahead of most submissions.
The pattern repeats: developers submit an app that crashes or is half-finished, declare privacy data that does not match what their SDKs actually collect, oversell with screenshots of features that do not exist, try to take payments for digital goods outside the store, ignore the guidelines until a rejection forces them to read them, and then, worst of all, try to dodge a takedown by re-uploading under a new name. Do the opposite, ship something stable and complete, disclose accurately, describe honestly, use the store’s payment rails, and fix issues the legitimate way, and removal becomes a rare, recoverable event rather than a launch-ending one.
Do this
- Ship a stable, complete app tested on real devices
- Match privacy disclosures to what your SDKs actually do
- Use real screenshots and an honest description
- Use the store’s payment system for digital goods
- Read both stores’ guidelines before submitting
- Fix and resubmit through the official process
Avoid this
- Submitting an app that crashes or is half-finished
- Declaring privacy data that does not match reality
- Overselling with screenshots of features that do not exist
- Taking payments for digital goods outside the store
- Ignoring the guidelines until a rejection forces it
- Re-uploading a removed app under a new name to evade a ban
Build Store-Compliant Apps With No Code
Skip the most common technical rejections. Build on a managed no-code platform that ships correctly signed builds, a valid privacy manifest and current SDKs, so crashes, signing and manifest issues are handled before you ever submit.
Get Started Free Read: The App Launch ChecklistFrequently Asked Questions
Why do apps get removed from the App Store and Google Play?
Apps get removed for breaking a store policy, either at review (a rejection, before the app is live) or after launch (a takedown). The most common reasons are policy and content violations, inaccurate privacy disclosures or a missing privacy manifest, crashes and broken functionality, misleading metadata or screenshots, bypassing the store’s in-app payment system, intellectual-property complaints, and security or malware issues. Google Play also removes apps that go stale and no longer meet its target-API-level requirement.
What is the difference between app rejection and app removal?
Rejection happens at review, before your app is ever published, your submission did not pass, so you get a reason, fix it and resubmit. Removal (or takedown) happens to an app that was already live: it is pulled from the store for a policy violation, a legal or IP complaint, or for going out of date. Removal is more serious than a rejection, and repeated or severe violations can escalate to suspension or termination of your entire developer account.
Why was my app rejected from the App Store?
Apple cites the exact App Store Review Guideline number in Resolution Center. The most common are 2.1 (the app crashed or was incomplete during review), 2.3 (metadata or screenshots do not match the app), 3.1.1 (selling digital goods outside Apple’s in-app purchase), 4.2 or 4.3 (too little functionality, or spam and duplicate apps), and 5.1.1 (privacy, collecting data without proper consent or disclosure). Read the cited number, fix that specific issue, reply in Resolution Center, and resubmit.
Why was my app removed from Google Play?
Google Play removes live apps for Developer Program Policy violations, often flagged by automated scanning. Common causes are a Data safety form that does not match your app’s actual data collection, restricted or infringing content, deceptive or disruptive ads, bypassing Play Billing for digital goods, keyword stuffing or misleading store listings, and malware or unwanted-software flags in your build or SDKs. Play also removes apps that no longer meet the current target-API-level requirement, so an app you have stopped updating can be pulled from search.
How do I avoid getting my app rejected or removed?
Read both stores’ guidelines and check your app against them, test on real devices until it is crash-free, make your privacy disclosures match reality (including third-party SDKs) and ship a valid privacy manifest, request only the permissions you use, keep metadata and screenshots honest with no keyword stuffing, use the store’s payment system for digital goods, and keep the app updated to current API and OS requirements. Submit one to two weeks early so a rejection does not blow your launch date.
Can I appeal if my app is removed or rejected?
Yes. On the App Store you can reply in Resolution Center or formally appeal a guideline decision if you believe the reviewer misunderstood your app. On Google Play you can submit an appeal from the Play Console. In both cases, be professional and factual: explain clearly what the app does, why you believe it complies, and include evidence. Appeals are read by people, so a calm, specific explanation is far more effective than resubmitting the same build unchanged.
Can my developer account be terminated?
Yes, and this is the most serious outcome. Repeated policy violations, fraud, malware, or trying to evade a removal by re-uploading a banned app under a new name or account can get your entire Apple or Google developer account terminated, taking every app you publish with it. Account termination is hard to reverse, which is why you should take even early rejections seriously and always fix and resubmit through the legitimate process rather than trying to dodge enforcement.
How long does app store review take?
Apple App Store review typically takes from under a day to a couple of days, and most submissions are reviewed within 24 to 48 hours. Google Play review can range from a few hours to several days, and new developer accounts or sensitive categories can take longer. Because a rejection resets the clock, submit at least one to two weeks before any hard launch date so you have time to fix an issue and resubmit without missing your window.
If an app is removed from the store, is it deleted from my phone?
Usually not. When an app is removed from the App Store or Google Play, it generally stays installed on the phones of people who already downloaded it, but new users can no longer find or install it, and you cannot ship updates until it is reinstated. In rare, severe cases (malware or a security threat) the stores can remotely disable or flag an installed app, but a routine policy removal only stops new downloads and updates.
Do apps built with no-code platforms get removed from app stores?
They are subject to exactly the same policies as any other app. A good no-code platform like Appy Pie AI removes the common technical reasons for rejection, it produces correctly signed native builds, ships a valid privacy manifest, keeps SDKs and target-API levels current, and generates stable apps, so crashes, signing and manifest issues are handled for you. What it cannot do is make policy-breaking content compliant: if your app’s content, metadata or monetization breaks a store rule, it will still be rejected or removed, because that part is your responsibility, not the builder’s.
Publish Once, Stay Live
Removal is avoidable and, when it happens, recoverable, if you know the rules, ship something stable and honest, and fix issues the legitimate way. Work through the checklist above before every submission and treat a rejection as a normal, fixable step, not a disaster. Build store-compliant apps from the start on Appy Pie AI, where signing, the privacy manifest and current SDKs are handled for you.
Start Building Free →Build a Store-Compliant App With Appy Pie AI
No code, no dev team. Build stable, correctly signed native apps with a valid privacy manifest and current SDKs, and publish to the App Store and Google Play with the common technical rejections already handled.
Get Started Free4.7/5 on G2 with 1,388 reviews | 10M+ apps & sites built since 2016
Aasif Khan
Head of SEO and Growth Marketing Lead at Appy Pie AI with 17+ years in digital marketing, AI-powered optimization, and scalable growth strategies.
Abhinav Girdhar
Founder and CEO of Appy Pie AI. Builder of one of the world’s largest no-code and AI platforms, with 10M+ apps and websites created.