App Store Rejection: The Most Common Reasons Apps Get Rejected (And How to Avoid Them)

App Store Rejections

Getting rejected on your first app store submission feels alarming, but it’s far more common than most first-time app owners expect — a meaningful share of all first submissions get sent back with required changes. The good news is that most rejection reasons are predictable and entirely avoidable once you know what reviewers are actually checking for.

Why App Store Review Exists

Apple’s App Store and Google Play both run manual and automated review processes before any app goes live, checking for policy violations, broken functionality, and misleading claims. The review isn’t arbitrary — it exists to protect users from apps that crash, misrepresent themselves, or mishandle personal data. Understanding what reviewers are actually screening for is the fastest way to avoid a rejection cycle.

The Most Common Rejection Reasons

1. Crashes or Bugs During Review

This is consistently one of the top rejection causes. Reviewers test core user flows on real devices, and any crash — even in a feature that works fine in your own testing environment — results in an immediate rejection. Testing on multiple real devices and OS versions before submission, not just the simulator you built on, catches most of these issues.

2. Incomplete or Placeholder Content

Submitting an app with “lorem ipsum” text, broken image placeholders, or non-functional buttons signals an unfinished product. Reviewers reject apps that appear incomplete even if the core functionality technically works.

3. Missing or Unclear Privacy Policy

Every app that collects any user data — which is nearly all apps — needs a clear, accessible privacy policy linked both in the app store listing and within the app itself. A missing, broken, or vague privacy policy link is an easy and extremely common rejection trigger.

4. Requesting Permissions Without Clear Justification

If your app requests camera, location, or contacts access without the app’s functionality making it obvious why, reviewers will flag it. Each permission request should include a clear, specific explanation string telling the user exactly why it’s needed — a generic “this app needs your location” rarely passes.

5. Misleading Metadata or Screenshots

Screenshots, descriptions, or keywords that don’t accurately represent what the app actually does are a direct policy violation, not just a minor issue. This includes using screenshots that show features not yet implemented, or stuffing the description with unrelated keywords to game search.

6. Broken Login or Account Creation

Reviewers typically need to log in to test your app’s core functionality. If account creation or login is broken, buggy, or requires something the reviewer can’t access (like a verification SMS to a real phone number), the entire submission gets rejected without the reviewer even testing the core features.

7. Apple-Specific: Missing Sign in with Apple

If your app offers third-party login options like Google or Facebook sign-in, Apple requires you also offer Sign in with Apple as an equivalent option. This specific rule catches many first-time iOS developers off guard.

8. Google Play-Specific: Data Safety Form Mismatches

Google Play requires a detailed Data Safety declaration describing exactly what data your app collects and how it’s used. If this declaration doesn’t match what the app actually does — even unintentionally — it’s grounds for rejection or later removal.

Before Submitting

Common Rejections

A Pre-Submission Checklist

• Test the full app on at least two real physical devices, not just a simulator
• Remove all placeholder text, images, and non-functional elements
• Link a complete, accurate privacy policy in both the listing and in-app
• Add clear justification strings for every requested permission
• Confirm screenshots and description accurately reflect current functionality
• Provide reviewer-accessible test credentials if login is required
• For iOS: confirm Sign in with Apple is included if other third-party logins exist
• For Android: double-check the Data Safety form matches actual app behavior

What to Do If You Get Rejected Anyway

Read the specific rejection reason carefully — both Apple and Google provide a stated reason, not just a generic rejection. Address that exact issue, document the fix in your resubmission notes, and avoid introducing unrelated changes in the same resubmission, which can trigger a fresh full review instead of a faster targeted one.

Frequently Asked Questions

How long does app review typically take?
Apple’s review typically takes 24-48 hours; Google Play’s can range from a few hours to several days depending on the app’s category and history.

Can I appeal a rejection I believe is incorrect?
Yes, both platforms offer an appeals process if you believe a rejection misapplied their guidelines, though this should be reserved for genuine misunderstandings rather than policy violations you can simply fix.

Does a rejection hurt my app’s future standing?
A standard rejection with a fix and resubmission has no lasting negative impact. Repeated policy violations or attempts to circumvent guidelines, however, can affect your developer account standing.

Our team handles app store submissions as part of every build, specifically to avoid this back-and-forth. Get in touch if your app is stuck in review.