15 Common App Submission Mistakes: And How to Fix Every One
Most app rejections are preventable. Here are the 15 mistakes developers make most often when submitting to the App Store and Google Play: with exact fixes for each.
Apple and Google reject a combined 300,000+ app submissions every month. The majority of those rejections come from the same set of avoidable mistakes: problems that a pre-submission checklist or a five-minute automated scan would have caught. Here are the 15 most common, in order of how frequently they cause rejections.
Submitting a debug build instead of a release build
Debug builds are rejected instantly by both stores. They're larger, slower, and contain logging and test endpoints that stores explicitly prohibit in production apps.
Fix
Always generate your build using Release configuration with ProGuard/R8 enabled (Android) or Archive → Distribute App in Release mode (iOS). Run our free App Health Check before submission: it detects debug builds in seconds.
Missing or non-functional privacy policy URL
Any app that collects user data, uses analytics SDKs, or includes social features must have a publicly accessible privacy policy URL in both the store listing and within the app itself.
Fix
Write a real privacy policy (not generic boilerplate). Host it at a stable URL. Add it to App Store Connect under App Privacy. Link it from your app's Settings screen.
Not providing demo/test account credentials
If your app requires login, Apple reviewers must be able to access all features. Apps submitted without credentials are immediately rejected with a request to provide them: wasting a review cycle.
Fix
Add a valid email and password in the 'Notes for Reviewer' field in App Store Connect. Test these credentials yourself before submitting. Create a dedicated test account, not your personal one.
Screenshots that don't match the actual app UI
Reviewers compare screenshots to the live app. If your screenshots show a different UI, different features, or a more polished version than what's submitted, you'll be rejected for misleading metadata.
Fix
Take screenshots from the actual build you're submitting: not from design files or an older build. Update screenshots with every major UI update.
Requesting permissions on first launch without context
Showing camera, location, contacts, and microphone permission dialogs all on first launch: before the user has seen any benefit: is a pattern both stores now actively reject.
Fix
Request permissions lazily: at the point in the app where the feature is actually needed. Show an in-app explanation screen before the system dialog. Remove any permissions your app doesn't actively use.
Missing iOS Privacy Manifest (PrivacyInfo.xcprivacy)
Since May 2024, every iOS app submission must include a PrivacyInfo.xcprivacy file. Without it, your submission is automatically rejected.
Fix
In Xcode: File → New File → Resource → App Privacy. Declare all required reason APIs your app uses. Ensure every SDK you include also has its own privacy manifest. See our full iOS Privacy Manifest guide.
App crashes during reviewer walkthrough
Crashes in the first 60 seconds are the single most common reason for rejection. Reviewers test the core flows: if anything crashes, it's rejected immediately.
Fix
Install your release build on a physical device (not simulator) and test every flow yourself. Use Crashlytics to catch crashes pre-launch. Test on low-end devices and without internet connectivity.
targetSdkVersion below Google Play's minimum
Google Play requires new apps to target Android 14 (API 34) or higher. Apps targeting older versions will be blocked from updating or publishing.
Fix
Update targetSdkVersion to 34 in your app/build.gradle. Test thoroughly on Android 14 devices: several permission and intent behaviours changed in API 34.
In-app purchases bypassing Apple's payment system
Linking to a website, mentioning external subscriptions, or directing users to pay outside StoreKit for digital goods results in rejection and potential developer account removal.
Fix
Use StoreKit 2 for all in-app digital purchases. Physical goods and real-world services are exempt. Even links to 'manage your subscription at our website' can trigger rejection.
App description includes placeholder or outdated content
App descriptions that mention features not present in the build, reference removed functionality, or contain generic marketing copy that doesn't describe the app accurately will trigger rejection.
Fix
Your description should exactly describe what the submitted build does. Have someone unfamiliar with your app read the description and then use the app: if anything doesn't match, update it.
Inaccurate Data Safety form (Google Play)
Google cross-references your Data Safety Section against what your APK actually does, including embedded SDKs. Inaccurate declarations: even accidental ones from third-party SDKs: can result in removal.
Fix
Audit every SDK in your APK using Exodus Privacy or AppTester's Health Check. Update your Data Safety form to match what each SDK actually collects, not just what your own code does.
No app icon or wrong icon format
Missing icons, icons with alpha channel (iOS), icons using default system templates, or icons in the wrong size cause immediate automated rejection before a human even reviews your app.
Fix
iOS: 1024x1024 PNG without alpha channel. Android: Adaptive icons with separate foreground and background layers for all density buckets (mdpi through xxxhdpi). Use our Health Check to verify icon completeness.
App description uses competitor brand names
Referencing competitor app names in your title, subtitle, or keyword field (even as 'alternative to X') violates App Store guidelines and triggers metadata rejection.
Fix
Describe your app on its own merits. Use your 100-character keyword field for generic terms, not brand names. Keep your title and subtitle factual descriptions of your app's function.
Subscription terms not disclosed before purchase
Hiding the price, trial length, or renewal terms: or showing them only in fine print: is one of the most aggressively enforced policies in both stores.
Fix
Display price, trial duration, and renewal frequency prominently on the paywall screen. Use the native store subscription sheet. Include a 'Manage Subscription' link in your app settings.
Not testing on real devices before submission
Simulators and emulators don't reproduce hardware-specific crashes, permission dialogs, real camera behaviour, or network conditions. The reviewer tests on a real device. You should too.
Fix
Test on at least two physical devices before every submission: ideally one flagship and one mid-range or older device. Use AppTester.co for structured human testing on a range of real devices.
Catch all 15 before you submit
Our free App Health Check automatically scans for the most common submission mistakes: debug builds, missing privacy manifests, permission issues, and more. Takes 30 seconds.