App Store Rejections
App Store Rejection Reasons: A 2026 Index of 80+ Real Rejections
Every App Store and Google Play rejection reason that actually gets apps rejected in 2026 — with fixes, cited guidelines, and a pre-flight checklist.
This is an operating reference for indie developers, not a listicle. When Apple or Google rejects your app, the reviewer mails you a short letter and a guideline number. You then have to translate that letter into the specific thing you did wrong — and into the specific edit that will get you through next time. That translation is what this page is for.
The App Store rejects roughly a third of first submissions each year. Google Play rejects or suspends fewer apps on the first pass but does so after launch far more often, through policy-violation notices that can pull a live app down overnight. Either way, the cost of a rejection is not the rejection itself — it is the week of re-submission cycles, the fixed launch date you slipped, and the retention curve that flattens while you wait.
The 80+ App Store rejection reasons below are the ones that actually show up in the wild in 2026. Each includes what the rejection letter looks like, why reviewers flag it, how to fix it, and the specific App Review Guideline or Google Play policy you can cite when you reply. A subset are caught by Push My App’s Pre-Flight Scanner before your binary ever leaves your laptop; the rest come down to decisions you make about your listing, your content, and your business model.
Use the table of contents to jump to the category that matches your rejection letter. Use Ctrl-F to find the exact phrase from the letter. And if you are reading this before submitting — which is where this page earns its keep — pair it with the free ASO pre-submission checklist and do the full walkthrough.
How review actually works in 2026
Reviewers on both sides are humans (Apple) and a mix of humans and automated checks (Google). They don’t run your app for long. They don’t read your FAQ. They tap through the first screen, try one core flow, scan your metadata, and make a call. If the call is reject, you get a letter. The letter cites one or more guideline numbers and — usually — includes a screenshot or a log line that shows the problem.
Apple’s review flow. Submissions go into an automated static-analysis pass, then a human reviewer picks them up from a global queue. First-submission review times published by Apple have hovered at roughly 24 hours for most appsfor several years — sometimes under an hour for an update, sometimes two to three days during peak launch windows. Rejection letters arrive in App Store Connect’s Resolution Center; every letter you have ever received on a given app thread is preserved there.
Google Play’s review flow. Google runs a pre-launch report (automated device testing, crashes and ANRs, policy issues), a static policy scan, and then a human policy review where flagged. New apps often clear in 3 to 7 days; updates are usually much faster. Unlike Apple, Google can also take your app down after it is already live if post-launch scanning flags a policy violation, or if a user report escalates. You get an email with the specific policy reference and a 7-day appeal window.
Why the same app can pass one and fail the other. Apple enforces design quality, business-model rules, and metadata accuracy aggressively. Google is stricter about data-safety declarations, permissions, security posture (exposed secrets, SQL injection), and long-tail policy items like Deceptive Behavior and Impersonation. Apple will reject a sparse-content app for Spam (4.3); Google will accept the same app but reject yours if the Play Console Data safety form does not match what your code actually collects. Your submission strategy: treat them as two review boards with overlapping but non-identical rubrics. Never assume “it passed one, it will pass the other.”
How to use this 80+ index
The list below is grouped into eight categories:
- Metadata and listing — what reviewers see before they launch the app.
- Binary and platform — what they catch when the binary runs.
- Functionality and user-facing — what happens when a reviewer actually uses it.
- Privacy, data, and tracking — what the App Privacy label or Data safety form does not match.
- Design and content — objectionable, misleading, or low-quality experience.
- Business-model and payments — IAP, subscriptions, external purchase.
- Android-only and iOS-only special cases — platform-specific edge cases.
- Pre-flight workflow and appeal — how to avoid the letter, and what to do when you get one.
Each row tells you what the rejection letter says, why reviewers flag it, how to fix it, and the rule it cites. The cited rule is usually an App Review Guideline number (e.g. 2.1) or a Google Play policy section name. Apple’s full guidelines live at developer.apple.com/app-store/review/guidelines; Google’s are in the Play Developer Policy Center.
Metadata and listing rejections
Metadata rejections are the cheapest to catch and the easiest to trigger. A reviewer reads your title, subtitle, keywords, and description before launching the app at all. Anything that feels padded, misleading, or broken here triggers a reject before your binary is touched. The free keyword character counter and subtitle helper were built for exactly these items.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| App name is generic or category-descriptive (“Todo”, “Calculator Pro”) | Apple treats overly generic names as attempts to rank on search terms alone. | Use a brand name plus a short descriptor. Keep the brand at the front. | Apple 4.1 |
| Keyword spam in description or name | Listing is stuffed with trademarked terms, competitor names, or repeated keywords. | Remove competitor names and trademarks you do not own. Keywords belong in the keywords field, not the description. | Apple 5.2 / Google Metadata |
| Subtitle describes a feature the app does not have | Reviewer reads the subtitle, launches the app, cannot find the feature within a minute. | Write the subtitle against the actual first-run experience, not the roadmap. | Apple 2.3.7 |
| Promotional text contains a price or time-limited discount | Promo text is supposed to describe the app, not run marketing campaigns. | Move pricing to screenshots or in-app. Keep promotional text evergreen. | Apple 2.3.1 |
| Screenshots show a different app, device frame, or OS | Screenshots use outdated device bezels or a different product’s UI. | Render fresh screenshots at the current required sizes. The screenshot size reference lists every sign-off dimension for 2026. | Apple 2.3.3 |
| Support URL returns 404 or a parked domain | Apple hits every URL in your listing. One 404 is a reject. | Point Support URL at a real page with a contact form or an email address above the fold. | Apple 1.5 |
| Placeholder text in description (“Lorem ipsum”, “Your description here”) | Copy was never finalized before submission. | Run a grep for placeholder strings in every localized description field. | Apple 2.3.8 |
| Copyright claims for content you do not own | Description or icon references Disney, Marvel, a sports league, a music artist, or a trademarked phrase without licence. | Strip every third-party IP reference. If you have a licence, have it ready for reply. | Apple 5.2 / Google IP |
| Localized description is a direct machine translation of English | Reviewer in the locale reads broken grammar and flags it as low quality. | Localize properly. Push My App’s 14-language translator regenerates keywords per locale instead of translating them. | Apple 2.3 / Google Metadata |
| Feature graphic contains device mocks or price text (Google) | Play Store policy bans device frames and call-to-action overlays in the feature graphic. | Use a clean graphic with product logo and tagline only. | Google Metadata |
| App title or icon mimics another app (Google Deceptive Behavior) | Icon colors, silhouette, or name look close enough to a popular app to confuse users. | Redesign for visual distance. Side-by-side screenshots of the two icons help a reply. | Google Deceptive Behavior |
| Repetitive or duplicative store listings (Google) | Same team has several near-identical apps on the account. | Consolidate into one listing or meaningfully differentiate each. | Google Spam and Minimum Functionality |
| “Beta” or “pre-release” wording in the public listing | Apple rejects public listings that describe the product as not ready. | Use TestFlight for beta distribution. Remove the word from description, name, and screenshots. | Apple 2.2 |
| Age rating does not match the app experience | App shows UGC or 17+ content but the rating is 4+. | Re-take the questionnaire. In-app content moderation may also be required. | Apple 1.3 / Google Content Rating |
| Icon contains an Apple-owned mark (Apple logo, SF Symbol as main art) | App icon uses system glyphs or the Apple logo as its primary shape. | Design an original icon. Use the app icon resizer to generate every required size from a 1024×1024 master. | Apple 4.1 / Brand Guidelines |
Binary and platform rejections
Binary issues are what Apple’s automated pass flags first and what Google’s pre-launch report catches. Most of these are detectable before submission. Push My App’s Pre-Flight Scanner inspects your .ipa, .apk, and .aab for every item in this section, flagging the exact file, key, or missing declaration that would trip a review.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| App crashes on launch on a specific device | Most common rejection reason. A framework is missing, a permission is denied, or a startup race fires. | Reproduce on the exact device model and OS version in the rejection letter. Apple always tells you which one. | Apple 2.1 |
| App requires a capability the target device does not have | UIRequiredDeviceCapabilities includes an item the installed-on device lacks. | Remove the capability from Info.plist or gate the feature at runtime. | Apple 2.1 |
| Missing Privacy Manifest for required-reason APIs | Enforcement landed May 2024. Apps using required-reason APIs without a PrivacyInfo.xcprivacy get rejected at submission. | Add PrivacyInfo.xcprivacy with the declared reasons for UserDefaults, file timestamp, disk space, and active keyboard APIs. Check every SDK you depend on. | Apple 5.1.1 |
| Privacy Manifest does not cover a bundled SDK | A third-party SDK calls a required-reason API and its own PrivacyInfo file is missing. | Update the SDK. If the vendor has not shipped a manifest, drop the SDK or vendor it with your own manifest. | Apple 5.1.1 |
| Encryption export compliance not declared | ITSAppUsesNonExemptEncryption is missing or set incorrectly. | Add the key to Info.plist. For standard HTTPS and Apple’s crypto APIs, the value is usually false; otherwise file the annual self-classification report. | US Export Admin Regs / Apple 5.1 |
| App Bundle contains private API usage | A string like _setKeyboard or LSApplicationWorkspace appears in the binary. | Remove the private call. Sometimes caused by an older SDK — update it. | Apple 2.5.1 |
| App is built against an old SDK | Apple enforces a minimum SDK each year. As of Apr 2025, new apps must build with iOS 18 SDK or later. | Update Xcode, bump deployment target, rebuild. | Apple 2.4.1 |
| Target SDK level too old (Google) | Play enforces a rolling target API level. As of Aug 2025, new apps must target API 35 (Android 15). | Bump targetSdkVersion and re-test runtime permissions and scoped storage. | Google Target API Level |
| App does not support 16 KB memory pages (Google) | From Nov 2025 Play requires apps targeting Android 15+ to support 16 KB pages. | Rebuild native libraries with 16 KB alignment. Verify with the Play Console App Bundle analyzer. | Google 16 KB page size |
| Debuggable flag in release AAB | android:debuggable="true" slipped into the release manifest. | Build with a release-signing Gradle variant, strip debuggable. | Google Security |
| 64-bit requirement not met (Google) | APK does not include 64-bit ABIs. | Ship App Bundle (.aab) with both arm64-v8a and x86_64 variants. | Google 64-bit |
| APK upload to App Store Connect (iOS) | Wrong artifact uploaded. Apple only accepts .ipa. | Archive in Xcode as iOS App Store Distribution. | Apple submission |
| APK upload to Play Console | Play requires .aab for new apps since 2021. | Use Android App Bundle. Play Asset Delivery handles device-specific slicing. | Google AAB requirement |
| Bitcode flag still enabled in Xcode | Bitcode was deprecated; builds with it set now warn or fail on upload. | Disable Bitcode in the Xcode build settings and re-archive. | Apple deprecation |
Functionality and user-facing rejections
This category is where Apple’s human reviewer actually sits with the app for a few minutes. Every item below assumes a reviewer who has launched your app, tried the first advertised flow, and decided the experience does not match the listing or the guidelines.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| App has limited functionality or duplicates a template | App looks like a reskinned template with no meaningful content. | Ship real content before submission. Even 10 custom screens beats 30 templated ones. | Apple 4.3 / 4.2 |
| Demo account credentials do not work | You left a test credential that expired, or forgot to enable it in production. | Test the demo account end-to-end on a clean install before submission. Include explicit 2FA instructions in the reviewer notes. | Apple 2.1 / App Review Info |
| App requires sign-up before any functionality is visible | Reviewer cannot evaluate the app without creating an account. | Offer a meaningful browse-as-guest mode or allow the reviewer to skip auth on a specific build. | Apple 5.1.1(v) |
| Account deletion is not available in-app | Enforced June 2022. Apps that let users create an account must let them delete it from inside the app, not just email support. | Add a Delete Account button in settings that fully removes the account and confirms with a separate screen. | Apple 5.1.1(v) |
| Third-party login without Sign in with Apple | App offers Google, Facebook, or Twitter login but not Sign in with Apple. | Add Sign in with Apple. It is required whenever a third-party-only social login is offered. | Apple 4.8 |
| App is primarily a WebView of an existing website | Native shell that just loads a URL with no native features. | Add meaningful native functionality: push, offline, share extension, widget. Otherwise move to Safari or a PWA. | Apple 4.2 |
| In-app content bypasses IAP | Unlocks are paid outside the App Store for digital content consumed inside the app. | Route digital-content purchases through StoreKit. Physical goods and real-world services are exempt. | Apple 3.1.1 |
| External purchase links in-app | Outside the US Reader category and the EU DMA exceptions, you cannot link out to pay. | Remove the external link or apply to the External Purchase Link entitlement program. | Apple 3.1.3 / 3.1.3(a) |
| App includes links to beta or TestFlight | Production listing points at a beta flow. | Strip TestFlight links and external beta references from the release build. | Apple 2.2 |
| Restricted content without required permit (Google) | Gambling, alcohol, firearms, or medical-regulated content without licence. | Hold the permit before submitting. Upload licence documents in the Play Console. | Google Restricted Content |
| User-generated content without moderation | App accepts photos, comments, or messages with no filter, report, or block. | Add report, block, moderation queue, and a responsive takedown process. UGC without moderation is a near-auto reject on both stores. | Apple 1.2 / Google UGC |
| AI-generated content with no moderation layer | App calls an LLM or image model and exposes raw output. Apple updated 1.1 in 2024 for this. | Add a visible moderation layer before output is shown. Display a content-policy notice. Log and rate-limit prompts. | Apple 1.1 / Google Deceptive Behavior |
| App simulates the system UI in a misleading way | Shows fake iOS settings, fake alerts, or pretends to be a different app. | Redesign so there is no mistaking your UI for the OS. | Apple 2.3.1 / 4.1 |
Privacy, data, and tracking rejections
Privacy is the category that has tightened the most between 2023 and 2026, and it is the category where Apple and Google now diverge most sharply. Apple enforces through the App Privacy label, the Privacy Manifest, and App Tracking Transparency. Google enforces through the Data safety form and runtime-permission policies. If your Data safety declarations disagree with what the app actually does, that is the rejection — not the data collection itself.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| Privacy Policy URL unreachable or not a privacy policy | URL 404s or points at terms of service, a homepage, or a parked domain. | Publish a real privacy policy. Link directly to the policy page, not the marketing site. | Apple 5.1.1 / Google User Data |
| App Privacy label does not match the Privacy Manifest | The label says “Data Not Collected”; the manifest declares a required-reason API and the SDK collects analytics. | Reconcile. Update the label or remove the collection. Cross-check with every SDK. | Apple 5.1.1 / 5.1.2 |
| Collects user data with no privacy policy at all | Sign-up stores email and name but the app has no policy. | You cannot collect anything without a policy. | Apple 5.1.1 / Google User Data |
| Requests ATT without proper pre-prompt context | Tracking prompt appears cold on launch with no explanation. | Add a pre-prompt screen that explains why tracking is useful, then trigger ATT. Wording must be factual. | Apple 5.1.2 |
| App collects device ID and claims it does not | App still reads IDFA or an advertising ID despite ATT being denied. | Gate every advertising identifier read on the ATT status. | Apple 5.1.2 |
| Data safety form mismatch (Google) | Form says no data collected; the app sends device IDs, location, or crash logs with user identifiers. | Audit every network request. Declare everything the app sends, including analytics and crash SDKs. | Google Data safety |
| Foreground location without clear justification (Google) | App requests ACCESS_FINE_LOCATION but the feature does not need it. | Downgrade to coarse, remove the feature, or document why the feature requires fine location. | Google Location Permissions |
| Background location without a user-visible feature | ACCESS_BACKGROUND_LOCATION requested for an unclear reason. | Remove it. Background location has one of the highest bars for approval on both stores. | Google Background Location |
| Kids category app with third-party analytics | App is rated for children under 13 but embeds analytics or ad SDKs that do not pass Kids review. | Remove tracking SDKs entirely or swap for Kids-compliant analytics. | Apple 1.3 / Google Families |
| COPPA / GDPR misconfiguration | No consent gating for EU or US minors despite collecting data. | Add a consent flow; regionalize data collection. Keep evidence of consent. | Regulation / Apple 1.3 / Google Families |
| SDK collects PII without declaration | Analytics SDK silently collects device contacts or inbox for “attribution.” | Read the SDK’s docs. Remove or downgrade. | Apple 5.1.1 / Google User Data |
Design and content rejections
Design and content rejections are the most subjective category. Two reviewers can look at the same app and reach different conclusions. You reduce your exposure by controlling the things that are objective: your icon, your screenshots, your onboarding, your alerts, and any subscription UX.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| Copycat or trademark violation | Icon, name, or marketing copy too close to an existing well-known app. | Rebrand. Include evidence of prior art or a trademark filing in your reply. | Apple 4.1 / Google IP |
| Incomplete or beta-quality experience | Core flows unfinished or obviously unpolished. | Move to TestFlight or internal testing. Resubmit when the flow works end to end. | Apple 2.2 / Google Quality |
| Placeholder assets (gray boxes, default SwiftUI previews) | Build shipped with unfinished UI. | Do a final screen-by-screen pass before submission. Remove everything that was not designed. | Apple 4.0 |
| Icon does not match screenshots | Screenshots show a logo that does not match the installed app icon. | Re-export both from the same master. The free app icon resizer guarantees consistency across every iOS and Android size. | Apple 2.3.3 |
| Notifications used for marketing without consent | App pushes promotional content without an opt-in toggle. | Add a clear opt-in for marketing notifications distinct from transactional ones. | Apple 4.5.4 |
| Dark-pattern subscription UX | Price is hidden, trial auto-renews without visible disclosure, cancel is buried. | Display price, period, auto-renew, and cancellation path clearly on the purchase screen. | Apple 3.1.2 / Google Subscriptions |
| Objectionable content without age-rating match | App contains violence, adult themes, or gambling with a lower age rating. | Raise the rating, or remove the content. | Apple 1.1 / Google Content Rating |
| AI-generated content resembling real people | App generates deepfakes or photorealistic images of identifiable individuals without consent. | Block prompts that reference real people by name. Disclose and moderate generated output. | Apple 1.1.4 |
| App impersonates a brand or person (Google) | Name, icon, or description implies official affiliation that does not exist. | Remove the implication or produce authorization in the reply. | Google Impersonation |
| Misleading store listing (Google) | Screenshots show functionality not in the app; description overpromises. | Align every screenshot and sentence with the shipped build. | Google Deceptive Behavior |
| Default system assets passed off as custom (launch screen, empty states) | Storyboard with the default iOS launch image; blank list screens with no copy. | Customize every default. Fill every empty state with at least a line of instructive copy. | Apple 4.0 |
| Broken dark mode | App does not adapt to dark mode or inverts colors illegibly. | Test every screen in dark mode. Ship a manual override toggle if time is short. | Apple 4.0 / Google Quality |
Business-model and payments rejections
Payments rejections are narrow but lethal. Each store has a specific processor it requires you to use for digital goods, and each has a specific set of exceptions.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| Subscription terms unclear or missing | Price, period, auto-renew, and cancel method not shown on the purchase screen. | Display all four on the paywall, above the fold, before any tap on Subscribe. | Apple 3.1.2(a) |
| Free trial auto-renews without explicit disclosure | Users tap through a free trial and learn about renewal only in email. | State “After the trial, $X.XX will be billed every month” next to the CTA. Do not rely on small print. | Apple 3.1.2(a) / Google Subscriptions |
| Selling physical goods through IAP | Physical goods must use a regular card processor, not StoreKit. | Replace IAP with Apple Pay or another card processor for shipped goods. | Apple 3.1.5(a) |
| Price tier mismatch between iOS and Android | Google detects a near-identical app with cheaper IAP on iOS, or vice versa, and flags it. | Align pricing or clearly disclose the reason for the difference. | Google Pricing |
| Restoring purchases button is missing | Users on a new device cannot recover IAP. | Add a Restore Purchases button in settings and on the paywall. | Apple 3.1.1 |
| Real-money gambling without the correct permit (Google) | Play allows gambling in some regions if licensed, otherwise it is a flat reject. | Do not submit until the licence is in place. Geofence to permitted regions. | Google Gambling |
| Subscription renewal not using Play Billing (Google) | App sells recurring subscriptions through Stripe or a card provider instead of Play Billing. | Integrate Play Billing for all digital-goods subscriptions, subject to the same exceptions Apple grants. | Google Payments |
| Showing an alternative payment option inside the app (US reader carve-out) | Reader-category carve-out has specific formatting rules; most apps get the execution wrong. | Apply for the StoreKit External Link Account entitlement first. Follow the exact copy and modal flow Apple requires. | Apple 3.1.3(a) |
Android-only and iOS-only special cases
These are the items that catch developers who work primarily on one side and are newly submitting to the other.
| Rejection signal | Why it happens | Fix | Rule |
|---|---|---|---|
| iOS: SF Symbols used as the primary app icon | Apple forbids using system glyphs as the main icon art. | Commission original icon artwork. | Apple 4.1 / HIG |
| iOS: HealthKit entitlement declared but unused | Privacy review flags orphaned entitlements. | Remove the entitlement from the App ID and Xcode if the app does not read health data. | Apple 5.1.3 |
| iOS: Wallet pass signing identity missing | App issues passes but the signing identity is not set up in App Store Connect. | Register the Pass Type ID and embed the correct certificate. | Apple Wallet docs |
| iOS: Liquid Glass / tinted icon missing on iOS 26+ | Icon does not ship the new asset variant introduced with Liquid Glass. | Export the new variants from your icon master and include them in the asset catalog. | Apple HIG 2025 |
| Android: Notifications without POST_NOTIFICATIONS | Since API 33, apps must request POST_NOTIFICATIONS at runtime. | Request the permission before the first notification; fall back gracefully when denied. | Android 13+ |
| Android: SCHEDULE_EXACT_ALARM without justification | App requests exact alarms without a qualifying use case (alarms, timers, reminders). | Justify the use case in Play Console, or switch to inexact alarms. | Google Exact Alarms |
| Android: Foreground services without the right foregroundServiceType | Android 14+ requires declaring the service type (location, media, data sync, etc.). | Declare the type in the manifest and request the matching runtime permission. | Android 14 Foreground Services |
| Android: QUERY_ALL_PACKAGES without an approved use case | App declares QUERY_ALL_PACKAGES but its functionality does not qualify. | Use <queries> with specific packages, or delete the permission. | Google Package Visibility |
| Android: Deep-link verification broken | App claims an HTTPS autoVerify intent but the domain’s Digital Asset Links file is missing. | Publish .well-known/assetlinks.json with the correct SHA-256 fingerprint. | Android App Links |
| Android: Photo picker not used for media selection | App requests READ_MEDIA_IMAGES when the photo picker would suffice. | Switch to the system photo picker. Keeps permissions minimal and reviewers happy. | Android 13 Photo Picker |
A pre-flight workflow that keeps you out of the index
The best defense against everything above is a five-step pre-flight the night before you submit. It takes about twenty minutes and catches the majority of rejections in this index.
- Binary scan.Run a static analysis against your .ipa or .aab. Push My App’s Pre-Flight Scanner checks every item in the Binary and Privacy sections above, including missing Privacy Manifests, wrong target SDK, 16 KB page alignment, debug flags, and over-permissioning.
- Metadata scan. Use the keyword character counter to confirm every localized field is within its store’s limits. Use the subtitle helper to verify the subtitle describes what the app actually does today.
- Screenshot and icon check. Regenerate every required size from a single master so the listing icon matches the in-app icon matches every screenshot overlay. The screenshot size reference lists every 2026 dimension for iPhone, iPad, and Android.
- Store-response readiness. Write a short reviewer note with the demo account, the 2FA codes, any special URLs, and a one-paragraph description of the core flow. Include a test card if you have IAP.
- Appeal template on standby. Keep a one-page response template ready so if a reject does come in, you reply within the hour, not the week.
Run your next build through an 80+ rejection pre-flight
Push My App’s Pre-Flight Scanner runs the full index of binary and metadata checks against your .ipa, .apk, or .aab before you hit Submit. Pair it with direct submission to the App Store and Google Play and you ship from one dashboard.
What to do if you are already rejected
Read the letter twice. Rejection letters usually cite multiple guidelines. Miss one, resubmit, and you get rejected again for the one you missed. Copy each cited section into a task list and work through them individually.
Reply via Resolution Center with evidence, not argument. The reviewer who reads your reply is almost never the one who wrote the letter. They want the shortest path to approving your app. Give them screenshots, video, code diffs, or permit documents — whichever proves your point — and keep prose short.
Use Expedited Review sparingly. Apple grants it for genuinely urgent fixes. Save it for bugs that affect live users, not for missed launch dates. You get maybe two or three a year before Apple stops approving them.
If the rejection is genuinely wrong, appeal. Apple’s App Review Board escalation and Google’s policy appeal path both exist. Both take longer than simply editing and resubmitting, so only use them when the issue is a reviewer error you can point to with a diff. If you’re not sure, compare your approach against how ASO.dev handles the same flow and see whether your implementation is genuinely standard. If you get stuck, the contact form on pushmyapp.ai will get a real human reply the same day.
Frequently asked questions
What is the number one reason apps get rejected from the App Store in 2026?
Guideline 2.1 — Performance: App Completeness. Most first-submission rejections trace to a crash on launch, a broken core feature, or a demo account that reviewers cannot use. Apple's reviewers give every app a few minutes on one device; anything that blocks them from reaching the core experience in that window is an automatic reject.
How long does App Store review take in 2026?
For most first submissions, Apple's published median is around 24 hours. Updates are often faster. During peak launch windows — late November into December and before WWDC — two to three days is common. Google Play review for new apps runs 3 to 7 days; updates to established apps usually clear in under 24 hours.
Can Apple or Google reject my app after it is already live?
Both can. Apple rarely pulls a live app for a review-time issue but will remove apps that violate newer guidelines as enforcement rolls out. Google is far more aggressive: Play's automated post-launch scans can suspend a live app overnight for a policy violation, with a 7-day appeal window. Assume both stores are re-reviewing you continuously.
How is Google Play's rejection process different from Apple's?
Apple's rejections are almost always about quality, design, business model, or metadata accuracy. Google's are disproportionately about data-safety declarations, security posture, permissions, and long-tail policies like Deceptive Behavior and Impersonation. The same app can pass Apple and fail Google on a Data safety form mismatch, or vice versa.
Does using AI-generated content increase my rejection odds?
Yes, on both stores. Apple updated Guideline 1.1 in 2024 to require moderation for user-generated or generative-AI content, and rejects apps that produce images resembling real people without consent. Google flags AI apps that produce or could produce sensitive content without filtering under Deceptive Behavior and Restricted Content. If your app calls an LLM or image model, you need a visible moderation layer.
Can Push My App's Pre-Flight Scanner catch every rejection reason?
No — the Scanner catches every rejection class that can be detected from the binary, the listing metadata, and the assets. That covers most of the Metadata, Binary, Privacy, and Design categories on this page. Rejections that depend on how a reviewer uses your app (a broken demo account, a sparse feature set flagged as spam) still require your judgment. See pricing on the pricing page for what is included in each plan.
Ship your listing without the rejection letter
Push My App generates store-ready metadata, resizes screenshots for every device, translates your listing into 14 languages, and runs an 80+ item rejection pre-flight before you submit.
Start your free trialKeep reading
App Store Rejections
App Store Review Pre-Flight: A 9-Minute Checklist Before You Hit Submit
Nine checks, one per minute, that catch 80 percent of App Store and Google Play rejections. Run them before you hit Submit in 2026. Free checklist.
Read
App Store Rejections
Your App Got Pulled: A 2026 Recovery Playbook
Your live app got suspended. A 7-day appeal window, specific reply templates for the 5 most common post-launch pulls, and how to get back to ranking.
Read
ASO Guides
App Store Optimization for Indie Developers: The 2026 Playbook
The 2026 ASO playbook for indie developers with zero budget. Keywords, metadata, screenshots, localization, reviews, and a 30-day sprint plan.
Read