Crash in Mobile Development: What It Is, Types, and Prevention Methods

What is a Crash

Crash is an abnormal termination of an application caused by an unhandled exception or a fatal system signal that was not handled in the application code. When the system or virtual machine (JVM, ART) detects a fatal condition — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — it immediately stops the process and unloads it from memory. The user sees a sudden app closure without any system error notification. According to Google, apps with a crash-free rate below 99% lose up to 20% of active users per month.

On Android, the crash handling mechanism differs from desktop systems. Instead of a debug dialog with a stack trace, Android simply kills the process without saving detailed information. Collecting crash information is the job of third-party libraries (Crashlytics, Sentry, Bugsnag) that intercept exceptions via Thread.setDefaultUncaughtExceptionHandler before the process is terminated.

iOS uses a similar mechanism with NSException and Mach exceptions to handle fatal errors. When an unhandled exception occurs, the system terminates the application, and the report is saved as a .crash file. Collecting crashes on iOS requires integration with Crashlytics or the built-in report through Xcode Organizer.

Main Types of Crashes

Five categories of crashes cover 90% of all failures in mobile applications. Understanding each type helps diagnose and fix issues in production faster.

NullPointerException — the King of Crashes

NullPointerException (NPE) is the most common crash type in all Java/Kotlin applications. It occurs when trying to call a method or access a field of an object that is null. Typical scenarios: uninitialized Activity field on screen rotation, null response from server during JSON deserialization, careless navigation through RecyclerView adapter.

Kotlin solves the NPE problem at the language level through null-safe types: String? cannot be used without explicit checking. However, Java compatibility and Reflection still create risks. Use @NonNull and @Nullable annotations and enable strictNullChecks in static analysis tools.

fun safeLength(text: String?): Int {
    return text?.length ?: 0 // safe null handling
}

IndexOutOfBoundsException and Collection Errors

IndexOutOfBoundsException occurs when accessing a non-existent index of a list or array. Common scenarios: removing an element from RecyclerView without synchronizing with the adapter, multi-threaded modification of ArrayList without locking, incorrect position calculation in ViewPager. ConcurrentModificationException is a close relative when iterating and modifying collections simultaneously.

Use CopyOnWriteArrayList for multi-threaded access or Lock-free collections from java.util.concurrent. For UI synchronization, use DiffUtil which calculates the difference between old and new lists safely and efficiently.

ClassCastException — Type Problems

ClassCastException occurs when casting an object to an incompatible type. In Android, typical causes: incorrect ViewHolder type in RecyclerView (different cell types without proper getItemViewType), incorrect Fragment casting during navigation, Serializable objects with different class versions.

Use Kotlin's safe-cast via the as? operator, which returns null on type incompatibility. In Java — check via instanceof before casting. For Parcelable objects, always declare CREATOR in each class.

IllegalStateException and Logic Errors

IllegalStateException signals calling a method in an inappropriate object state. A typical Android example — getSupportFragmentManager() after onSaveInstanceState, when commit() of a fragment is not allowed. Another common case — calling dismiss() on an already closed dialog.

Check the lifecycle state before FragmentManager operations. Use commitAllowingStateLoss() only when you are sure that state loss is not critical. In Kotlin, create DSL-like builders that eliminate invalid states at the type level.

Native Crash (SIGSEGV, SIGABRT signals)

Native Crash occurs in native C/C++ code due to memory violations: null pointer dereference, double-free, stack buffer overflow. On Android, such crashes happen in NDK libraries, game engines (Unity, Unreal), and system dependencies. Native Crash is NOT intercepted by Thread.setDefaultUncaughtExceptionHandler — it kills the process instantly.

For diagnosing native crashes, use minidump files (Breakpad) or Android tombstones. Firebase Crashlytics supports native crash collection via the NDK SDK. On iOS, a similar issue is solved using PLCrashReporter.

Crash Reporting Tools

Three tools dominate the mobile crash reporting market. Each provides stack trace collection, aggregation by app version, and notifications of new crashes.

Firebase Crashlytics

Crashlytics is the most popular crash reporter for mobile applications, part of the Firebase ecosystem. It automatically collects stack traces, device information, OS version, and user custom keys. Integration takes 10 minutes through Firebase Console and Gradle Plugin. Crashlytics also supports real-time logs (Logcat) and user tracks.

FirebaseCrashlytics.getInstance()
    .setCustomKey("current_screen", "ProfileFragment")

FirebaseCrashlytics.getInstance()
    .log("User tapped login button")

Sentry

Sentry is an alternative to Crashlytics with a more flexible filtering system and support for 90+ platforms. Unlike Firebase, Sentry provides a self-hosted server for companies with strict data requirements. Sentry supports distribution tracking, breadcrumbs, and CI/CD pipeline integration.

Bugsnag and AppCenter

Bugsnag stands out with support for severity-based alerts: it categorizes crashes into critical, error, and warning. AppCenter from Microsoft is a free tool with basic functionality for small projects. Both support Android, iOS, React Native, and Flutter.

How to Analyze a Crash

Analysis of a crash is the process of reconstructing the full picture of what happened. The stack trace only shows the last point of failure but does not provide the context that led to the problem. A professional approach includes four stages.

The first stage is reading the stack trace. Identify the class, method, and line of code where the exception occurred. Trace the call chain from the top frame to the bottom: the last line in the stack is the crash location, and the upper lines are the sequence of calls. Deobfuscation (ProGuard/R8 mapping) is mandatory for production builds.

The second stage is device context. Crashlytics shows the device model, OS version, available memory, and app version. For example, a crash only on Samsung Galaxy S10 with Android 11 points to a problem with a specific One UI version, not a general code error.

The third stage is reproduction on a test device. If the crash does not reproduce consistently, ask the user for exact steps or use Remote Config for logging before the problematic code section. AB testing of the fix on part of the audience helps confirm the solution.

The fourth stage is post-fix monitoring. After publishing the fix, monitor the crash rate for 3–5 days. If the crash completely disappears — the fix worked. If the frequency decreased but did not go to zero — there is a second scenario requiring separate analysis.

Crash Prevention Practices

A systematic approach to crash prevention includes static analysis tools, mandatory edge case testing, and proper error handling at all levels of the application.

Static Code Analysis

Detekt (Kotlin) and Lint (Android) find potential issues at compile time: unused variables, potential NPEs, incorrect API usage. Include these tools in the CI pipeline with an error threshold. For example, Detekt with a configuration of 30+ warnings or any error-blocking does not pass the build.

Unit Tests and UI Tests

Coverage of key usage scenarios with unit tests is the basic protection against regression crashes. Test data models, ViewModel, and UseCase layers with edge cases: null values, empty lists, invalid JSON. UI tests via Espresso or Compose Test cover critical flows: authentication, payment, onboarding.

Graceful Degradation

Design the application so that a failure in one module does not crash the entire screen. Use catch blocks at the ViewModel level with fallback state: showing a placeholder instead of a list, cached data when offline, a fallback image on load error. This turns a potential crash into a controlled UX scenario.

Phased Rollout with Monitoring

Staged rollouts are a standard practice on Google Play and App Store: a new version is released to 5%, then 20%, then 100% of the audience with 1–3 day intervals. At each stage, the crash rate is monitored: if the crash-free rate falls below 99.5%, the rollout stops automatically. Firebase Remote Config allows disabling problematic features without publishing a new version.

Dependency Version Control

Renovate or Dependabot in CI automatically check libraries for known vulnerabilities and critical bugs. Updating a single dependency can eliminate an entire class of crashes. However, test updates on the staging environment before rolling out to production — a new library version may contain incompatible changes.