← Blog/App Submission

Top App Store Rejection Reasons and How to Fix Them (2026)

A complete reference of the most common rejection reasons across the App Store and Google Play, organised by category, with exact steps to fix each one before you resubmit.

Mar 20, 2026·14 min read·AppTester.co Team

Before you resubmit: Run the free AppTester Health Check on your binary. It automatically detects debug builds, missing privacy manifests, signing errors, and SDK version issues — the most common instant-rejection causes — in under 30 seconds.

Build rejections

Debug build submitted

BothInstant rejection

Fix

Never submit from Xcode Run or Android Studio Run. Use Archive (iOS) or a signed release Gradle task. Verify: aapt dump badging your-app.apk | grep debuggable should return nothing.

Wrong signing certificate or keystore

BothInstant rejection

Fix

iOS: use a Distribution provisioning profile, not Development. Android: sign with your release keystore. Run keytool -list -printcert -jarfile your-app.apk to verify.

App crashes on launch

BothInstant rejection

Fix

Test on real devices, not simulators only. Run on the oldest supported OS version. Firebase Crashlytics or Sentry will surface launch crashes during beta testing.

Minimum SDK / target SDK too low (Android)

AndroidInstant rejection

Fix

Google Play requires targetSdkVersion to be within one year of the latest Android release. As of 2026: API level 35 minimum. Update build.gradle.

App built with outdated Xcode (iOS)

iOSRejection

Fix

Apple requires submissions to use the latest stable Xcode within a few months of each release. Check App Store Connect developer news for the current requirement.

Privacy rejections

Missing privacy policy link

BothRejection

Fix

Add a working privacy policy URL in App Store Connect / Play Console, and link to it within the app on the first screen that collects user data or during onboarding.

Missing iOS Privacy Manifest (PrivacyInfo.xcprivacy)

iOSRejection

Fix

Required for all apps since iOS 17 SDK. Create PrivacyInfo.xcprivacy at the target root. Declare every Required Reason API your app or its third-party SDKs use.

Undeclared tracking (iOS App Tracking Transparency)

iOSRejection

Fix

If your app tracks users across apps or websites, you must implement ATT framework and request permission before tracking. Declare usage in the privacy manifest.

Data Safety section incomplete or inconsistent (Android)

AndroidRejection or warning

Fix

In Play Console, complete the Data Safety form. Every permission your app requests must be declared. Every third-party SDK that collects data must also be declared.

Excessive permissions not justified

BothRejection or flagged

Fix

Remove any permission not directly required by a user-facing feature. If a permission is needed, add a usage description string (iOS) or explain it in the Data Safety form (Android).

Metadata rejections

Misleading screenshots

BothRejection (Guideline 2.3.3)

Fix

Screenshots must show the current app UI. Remove any screenshot showing a feature not present in the submitted build. Do not use mockups as store screenshots.

Keyword stuffing in app name or subtitle

iOSRejection

Fix

App name and subtitle must not be keyword lists. 'Best Todo App Pro Task Manager Notes Planner' is not an app name. Use clear, brand-appropriate naming.

App description mentions competitor names

BothRejection

Fix

Remove any competitor brand names from the description. Phrases like 'better than [CompetitorApp]' are grounds for rejection.

Placeholder or lorem ipsum content

BothRejection

Fix

Remove all placeholder text from the app UI and store listing before submission. Reviewers will flag any visible lorem ipsum or 'TBD' content.

App name or icon too similar to another app

BothRejection

Fix

Search the store for your app name and icon concept before submission. Similarity to well-known apps is a rejection cause.

Content rejections

Inappropriate content for age rating

BothRejection

Fix

If your app contains mature content, set the age rating accordingly. A 4+ rated app must have no violence, adult content, or strong language.

App does not work as described

BothRejection (Guideline 2.1)

Fix

Test every flow listed in your description. If a feature is broken, remove it from the description or fix it before submission.

App has no standalone utility (iOS)

iOSRejection (Guideline 4.2)

Fix

Apple rejects apps whose only function is to display a website. Your app must provide features that justify being a native app.

Unfinished or demo app

BothRejection

Fix

Every feature in the app must be complete. Apps in clearly beta/demo state are rejected. Remove all under-construction screens and stub pages.

Payments rejections

External payment link in iOS app

iOSRejection (Guideline 3.1.1)

Fix

You may not direct users to external payment systems in an iOS app without Apple's entitlement. Use StoreKit for in-app purchases. Note: the entitlement for alternative payments has specific rules — read the current guidelines.

In-app purchase not working during review

BothRejection

Fix

Set up a sandbox test account and test every IAP flow before submitting. Provide test account credentials in the App Review Notes.

Subscription without clear terms

BothRejection

Fix

Auto-renewing subscriptions must display the price, duration, and cancellation terms before the user subscribes. Add this to the subscription screen.

Accounts rejections

Sign In with Apple not implemented (iOS)

iOSRejection (Guideline 4.8)

Fix

If your app offers social login (Google, Facebook, Twitter), you must also offer Sign in with Apple. Add it to your auth flow.

No account deletion option

BothRejection

Fix

Both Apple and Google require apps with account creation to also allow account deletion from within the app. Add this to account settings.

Login required for all features

BothMay be rejected

Fix

Apps that require account creation before any content is accessible risk rejection. Allow users to browse or try features before being forced to create an account.

Functional rejections

Broken links in app

BothRejection

Fix

Test every link in the app: privacy policy, terms of service, support link, and any in-app web links. Broken links are a rejection cause.

App does not support required device capabilities

iOSRejection

Fix

If your app declares a required device capability in Info.plist (e.g., camera, NFC), it must actually use that feature. Remove unused capability declarations.

Location used without visible purpose

BothRejection

Fix

If your app requests location, it must use it for a visible, user-facing feature. Requesting location with no obvious purpose causes rejection.

VoiceOver / accessibility is broken

iOSMay be rejected

Fix

Apple reviewers test with VoiceOver. Ensure all interactive elements have accessibility labels and that the app is navigable without sight.

Legal rejections

App contains copyrighted content without license

BothRejection

Fix

Remove any unlicensed images, fonts, music, or third-party assets. Use only assets you own or have a verified license for.

Gambling without appropriate license declaration

BothRejection

Fix

Real-money gambling apps require platform approval and proof of gaming license. Declare your license in the submission notes.

Catch rejections before you submit

Run the AppTester Health Check on every build — it catches binary, signing, SDK, and privacy manifest issues instantly

Use the AppTester Rejection Database to look up specific rejection messages and find exact fixes

Submit for human testing before your first submission — reviewers test manually, so your app should pass a human review first

Provide test credentials in App Review Notes for any login-protected features

Read the full App Store Review Guidelines and Google Play Developer Policy at least once — many rejections come from not knowing the rules exist

Check your app for rejection risks — free

Upload your APK, AAB, or IPA. The Health Check scans for the most common binary-level rejection causes in under 30 seconds.