Crash Reporting in Mobile Development — What It Is, Services and Setup

What is Crash Reporting?

Crash Reporting is the process of automatically collecting technical information about app crashes and centrally transmitting it to a server for analysis. Unlike logging, crash-reporting specifically captures emergency situations — the moment when the app was forcibly terminated by the system or OS.

Each crash report contains three key components: exception type (NullPointerException, SIGSEGV, NSInternalInconsistencyException), full call stack with line numbers, and environment information — OS version, device model, available memory size. According to Sentry Engineering, 2024, the combination of these three elements allows reproducing and fixing 85% of critical errors.

Modern crash-reporting systems extend functionality beyond regular crashes. Firebase Crashlytics automatically groups recurring crashes into issues, Sentry tracks regressions between releases, and Bugsnag shows the user path to the error. All three services support iOS, Android, React Native and Flutter.

According to Google I/O 2024, apps without crash-reporting spend an average of 3–5 working days diagnosing a single critical error, while with Crashlytics it takes 15–30 minutes. The time savings exceed 90% for each incident.

How the Crash Report Collection System Works

Architecture of a crash-reporting system consists of three layers: a client SDK installed in the app, a server API for receiving and processing reports, and a web dashboard for analysis. The client SDK intercepts unhandled exceptions, serializes them into JSON and sends them to the server on the next app launch.

Crash report submission occurs asynchronously after app restart. This is a fundamental point: at the moment of crash, the app cannot guarantee successful data transmission over the network. The SDK writes the report to local storage, and on the next launch sends it via a background thread. According to Firebase Engineering, 2024, this approach ensures delivery of 99.7% of crash reports.

For non-fatal exceptions (handled exceptions inside try-catch), the SDK sends the report immediately since the app continues working. Non-fatal reports contain the same data as crashes but do not interrupt the user session. This is especially useful for tracking API request errors, data validation and business logic.

Crash grouping — a server algorithm that merges identical crashes based on a hash of the last 5–10 stack frames. This allows developers to see not 1000 individual reports but one issue with 1000 occurrences across different devices and OS versions.

Firebase Crashlytics: Integration and Features

Firebase Crashlytics is the most popular crash-reporting service for mobile apps, used in over 3 million projects worldwide. The free tier includes unlimited reports, Google Analytics integration and automatic crash grouping.

Crashlytics Integration on Android

Setup Crashlytics on Android is minimal: add the dependency in build.gradle and initialize the SDK in Application.onCreate. Crashlytics automatically sets its own Thread.setDefaultUncaughtExceptionHandler, intercepting all unhandled exceptions.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

Key feature of Crashlytics — custom keys and logs. Developers can add up to 64 key-value pairs to each crash report: screen state, selected plan, user level. Custom log messages are also available, which appear in the report in chronological order.

Velocity Alert — Automatic Regression Detection

Velocity Alert is a Crashlytics feature that monitors sharp increases in crash count for a specific issue. If after a new release the crash count exceeds a threshold, the team receives a push notification and email 5–15 minutes before mass user complaints.

Alert threshold settings: 2x in 1 hour for critical issues. According to Google, 2024, teams with Velocity Alert enabled release hotfixes on average 40% faster than teams relying on manual dashboard monitoring.

Crashlytics Integration on iOS

On iOS Crashlytics SDK integrates via CocoaPods or Swift Package Manager. The SDK intercepts both Objective-C exceptions (via NSSetUncaughtExceptionHandler) and OS signals (SIGSEGV, SIGABRT) through its own mach exception handler.

According to Apple Developer, 2024, Crashlytics for iOS handles up to 98% of all crash types, including low-level memory errors that are not caught by standard tools. This makes Crashlytics the de facto standard for iOS development.

Sentry and Bugsnag: Alternative Platforms

Sentry is an open-source error monitoring platform supporting 80+ languages and frameworks. Unlike Crashlytics, Sentry targets backend developers but provides full-featured SDKs for iOS, Android, React Native and Flutter.

Sentry's key advantage is Performance Monitoring in a single dashboard. Developers see not only crashes but also the transactions that led to them: slow network requests, UI freezes, long database operations. According to Sentry, 2024, 40% of crashes have preceding performance issues that remain unnoticed without this approach.

Bugsnag differs in its error grouping approach — instead of a call stack, it analyzes the user journey. Each crash report contains the sequence of screens and user actions that led to the error. This is especially useful for complex business processes: order placement, registration, payment.

Service costs vary: Crashlytics is free within Firebase, Sentry offers a free tier for 5000 events per month, Bugsnag starts at $29 per month. All three platforms provide open-source SDKs. The choice of service depends on team size, budget and data security requirements.

Crash Reporting on iOS: Features and NSException

iOS specifics — a multi-layered error handling architecture. Crash-reporting SDKs must intercept Objective-C exceptions (NSException), Swift errors (Error), POSIX signals (SIGSEGV, SIGBUS) and mach exceptions. Each type requires a separate interception mechanism.

NSException is the simplest type to intercept via NSSetUncaughtExceptionHandler. However, according to Apple, 2024, only 30% of crashes in modern Swift apps are NSException. The remaining 70% are OS signals and Swift runtime errors, which require a mach exception handler mechanism.

iOS developers should test crash-reporting through local crash generation of different types: __builtin_trap() for signals, [NSException raise:...] for exceptions, fatalError() for Swift. This is the only way to ensure the SDK covers all crash types.

Crash Reporting on Android: ANR and Native Crashes

Android adds two specific crash types not present on iOS: ANR (Application Not Responding) and native crash in C/C++ code. ANR occurs when the UI thread is blocked for more than 5 seconds — the system shows an "App Not Responding" dialog and suggests closing it.

The standard Thread.setDefaultUncaughtExceptionHandler does not intercept ANR, since it is not an exception but a signal from ActivityManager. To track ANR, Crashlytics and Sentry use a background watchdog thread that checks UI thread responsiveness every 5 seconds. According to Firebase, 2024, 15% of all Android issues are ANR, not crashes.

Native crashes on Android occur in C/C++ code running through JNI (Java Native Interface). These crashes are not Java exceptions and are not caught by Thread.setDefaultUncaughtExceptionHandler. They are handled using Google Breakpad or Crashpad, which install sigaction handlers for SIGSEGV, SIGABRT, SIGBUS signals.

According to Google I/O 2024, the number of native crashes is growing with the spread of game engines (Unity, Unreal Engine) and computer vision libraries (ML Kit, OpenCV). Hybrid app developers are recommended to always enable native crash-reporting.