Common App Store Rejection Reasons and How to Fix Them

Four rules drive most app store rejection reasons on Apple's platform: incomplete or crashing builds (Guideline 2.1), spam and copycat submissions (4.3), thin functionality (4.2) and privacy violations (5.1.1). Apple turned away over 2 million submissions in 2025, including 443,000 for privacy problems alone.

A rejection notice usually arrives the week your marketing calendar goes live. The build works, the design passed three review rounds, and then one Resolution Center message pushes launch into next month. The useful part: reviewers reject apps for a short, predictable list of reasons, and almost every one of them has a known fix.

This guide walks through the app store rejection reasons that actually appear in review messages, the fix for each, how the appeal process works on both platforms, and the pre-submission checklist that keeps you out of a second round. Every figure comes from Apple's and Google's own 2025-2026 disclosures.

Table of Contents

• Rejection Reasons at a Glance
• What Both Stores Tightened in 2026
• App Store Rejection Reasons: Apple's Top 8
• Google Play Policy Violations
• Your First 24 Hours After a Rejection
• How the Appeal Process Works
• Repeat Violations and Account Termination
• Pre-Submission Checklist
• Frequently Asked Questions

Rejection Reasons at a Glance

The table below maps the app store rejection reasons teams hit most often against the work each one demands. Timelines assume you diagnose the problem correctly on the first read.

Notice what the list has in common: none of these rules measure code quality. Your app can run flawlessly and still fail review because a declaration contradicts what the binary actually does.

What Both Stores Tightened in 2026

Apple updated its review guidelines in June 2026 with sharper language about low-value apps. New submissions in saturated categories — flashlights, wallpapers, dating, sound effects, simple timers, fortune telling — no longer clear review unless they deliver a meaningfully different or improved experience. As MacRumors reported, the revision also lets Apple pull low-effort apps after publication.

The scale of enforcement explains the tone. Apple's 2025 fraud prevention report counts 1.2 million new apps and nearly 800,000 updates rejected in a single year. Within that total, 371,000 submissions copied other apps, qualified as spam or misled users, and 22,000 contained hidden or undocumented features. Apple also terminated 193,000 developer accounts over fraud concerns.

Google runs a different model with a similar outcome. According to Google's 2025 security review, the company prevented over 1.75 million policy-violating apps from publishing, banned more than 80,000 developer accounts and stopped 255,000 apps from gaining excessive access to sensitive user data. Google also runs more than 10,000 safety checks on every app it publishes and now feeds generative AI models into that review pipeline.

One practical consequence follows from all of this. As automated scanning grows, "the last build passed" stops working as an argument. The same binary can trip a new detection rule six months later.

App Store Rejection Reasons: Apple's Top 8

Apple cites a guideline number in every rejection message. Reading that number correctly does half the work, because each rule expects a different kind of evidence. Open the relevant section of the App Review Guidelines before you write a single line of your reply.

Guideline 2.1 — App Completeness

This rule produces the largest share of rejections and usually the easiest fixes. A reviewer opens your app, hits a wall and stops. Crashes, empty list screens, infinite loading spinners and expired demo credentials all land here.

Three things close most 2.1 cases. First, supply a demo account that never expires and put the credentials in the App Review notes. Second, populate that account with realistic data, because an empty dashboard reads as an unfinished app. Third, write step-by-step instructions for any feature behind a paywall, an invite or a role permission.

Add context when your app depends on hardware, carriers or geography. Reviewers test from California, so a verification flow tuned for one market can fail silently on their device.

Guideline 4.3 — Spam

Rule 4.3(a) targets near-identical submissions shipped under separate bundle IDs — one app per city, per branch or per franchise. Rule 4.3(b) covers repetitive entries in saturated categories, and Apple expanded that language in 2026.

Only real differentiation clears this rule. A new icon and a fresh colour palette will not move a reviewer. Describe the specific capability that separates your app from what already exists, then make sure the build demonstrates it.

Businesses that need many branded variants get better results from one app with account-based content. Users sign in and see their own branch, while the store holds a single listing. That architecture removes the 4.3 risk and cuts your maintenance to one codebase.

Guideline 4.2 — Minimum Functionality

This rule stops projects that drop a website into a WebView and call it an app. Apple's standard wording says the experience does not differ enough from browsing in Safari. Bolting on push notifications does not clear the bar either.

Recovery means building a genuine native layer. Native navigation, offline state handling, camera access, biometric sign-in — anything a browser cannot do. If your product team cannot answer "why does this need to be an app?" in one sentence, the 4.2 risk remains.

Teams planning that move should scope mobile app development around native capabilities from the start. Retrofitting them after a rejection always costs more.

Guideline 5.1.1 — Privacy and Data Collection

Apple prohibits mandatory personal data that your core feature does not need. A catalogue app that forces phone verification, or a recipe app demanding a birth date, fails here. Adding a guest flow that works without registration solves most cases.

Purpose strings cause the second wave of 5.1.1 rejections. When you request location, camera or contacts, the prompt must state what you do with that data. "Required for the app to work" never passes.

Your privacy policy carries the rest of the weight. The URL must resolve, and the policy must state what you collect, who else receives it and how a user requests deletion. Teams serving European or Turkish users should align that page with GDPR and KVKK obligations at the same time.

Guideline 2.3 — Accurate Metadata

These rejections never touch your binary. You correct the store listing and resubmit the same build. Screenshots showing features that do not exist, descriptions promising "AI-powered" behaviour the app lacks, or imagery referencing other platforms all trigger it.

Screenshots must show the real interface in use. Splash screens, login forms and design mockups fail the requirement. Every claim in your listing needs a matching feature in the build under review.

Guideline 3.1.1 — In-App Purchase

Digital content, subscriptions and in-app currency require Apple's purchase system. Physical goods and real-world services require the opposite — your own payment stack. E-commerce teams see the split clearly: selling shoes through your own checkout passes review, while a premium membership inside the same app belongs in IAP.

A US court ruling in May 2025 opened external purchase links on the US storefront. That exception stays regional. Apps that show external links across all storefronts without a region check still fail review.

Guideline 4.8 — Login Services

If your app offers a third-party login such as Google or Facebook, it must also offer an equivalent option, and Sign in with Apple satisfies the requirement by default. Equivalence has technical conditions: the alternative must limit collection to name and email, let users hide their email address, and skip advertising data collection without consent.

The rule does not apply when you only run your own email and password system. Reviewers also check that the button style and placement follow Apple's design requirements.

Guideline 5.2 — Intellectual Property

Prepare your licence documents before submission whenever the app uses brands, logos, characters or licensed content. Reviewers usually ask for proof, and the case closes quickly once you supply it. Without documentation, an appeal will not help.

Agency-published apps hit a specific trap here: the developer account belongs to one legal entity while the brand belongs to another. A short written authorisation from the trademark owner removes that risk entirely.

Google Play Policy Violations

Google's process differs from Apple's in two ways. Fewer submissions fail on the first pass, but post-publication enforcement runs much harder, so an app can disappear months after launch. Google also names the policy rather than citing a numbered guideline.

Data Safety Form Mismatches

Your Data safety form in Play Console must match what the app really does. Google scans the binary and compares it to your declaration. Third-party SDKs cause most failures: if an analytics, ads or crash-reporting library collects data, Google counts that as collection by you.

Build an SDK inventory before you fill the form. List the data category each library touches, then reconcile that list with your privacy policy. The form, the policy and your in-app permission prompts all need to tell one consistent story.

Sensitive Permissions and Background Location

Background location, SMS, call log and full package visibility fall into the restricted category. Each one requires a Permissions Declaration Form explaining why the permission serves your core feature and why a privacy-friendlier alternative does not work.

A short screen recording makes the strongest case in those forms. Video proves which screen delivers the user benefit and typically saves you a review round.

Broken Functionality

Google's Broken Functionality policy covers apps that fail to complete a basic flow — screens that never load, buttons that go nowhere, lists that stay empty, builds that close on first launch. Reading the pre-launch report before you promote a release prevents most of these.

Target API Level and the Testing Requirement

Under Google's target API level requirements, new apps and updates must target Android 16 (API level 36) from 31 August 2026, while existing apps need Android 15 (API level 35) to stay available to new users. Teams that need more time can request a one-time extension through 1 November 2026.

Personal developer accounts created after 13 November 2023 face an extra gate. Play Console's testing rule requires at least 12 testers opted into a closed test continuously for 14 days before you can apply for production access. Organization accounts skip that requirement, which is why most businesses should register as a company and start the D-U-N-S process early.

For the full sequence from account setup to store approval, our guide on how to publish an app covers each step in order.

Your First 24 Hours After a Rejection

Rushing costs more than the rejection itself. This sequence keeps the number of review rounds down.

1. Read the whole message. Apple usually attaches a screenshot or video showing exactly where the problem appeared.
2. Open the cited guideline. Sub-sections demand different fixes; 2.3.3 and 2.3.10 sit far apart in practice.
3. Identify the rejection type. Metadata rejections need no new binary — correct the listing and resubmit the same build. Binary rejections mean a new upload and a fresh review cycle.
4. Fix everything in one pass. Partial fixes invite reviewers to open additional issues on the next round.
5. Reply with specifics. List what you changed, attach screenshots, and add a 30-second screen recording when the fix involves a flow.
6. Reschedule the launch. Apple reviews 90% of submissions in less than 24 hours on average, but each resubmission starts a new review window. Move press and ad timelines accordingly.

How the Appeal Process Works

Most rejections never need an appeal. When the reviewer is right, fixing and resubmitting always beats arguing. Appeal only when you believe someone applied a guideline your app genuinely satisfies.

Apple runs a two-tier process. You reply first through the Resolution Center, which resolves the majority of misunderstandings. If that fails, you escalate to the App Review Board. Apple grants one appeal per rejected submission and asks you to answer any outstanding information requests before you file.

Strong appeals contain three elements: the guideline number, a factual explanation of how your app complies, and evidence. Screen recordings, licence agreements, architecture diagrams and user-flow charts all qualify. Commercial-impact arguments and emotional language change nothing.

On Google's side you appeal from the app status screen in Play Console, where the policy notice links straight to the form. The same principle applies — technical evidence that contradicts the violation claim carries the decision.

Repeat Violations and Account Termination

A single rejection leaves no permanent mark on your developer account. Repeated violations of the same rule belong to a different category. Apple terminated 193,000 developer accounts in 2025 and Google banned more than 80,000, and deliberate repeat offences account for most of those numbers.

The simplest way to manage that risk is to stop treating a rejection message as an opening offer. Resubmitting the same approach after the same rejection creates a pattern that automated systems flag. When a feature sits close to a guideline boundary, asking Apple before you ship costs far less than finding out afterwards.

One more rule for companies that publish through an agency: keep ownership of the store accounts on the brand side. Sharing a termination risk with a third party is not worth the convenience.

Pre-Submission Checklist

Working through these items measurably raises your odds of a first-pass approval.

• Demo account: never expires, contains realistic data, reaches every role.
• Crash testing: run TestFlight and the Play pre-launch report across device and OS versions.
• Privacy policy: live URL, data inventory, sharing parties, deletion request path.
• Purpose strings: each one explains a concrete user benefit.
• Data safety form: reconciled line by line with your SDK inventory.
• Screenshots: real interface only, existing features only.
• Payment architecture: digital goods in IAP, physical goods in your own checkout.
• Login options: Sign in with Apple present whenever third-party login exists.
• Target API: targetSdk at or above the current threshold.
• Testing gate: 12 testers and 14 continuous days complete for personal Play accounts.

To work through the same sequence as a live checklist, use our app launch checklist tool. Platform-specific details sit in our guides on iOS app development and Android app development.

Frequently Asked Questions

How long does it take to resolve app store rejection reasons?

Metadata rejections usually close the same day because they need no new binary. Technical rules such as Guideline 2.1 and 5.1.1 take one to five days. Guideline 4.2 and 4.3 rejections require product changes and can stretch across two to six weeks.

Does resubmitting send my app to the back of the queue?

Uploading a new binary returns the app to Waiting for Review and starts a fresh review cycle. That is standard process rather than a penalty. For metadata rejections you resubmit the same build without a new upload.

Do app store rejection reasons damage my developer account?

Individual rejections leave no lasting effect on your account standing. Risk builds when you repeat the same violation. Deliberate and persistent breaches can end in account termination.

How do I get past a Guideline 4.3 spam rejection?

State in writing which specific capability separates your app from existing ones, and make sure the build demonstrates it. Consolidate multi-brand structures into one app with account-based content. Cosmetic changes will not clear this rule.

Will Apple reject my app if I convert my website into one?

Wrapping a site in a WebView carries a very high Guideline 4.2 risk. Apps that add native navigation, offline behaviour, device features and a real notification architecture can pass. The deciding question is whether your app does something a browser cannot.

Why is my app stuck without publishing on Google Play?

For new personal accounts, the most common cause is an incomplete 12-tester, 14-day closed test. The second is a mismatch between your data safety form and actual SDK behaviour. The third is a target API level below the current threshold.

Does appealing put my app at risk?

An appeal creates no additional penalty for your app. It does extend your launch timeline while you wait. When the reviewer has a valid point, fixing and resubmitting produces a faster result.

What extra documents do non-US companies need?

Organization accounts on Google Play require a D-U-N-S number and website verification, and obtaining a D-U-N-S number can take several weeks. Apple runs a comparable check on company enrolments. Companies serving EU or Turkish users should also align their privacy policy with GDPR and KVKK obligations.

A rejection notice is not a verdict on your product. Almost all app store rejection reasons come down to declarations that do not yet match your build. Teams that read the cited rule carefully, gather evidence and fix everything in a single pass usually turn a rejection around in days rather than weeks.

If your app just came back rejected, or you want an independent review before you submit, share the details through our contact page and we will map out the compliance gaps and a realistic launch timeline with you.