How to Avoid Submitting Debug Builds to the App Store
Submitting a debug build is the single most common immediate rejection. It is entirely preventable. Here is exactly how to verify your build type before every submission.
Why this matters: Both the App Store and Google Play run automated pre-screening on every submission. A debug build is detected and rejected before a human reviewer ever sees it. You waste a review cycle and up to 2 weeks of review time.
Debug vs release: what actually differs
Size
Debug
2x to 4x larger than the release equivalent. Debug symbols, logging data, and test endpoints are all bundled in.
Release
Optimised and stripped. ProGuard/R8 removes unused code and obfuscates class names. Noticeably smaller.
Performance
Debug
Slower — JIT compilation, assertions, and heavy logging are all active. Battery drain is higher.
Release
Optimised — AOT compilation on Android, aggressive optimisation flags on iOS. This is what users experience.
Logging
Debug
All log statements are active. Console logs, debug prints, and verbose network logging are included.
Release
Logging should be stripped or gated behind a flag. Sensitive data in logs is a security risk in production.
Network endpoints
Debug
Often points to development or staging APIs. Test endpoints may accept invalid data or skip authentication.
Release
Points to production APIs only. Any debug endpoint left active in production is a security vulnerability.
Signing
Debug
Signed with the debug keystore. App stores will not accept debug-signed builds.
Release
Signed with your production/distribution keystore or certificate.
Detectability
Debug
debuggable=true in AndroidManifest.xml (Android). Development provisioning profile in the IPA (iOS). Both are detected instantly by store automation.
Release
debuggable=false or absent. Distribution provisioning profile.
How to verify your build before submission
Android
In build.gradle: confirm buildTypes { release { debuggable false } }
Run: aapt dump badging your-app.apk | grep debuggable — should return nothing
Check signing: keytool -list -printcert -jarfile your-app.apk — should show your release certificate, not the debug keystore
Confirm ProGuard/R8: minifyEnabled true in your release buildType
Upload to AppTester Health Check — detects debug builds in under 5 seconds
iOS
In Xcode: Product → Archive (not Build or Run). Never use the Run button for production builds.
In the Organizer: Distribute App → App Store Connect → use Release configuration
Check the embedded.mobileprovision in the IPA: should reference Distribution, not Development
Confirm build settings: DEBUG_INFORMATION_FORMAT = dwarf-with-dsym for Release, not debug
Upload to AppTester Health Check — verifies provisioning profile type and build configuration
How to prevent it from happening again
Add a pre-submission checklist to your release process — build verification is step one
Never submit directly from Xcode Run or Android Studio Run button — always use Archive (iOS) or a signed release build task (Android)
In CI/CD pipelines: have separate build jobs for debug and release, with the release job requiring explicit approval before it triggers a submission
Run the AppTester Health Check as the first step in your submission process — it will catch a debug build in seconds before you waste a review slot
Add the debug build check to your team's PR review checklist for any changes to build configuration files
Detect debug builds in 30 seconds
Upload your APK, AAB, or IPA. The Health Check identifies debug builds instantly, along with every other common submission failure.