App Store Rejection: The Most Common Reasons and How to Avoid Them

You have spent months building your app. You have tested it, polished the UI, and aligned your launch timeline with a marketing push. Then Apple or Google sends back a rejection notice, and everything stalls. The review clock resets. Your press window closes. Your team loses momentum.

Apple rejects roughly 40% of app submissions on the first pass. Google's rejection rate is lower but has climbed sharply since Google Play moved to a more manual human-review model in 2022. Neither number is going down. Both stores are tightening their guidelines, and the consequences of getting caught off guard are real: a typical rejection adds 5 to 14 days to your launch timeline, and repeated rejections can result in developer account suspension.

The frustrating part is that most rejections are preventable. The same 10 to 15 issues account for the vast majority of rejections across both stores. If you understand them before you submit, you can avoid almost all of them. This guide covers every major rejection category, the exact guideline language that triggers them, and what you need to do differently.

This is the number one rejection reason for first-time app submitters. Apple's App Store Review Guideline 4.2 is blunt: apps must have enough utility, entertainment, or functionality to justify their existence on the store. Reviewers have to open your app and decide whether it does something meaningful. Many early-stage apps fail this test.

Common failure modes include apps that are essentially static websites wrapped in a WebView with no native features, apps that show a splash screen and not much else, and MVP builds where large sections are blocked behind "coming soon" labels. Apple reviewers are instructed to reject apps that feel like demos or placeholders. If your app cannot stand on its own as a functional product today, it is not ready for submission.

Copycat Apps and Reskinned Templates

Guideline 4.3 targets what Apple calls "spam." If your app is substantially similar to something already on the store, or if it looks like a reskin of a template with a new logo, reviewers will reject it. This catches a lot of app builders who purchase white-label source code and submit without meaningful customization.

The fix is differentiation. Your app needs a clear purpose and a reason to exist that is distinct from every competitor. A reviewer looking at your listing should be able to articulate in one sentence what makes it different. If they cannot, you will not pass.

Demo Accounts and Test Credentials

Apple requires that reviewers can access all features of your app without creating a real account or spending real money. If your app requires signup and you do not provide reviewer credentials in the App Review Information section of App Store Connect, you will be rejected under Guideline 2.1. Create a dedicated demo account with full feature access and enter those credentials before every submission. This is a simple thing to miss under launch pressure.

Apple's Human Interface Guidelines (HIG) are not optional. Reviewers check for obvious violations, and there are several that come up repeatedly. Non-standard UI patterns that behave unexpectedly, custom navigation that breaks iOS conventions, and interfaces that cover or obscure the system status bar without reason are all red flags.

Google Play has its own equivalent in the Material Design guidelines, though the enforcement is less strict. Where Google gets aggressive is on accessibility: apps that fail basic accessibility requirements, such as missing content descriptions on interactive elements or insufficient color contrast ratios, can be rejected or flagged during review.

Broken Layouts and Device Compatibility

Your app must render correctly across every device class it supports. If you list iPhone 16 Pro Max support in your app metadata but the layout breaks on that screen size, you will be rejected. The same applies to iPad: if you claim iPad compatibility, reviewers test on an iPad. Use Xcode's device simulation and Apple's Simulator to verify every supported screen size before submitting. On Android, test on at least one physical device per major screen density bucket.

Dark Mode and Accessibility

Since iOS 13, apps are expected to support Dark Mode. An app that ignores system appearance settings and hard-codes a white background will not necessarily be rejected, but an app where text becomes illegible in Dark Mode almost certainly will be. Run through your app in both light and dark modes before submission. On the accessibility side, make sure all interactive elements have labels that VoiceOver can read. Apple tests with VoiceOver during review more often than most developers expect.

Privacy violations are now one of the most common rejection reasons on both platforms, and the rules have gotten significantly stricter since Apple introduced App Tracking Transparency (ATT) in iOS 14.5 and expanded privacy nutrition labels in 2021. Google followed with its own Data Safety section requirements in 2022. Both stores will reject you if your declared data practices do not match your actual behavior.

Apple's ATT framework requires that you ask users for permission before tracking them across apps and websites owned by third parties. If your app uses an advertising SDK like Meta's Audience Network or Adjust and you have not implemented the ATT prompt correctly, reviewers will find it and reject you under Guideline 5.1.2. The prompt must use Apple's standard AppTrackingTransparency framework. Custom-built prompts that ask for tracking permission in non-standard ways are explicitly prohibited.

Privacy Nutrition Labels and Data Safety Forms

In App Store Connect, you must declare every type of data your app collects, how it is used, and whether it is linked to the user's identity. On Google Play, you fill out the Data Safety form before submission. Reviewers cross-reference your declared practices against the SDKs bundled in your binary. Tools like Apple's privacy report and Google's Data Safety checker will flag mismatches automatically. If your analytics SDK collects device IDs and you have not declared device identifiers as a data type, you will be rejected.

The practical fix is to audit every third-party SDK in your app before submission. Check the documentation for each SDK to understand what data it collects by default. Common culprits include Firebase Analytics, AppsFlyer, Braze, and Branch. Declare everything honestly. Reviewers do not penalize you for collecting data. They penalize you for collecting data you did not disclose.

Privacy Policy Requirements

Every app that collects any user data must link to a privacy policy from within the app and from your store listing. The privacy policy must be publicly accessible (not behind a login), written in plain language, and specific to your app. Linking to a generic company website privacy page that does not mention the app is insufficient. Both Apple and Google will reject apps where the privacy policy URL returns a 404, has expired SSL, or requires authentication to access.

Nothing generates more rejections, and more frustration, than payment policy violations. Apple's Guideline 3.1.1 is the most contentious rule in the App Store: digital goods and services sold inside iOS apps must use Apple's in-app purchase system, and Apple takes 30% (15% for small developers and subscriptions after year one). There is no way around this for digital content.

What counts as a digital good? Subscriptions, premium features, virtual currency, loot boxes, unlockable content, credits used within the app. If a user pays money and receives something digital in return, Apple wants a cut and wants the transaction to flow through StoreKit. Bypassing this by directing users to a web checkout is Guideline 3.1.1 territory and will result in rejection every time.

External Payment Links

The rules around external payment links shifted significantly after the Epic v. Apple antitrust case and subsequent regulatory pressure. As of 2025, Apple allows US App Store apps to link out to external payment pages for certain categories, but only under Apple's entitlement program and with Apple-approved disclosure language. The entitlement requires a separate application, and non-compliant implementations still result in rejection. Outside the US, the rules are governed by local regulations and vary by country. Do not assume that because an external payment link is allowed in one market it is allowed everywhere your app is distributed.

Reader Apps and Physical Goods

Reader apps (Netflix, Kindle, Spotify) are exempt from the in-app purchase requirement for subscriptions to content that can be consumed elsewhere. They are not allowed to include a "Sign Up" or "Subscribe" button that links to their own checkout, but they can include a neutral link to their website. Physical goods (merchandise, food delivery, ride sharing) are also exempt. The rule only applies to digital goods delivered within the app. Getting this classification wrong is a common mistake for apps that blur the line between physical and digital delivery.

Google Play's Billing Policy

Google Play requires Google Play Billing for in-app purchases with the same scope as Apple, at a 15% to 30% commission depending on category and revenue tier. Google has faced similar regulatory pressure and has introduced a User Choice Billing program in select markets. The default requirement still applies: build Google Play Billing correctly using the Play Billing Library 5.x or later, handle all purchase states (purchased, pending, refunded), and verify purchases server-side. Apps that implement billing incorrectly, or that attempt to circumvent Google Play Billing, are rejected under the Payments policy.

A crash during the review session is an automatic rejection. Apple's reviewers open your app and run through the core user flows. If the app crashes during onboarding, crashes when accessing a key feature, or produces an unhandled exception they can see, you are rejected under Guideline 2.1. This sounds obvious, but crashes in specific environments (a new device model, a fresh install without existing data, a specific OS version) are easy to miss in development.

Before every submission, run your app on a clean simulator install with the minimum supported iOS version you declare in your Info.plist. Then run it on a physical device running the latest iOS release. Check crash reporting in Xcode Organizer and Firebase Crashlytics. The week before submission is not the time to discover a crash that only happens on cold launch.

Performance on Older Devices

If your app supports iPhone 12 (still a common supported device floor in 2026), it needs to perform acceptably on that hardware. An app that stutters badly or runs out of memory on devices within your declared support range can be rejected for performance reasons. Profile your app with Instruments, specifically the Time Profiler and Allocations tools, to catch performance regressions before they reach a reviewer's device.

Metadata Violations

Metadata rejections are frustrating because they can happen independently of your binary. Common violations include:

• Keyword stuffing in the app name: Packing competitor names or unrelated keywords into your app title violates both stores' metadata policies. Apple's guideline 3.3.1 is explicit: app names cannot include pricing, terms like "free," or keywords stuffed solely for search rank.
• Inaccurate screenshots: Your screenshots must show the actual app running on real hardware, not competitor apps, not stock photos, and not features the app does not actually have. Showing features gated behind a paid tier without disclosure is a policy violation on Google Play.
• Wrong age rating: If your app contains mature content and you have selected a 4+ or Everyone age rating, reviewers will catch the mismatch and reject you. Be honest about content ratings. An inaccurate age rating is treated as misleading users.
• Misleading descriptions: Claiming your app does something it cannot do is a rejection under Apple's Guideline 2.3 and Google Play's Misleading Claims policy. "AI-powered" is fine if the feature exists. "AI-powered" as a marketing label for a rule-based decision tree will invite scrutiny.

Getting rejected does not mean the conversation is over. Both Apple and Google have formal appeal processes, and they work when used correctly. The key is understanding what to appeal versus what to fix.

If Apple's reviewer has misunderstood what your app does, or applied a guideline that clearly does not apply to your use case, you have grounds for an appeal. Go to the Resolution Center in App Store Connect, select your rejection, and choose "Appeal." Be concise, factual, and professional. Describe exactly why the guideline cited does not apply. Include screenshots or a short screen recording if it helps clarify how the feature works. Emotional arguments ("we worked really hard on this") do nothing. A clear demonstration that the reviewer made a factual error works well.

When to Use the App Review Board

Apple has a dedicated App Review Board for appeals that are denied at the initial level. This escalation path is appropriate when you believe the guideline itself is being applied incorrectly or when you have a novel use case that does not fit neatly into existing categories. Be prepared to wait: App Review Board decisions can take 5 to 10 business days. Do not escalate to the Board for a standard rejection where you simply disagree with the outcome. Reserve it for genuine guideline interpretation disputes.

Google Play's Appeal Process

Google Play rejections go through the Play Console. Select the rejected app, navigate to Policy Status, and submit an appeal through the provided form. Google's appeal responses are often templated and slower than Apple's, but they do result in reversals when the initial rejection was clearly an error. For account-level enforcement actions (policy strikes, account suspension), the appeal process is more involved and may require submitting a detailed explanation of your compliance steps.

When to Give Up the Appeal and Just Fix It

If the rejection is legitimate, appealing wastes time. A clear metadata violation, a genuine crash during review, or a missing privacy disclosure are not appeal cases. Fix the issue and resubmit. Apple's standard review time is 24 to 48 hours for most apps in 2026 (expedited review is available for critical bug fixes in production apps). A fast fix and resubmit often gets your app approved faster than a drawn-out appeal.

The best way to handle a rejection is to avoid it. Teams that consistently pass review on the first submission follow a structured pre-submission process. Here is the checklist we use before every client app submission.

Technical Readiness

• Clean install test: Delete the app from your device and reinstall from scratch. Verify onboarding, login, and core flows complete without errors.
• Minimum OS version test: Run the app on a device or simulator running your declared minimum iOS or Android version.
• Crash check: Review Crashlytics or Sentry for any crash-free session rate below 99.5% in the past 7 days. Investigate and fix before submitting.
• Memory and performance: Profile with Instruments (iOS) or Android Profiler. Memory spikes above 500MB on mid-range devices are a risk.
• Network failure handling: Test offline mode and poor connection scenarios. Unhandled network errors can appear as crashes to reviewers.

Privacy and Compliance

• ATT prompt: Verify the AppTrackingTransparency prompt displays before any tracking SDK initializes on iOS.
• Privacy nutrition labels: Audit every third-party SDK for data collection. Confirm your App Store Connect privacy declarations match.
• Data Safety form (Google Play): Verify all data types collected are accurately declared, including SDKs that collect data automatically.
• Privacy policy: Confirm the URL is live, publicly accessible, HTTPS, and accurately describes data practices for this specific app.

Payments and In-App Purchases

• StoreKit integration: Test all purchase flows in the Sandbox environment. Verify restore purchases works correctly.
• Receipt validation: Server-side receipt validation is required. Client-only validation is a security and policy risk.
• No external payment links: Confirm no buttons or text direct users to external payment pages outside the entitlement program.

Metadata and Store Listing

• Screenshots: Show the actual app on real device frames. No competitor names, no features that do not exist yet, no misleading claims.
• App name: No pricing, no "free," no keyword stuffing beyond your app's actual purpose.
• Age rating: Honest and accurate for every type of content in the app.
• Demo account: Active credentials with full feature access entered in App Review Information.
• Review notes: Explain any non-obvious features. If your app requires a specific physical device or location context, say so explicitly.

Navigating App Store review policy is one of the areas where experienced teams have a real advantage. If you are launching a mobile app and want to minimize the risk of rejection delays, book a free strategy call and we will walk through your submission readiness together.