App Crashes on Launch: Causes and Fixes (2026)

An app that crashes on launch is worse than an app with no features — users uninstall immediately. Crash-on-launch is also one of the most-commonly-caused-by-dumb-things classes of bug, usually a miss

An app that crashes on launch is worse than an app with no features — users uninstall immediately. Crash-on-launch is also one of the most-commonly-caused-by-dumb-things classes of bug, usually a missing file, an unhandled migration, or a permission assumption that broke on a new OS version. This guide covers diagnosis and fix patterns.

Common causes

1. Database migration fails

Your app upgraded. The new version expects schema version N+1. Users upgrading from an old version have schema at N-3. Migration path not handled. Crash on DB open.

Fix: Every DB migration tested on every supported upgrade path. Room / Core Data / SQLDelight support multi-version migrations — use them.

2. Required permission missing

Your code assumes permission X is granted (e.g., notification, storage, location). User denied it. App crashes dereferencing null.

Fix: Check permission before use. Degrade gracefully.

3. Missing resource / asset

R.drawable.some_icon referenced in code but removed from res/drawable/. Works in dev build; crashes on release where R-file regeneration differs or minification strips.

Fix: Keep references tight. Use ProGuard / R8 keep rules for runtime-resolved resources.

4. Network / config required at launch

SplashActivity fetches remote config before proceeding. Server down → timeout → crash. Or server returns malformed response → parse error → crash.

Fix: Remote config must have on-device defaults and graceful timeout.

5. SDK init failure

Firebase / Crashlytics / Segment / etc. init fails because of missing plist / JSON / network. Crash in App.onCreate because no try/catch.

Fix: Wrap every SDK init in try/catch. Log failures; continue.

6. Native library (JNI) load failure

Native library missing for the device's ABI (armeabi-v7a present, arm64 missing). Class loader crashes.

Fix: Build and ship all required ABIs. App Bundle (AAB) delivers per-device.

7. OS API not available on installed version

Code uses API 33-only feature on Android 11. Runtime NoSuchMethodError.

Fix: if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) guards. minSdk in build.gradle reflects actual support.

8. Memory at launch

Large bitmap loaded synchronously at launch. OOM on low-memory devices.

Fix: Lazy-load heavy resources. Scale bitmaps to display dimensions.

9. Keystore / keychain corruption

Biometric-bound key unreadable on boot (device reboot invalidates certain keys). Crash when trying to decrypt user session.

Fix: Catch the key-not-found exception, prompt for re-authentication.

10. Third-party SDK updates with breaking changes

Ad SDK updated auto; new version requires init parameter you did not provide.

Fix: Pin SDK versions. Update deliberately, test fully.

Diagnosis

On device

• adb logcat *:E on Android for stack traces
• Xcode Organizer → Crashes (after symbolication)

From field

• Crashlytics / Sentry / Bugsnag captures stacks, filter by version, filter by OS
• "New in this release" filter to find regression

Reproduce

• Fresh install on target device/OS
• Fresh install with pre-populated state (SQLite file from failing user if possible)
• Airplane mode launch (catches network-at-launch assumptions)

Fix patterns

• Early return on failed init: if (databaseInit() fails) { show error screen, don't proceed }
• Guarded splash: proceed to main UI after N seconds regardless of background work
• Crash handler at top level: send to Crashlytics; show "Something went wrong" screen instead of force-close

Prevention

• CI smoke test: launch app on clean emulator every PR
• Upgrade-path test: install old version, upgrade to new, launch
• Airplane-mode launch test
• Fresh install on each supported minSdk

How SUSA catches these

SUSA's cold-start run is a first-class feature: installs clean, launches, measures startup time + any crash. If the app crashes before the first step, the exploration reports a "launch failure" — no further steps run, but the crash is captured with logcat context.

susatest-agent test myapp.apk --persona impatient --steps 30

Upgrade testing: pass the old APK first to install, then swap:

susatest-agent test --install-first old.apk --upgrade-to new.apk

Most common pattern

Across 100+ launch crashes I have seen in the wild: by far the most common is an SDK that was auto-updated, introduced a breaking change, and fails init without a try/catch. Second most common is a database migration that worked fine for recent upgrades but fails on the long tail. Third is missing ABI on Android.

Crash on launch is solvable in one day. Crash rate drops from 5%+ to <0.5% with focused cleanup of SDK inits, migration tests, and permission guards.