Crash Reporting in mobiele ontwikkeling — wat het is, diensten en configuratie

Wat is Crash Reporting?

Crash Reporting — is het proces van automatisch verzamelen van technische informatie over applicatiecrashes en deze gecentraliseerd naar een server sturen voor analyse. In tegenstelling tot loggen, registreert crash-reporting juist de noodsituaties — het moment waarop de applicatie geforceerd werd beëindigd door het systeem of besturingssysteem.

Elk crashrapport bevat drie belangrijke componenten: het type uitzondering (NullPointerException, SIGSEGV, NSInternalInconsistencyException), een volledige call stack met regelnummers en informatie over de omgeving — OS-versie, apparaatmodel, hoeveelheid vrij geheugen. Volgens Sentry Engineering, 2024 stelt de combinatie van deze drie elementen in staat om 85% van de kritieke fouten te reproduceren en te verhelpen.

Moderne crash-reportingsystemen breiden de functionaliteit uit tot buiten gewone crashes. Firebase Crashlytics groepeert herhaalde crashes automatisch in issues, Sentry volgt regressies tussen releases, en Bugsnag toont het gebruikerspad naar de fout. Alle drie de diensten ondersteunen iOS, Android, React Native en Flutter.

Volgens Google I/O 2024 besteden applicaties zonder crash-reporting gemiddeld 3–5 werkdagen aan het diagnosticeren van één kritieke fout, terwijl dit met Crashlytics 15–30 minuten is. De tijdswinst bedraagt meer dan 90% voor elk incident.

Hoe werkt het crashrapportagesysteem

De architectuur van een crash-reportingsysteem bestaat uit drie lagen: de client-SDK geïnstalleerd in de app, de server-API voor het ontvangen en verwerken van rapporten, en een webdashboard voor analyse. De client-SDK vangt onverwerkte uitzonderingen op, serialiseert ze naar JSON en stuurt ze naar de server bij de volgende start van de applicatie.

Het verzenden van een crashrapport gebeurt asynchroon na het herstarten van de applicatie. Dit is een cruciaal punt: op het moment van de crash kan de applicatie niet garanderen dat gegevens succesvol via het netwerk worden verzonden. De SDK slaat het rapport op in lokale opslag en stuurt het bij de volgende start op de achtergrond. Volgens Firebase Engineering, 2024 zorgt deze aanpak voor levering van 99.7% van de crashrapporten.

Voor non-fatal uitzonderingen (handled exceptions binnen try-catch) verzendt de SDK het rapport onmiddellijk, omdat de applicatie blijft werken. Non-fatal rapporten bevatten dezelfde gegevens als crashes, maar onderbreken de gebruikerssessie niet. Dit is vooral handig voor het volgen van API-fouten, gegevensvalidatie en bedrijfslogica.

Crash groeperen — een serveralgoritme dat identieke crashes combineert op basis van een hash van de laatste 5–10 stackframes. Hierdoor ziet de ontwikkelaar niet 1000 individuele rapporten, maar één issue met 1000 voorkomens, verspreid over verschillende apparaten en OS-versies.

Firebase Crashlytics: integratie en mogelijkheden

Firebase Crashlytics — de populairste crash-reportingdienst voor mobiele applicaties, gebruikt in meer dan 3 miljoen projecten wereldwijd. Het gratis abonnement omvat onbeperkt aantal rapporten, integratie met Google Analytics en automatische crashgroepering.

Crashlytics integreren op Android

Aansluiten van Crashlytics op Android is minimaal: voeg een afhankelijkheid toe in build.gradle en initialiseer de SDK in Application.onCreate. Crashlytics stelt automatisch een eigen Thread.setDefaultUncaughtExceptionHandler in en vangt alle onverwerkte uitzonderingen op.

// 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)
    }
}

Belangrijke functionaliteit van Crashlytics — custom keys en logs. Ontwikkelaars kunnen tot 64 sleutel-waardeparen toevoegen aan elk crashrapport: schermstatus, geselecteerd abonnement, gebruikersniveau. Ook is het mogelijk om custom logberichten op te nemen die in chronologische volgorde in het rapport verschijnen.

Velocity Alert — automatische regressiedetectie

Velocity Alert — een Crashlytics-functie die een plotselinge toename van crashes voor een specifiek issue volgt. Als na een nieuwe release het aantal crashes de drempelwaarde overschrijdt, ontvangt het team pushmeldingen en e-mail 5–15 minuten voordat massale gebruikersklachten binnenkomen.

De drempel instellen: 2x in 1 uur voor kritieke issues. Volgens Google, 2024 brengen teams met Velocity Alert ingeschakeld hotfix-releases gemiddeld 40% sneller uit dan teams die vertrouwen op handmatige dashboardmonitoring.

Crashlytics integreren op iOS

Op iOS wordt de Crashlytics SDK geïntegreerd via CocoaPods of Swift Package Manager. De SDK vangt zowel Objective-C-uitzonderingen (via NSSetUncaughtExceptionHandler) als OS-signalen (SIGSEGV, SIGABRT) op via een eigen mach exception handler.

Volgens Apple Developer, 2024 verwerkt Crashlytics voor iOS tot 98% van alle crashtypen, inclusief laaggeheugenfouten die niet door standaardmechanismen worden opgevangen. Dit maakt Crashlytics de facto standaard voor iOS-ontwikkeling.

Sentry en Bugsnag: alternatieve platformen

Sentry — een open-source foutmonitoringsplatform dat 80+ talen en frameworks ondersteunt. In tegenstelling tot Crashlytics is Sentry gericht op backend-ontwikkelaars, maar biedt het volledige SDK’s voor iOS, Android, React Native en Flutter.

Het belangrijkste voordeel van Sentry — Performance Monitoring in één dashboard. Ontwikkelaars zien niet alleen crashes, maar ook de transacties die ertoe leidden: trage netwerkverzoeken, UI-bevriezingen, langdurige databasebewerkingen. Volgens Sentry, 2024 heeft 40% van de crashes voorafgaande prestatieproblemen die onopgemerkt blijven zonder een dergelijke aanpak.

Bugsnag onderscheidt zich door zijn benadering van foutgroepering — in plaats van de call stack analyseert het gebruikerspad (user journey). Elk crashrapport bevat een reeks schermen en acties van de gebruiker die tot de fout hebben geleid. Dit is vooral nuttig voor complexe bedrijfsprocessen: bestellen, registreren, betalen.

De kosten van de diensten variëren: Crashlytics is gratis binnen Firebase, Sentry biedt een gratis abonnement voor 5000 gebeurtenissen per maand, Bugsnag vanaf $29 per maand. Alle drie de platformen bieden SDK’s met open source. De keuze hangt af van teamgrootte, budget en gegevensbeveiligingseisen.

Crash Reporting op iOS: kenmerken en NSException

Kenmerk van iOS — een gelaagde architectuur voor foutafhandeling. Crash-reporting SDK’s moeten Objective-C-uitzonderingen (NSException), Swift-fouten (Error), POSIX-signalen (SIGSEGV, SIGBUS) en mach-uitzonderingen opvangen. Elk type vereist een apart opvangmechanisme.

NSException — het eenvoudigste type om op te vangen via NSSetUncaughtExceptionHandler. Volgens Apple, 2024 is echter slechts 30% van de crashes in moderne Swift-applicaties NSException. De overige 70% zijn OS-signalen en Swift runtime-fouten waarvoor het mechanisme van een mach exception handler nodig is.

iOS-ontwikkelaars moeten crash-reporting testen door lokale crashgeneratie van verschillende typen: __builtin_trap() voor signalen, [NSException raise:...] voor uitzonderingen, fatalError() voor Swift. Alleen zo kan worden gecontroleerd of de SDK alle crashtypen dekt.

Crash Reporting op Android: ANR en native crashes

Android voegt twee specifieke crashtypen toe die niet bestaan op iOS: ANR (Application Not Responding) en native crash in C/C++-code. ANR treedt op wanneer de UI-thread langer dan 5 seconden is geblokkeerd — het systeem toont een dialoogvenster “App reageert niet” en biedt aan deze te sluiten.

Standaard Thread.setDefaultUncaughtExceptionHandler vangt ANR niet op, omdat het geen uitzondering is, maar een signaal van ActivityManager. Voor het volgen van ANR gebruiken Crashlytics en Sentry een achtergrond-watchdog-thread die elke 5 seconden de responsiviteit van de UI-thread controleert. Volgens Firebase, 2024 is 15% van alle problemen op Android ANR, geen crash.

Native crash op Android treden op in C/C++-code die via JNI (Java Native Interface) wordt uitgevoerd. Deze crashes zijn geen Java-uitzonderingen en worden niet opgevangen door Thread.setDefaultUncaughtExceptionHandler. Voor de verwerking ervan worden Google Breakpad of Crashpad gebruikt, die sigaction-handlers installeren voor signalen SIGSEGV, SIGABRT, SIGBUS.

Volgens Google I/O 2024 neemt het aantal native crashes toe met de verspreiding van game-engines (Unity, Unreal Engine) en computer vision-bibliotheken (ML Kit, OpenCV). Ontwikkelaars van hybride applicaties wordt geadviseerd altijd native crash-reporting aan te sluiten.