App Crash: What It Is, Causes of Crashes and Detection Methods

What Is an App Crash

Crash — an unexpected program termination caused by an exceptional situation that the code did not handle. In mobile OSes, a crash leads to an immediate app closure and shows a “App stopped” screen or returns to the home screen.

Crashes are divided into two broad classes. Handled errors — try/catch blocks catch the exception, the app continues running, possibly with some loss of functionality. Unhandled crashes — the exception propagates up to the OS level, and the system kills the process. The second type is especially dangerous because the user cannot save data.

A system with two million users and a 0.1% crash rate loses 2,000 users on each release. According to Google Play Console (2024), apps with a crash rate above 1.5% are excluded from recommendations and lose up to 30% of organic traffic.

Main Causes of Crashes in Mobile Apps

NullPointerException (NPE) — the king of crashes in Java/Kotlin. Attempting to call a method on a null object. In Kotlin, NPE is less common thanks to null safety, but it is still possible when using the !! operator or interacting with Java code. Google (2024) estimates that NPE accounts for 25% of all Android app crashes.

IndexOutOfBoundsException — accessing a list element at a non-existent index. A common cause: data arrives from the server in an unexpected format, and the UI tries to display a position that does not exist. Solution — always check the collection size before accessing by index.

ANR (Application Not Responding) — an Android-specific problem. The UI thread is blocked for more than 5 seconds. Main causes: network requests on the main thread, heavy computations, database synchronization. StrictMode in Android helps detect UI thread blocking during development.

OutOfMemoryError (OOM) — the app exceeded its memory limit. On mobile devices with 2–4 GB RAM, OOM is a common issue when working with large images or infinite lists without pagination. Solution — Glide/Coil for image loading, LruCache for caching, ViewHolder in RecyclerView.

Runtime Exceptions and Fatal Errors

Runtime exceptions — errors that the compiler does not check at build time. They only appear when the code runs on a specific device with specific data. In Java, these are RuntimeException and its subclasses: NullPointerException, IllegalArgumentException, ArithmeticException.

Fatal errors (FATAL) — not runtime, but system failures. Signal 11 (SIGSEGV) — memory segmentation violation in native code. Signal 6 (SIGABRT) — abnormal termination triggered by the app itself via abort(). Such crashes are difficult to diagnose because the stack trace often does not show a clear context.

In iOS, the main causes are NSInvalidArgumentException (unexpected nil in a parameter) and EXC_BAD_ACCESS (access to deallocated memory). Swift has reduced the number of crashes compared to Objective-C, but errors in the ObjC runtime and C libraries still lead to crashes.

Crash Monitoring and Log Collection

Firebase Crashlytics — the standard for mobile apps. It automatically collects stack traces, adds logs, user IDs and device metadata. It groups crashes by signature (error class + line). Real-time alerts — notifications when the crash rate exceeds a set threshold (e.g., >0.1% per hour).

Sentry — an alternative with more flexible capabilities. It allows creating custom contexts, adding breadcrumbs (preceding events), configuring in-app filtering to exclude unimportant errors. Source maps for Kotlin and Swift let you see the source code rather than obfuscated names.

Best practices for logs: send key metadata before performing a dangerous operation — this way the log will show what the user was doing before the crash. Add custom keys (API version number, last screen, input data size). This turns a useless stack trace into actionable information.

Example: Setting up Crashlytics in Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Crash Prevention Strategies

Optional binding and null safety — in Kotlin use `?` for nullable types, `let` and `?:` for safe null handling. In Swift — optionals and guard let. Modern Kotlin (2024) added Contract annotations: `@ContractsDsl` allows declaring that a function does not return null, and the compiler checks it.

Error handling in networking — every network request must handle timeout, parsing errors, and server failures. Retrofit with Result type — a sealed class that guarantees the error will be handled. No Exception style: instead of try/catch, use sealed Result for explicit success and error handling.

Feature flags — disable problematic functionality remotely without releasing a new version. If a server-side operation causes a crash on older devices, the flag disables it for that group. Firebase Remote Config allows changing app behavior without publishing to the store.

Gradual rollout — release a new version to 5% of the audience and monitor the crash rate. If the rate stays below the target (usually <0.1%), expand to 25%, then 50%, then 100%. Google Play Console and App Store Connect support staged rollouts for automatic rollback when the threshold is exceeded.

Incident Response Plan

Step 1: Classification — determine severity: Critical (crash in >1% of users), High (0.1–1%), Medium (<0.1%). For Critical crashes — immediate response. For others — standard bugfix process in the current sprint. Google Play Console automatically classifies crashes by the number of affected users.

Step 2: Stack trace analysis — open the log in Crashlytics, check the exact crash location. Review custom keys: which screen, what data, OS version. Correlate with the latest deployment — often a crash is caused by a recent code change that affected an unexpected usage scenario.

Step 3: Reproduction — try to reproduce the crash on a device or emulator with similar parameters. If unsuccessful, check the crash log for patterns: specific models (Samsung A10), Android versions (API < 26), locales. Solution — add a defensive condition that covers the scenario.

Step 4: Fix and monitoring — release a hotfix with priority. After the release, ensure the crash rate for this type drops to zero. Write a regression test that covers the crash scenario. Without a test, the same bug may return in the next refactoring.