Crash Reporting nello sviluppo mobile — cos'è, servizi e configurazione

Cos'è il Crash Reporting?

Il Crash Reporting è il processo di raccolta automatica delle informazioni tecniche sui crash dell'app e la loro trasmissione centralizzata al server per l'analisi. A differenza della registrazione, il crash-reporting cattura specificamente le situazioni di emergenza — il momento in cui l'app è stata terminata forzatamente dal sistema o dal sistema operativo.

Ogni rapporto di crash contiene tre componenti chiave: tipo di eccezione (NullPointerException, SIGSEGV, NSInternalInconsistencyException), stack di chiamate completo con numeri di riga e informazioni sull'ambiente — versione del sistema operativo, modello del dispositivo, dimensione della memoria libera. Secondo Sentry Engineering, 2024, la combinazione di questi tre elementi consente di riprodurre e correggere l'85% degli errori critici.

I moderni sistemi di crash-reporting estendono le funzionalità oltre i crash ordinari. Firebase Crashlytics raggruppa automaticamente i crash ricorrenti in issue, Sentry traccia le regressioni tra le versioni e Bugsnag mostra il percorso dell'utente verso l'errore. Tutti e tre i servizi supportano iOS, Android, React Native e Flutter.

Secondo Google I/O 2024, le app senza crash-reporting impiegano in media 3–5 giorni lavorativi per diagnosticare un singolo errore critico, mentre con Crashlytics ci vogliono 15–30 minuti. Il risparmio di tempo supera il 90% per ogni incidente.

Come funziona il sistema di raccolta dei rapporti di crash

Architettura del sistema di crash-reporting si compone di tre livelli: SDK client installato nell'app, API server per ricevere ed elaborare i rapporti e dashboard web per l'analisi. L'SDK client intercetta le eccezioni non gestite, le serializza in JSON e le invia al server al successivo avvio dell'app.

L'invio del rapporto di crash avviene in modo asincrono dopo il riavvio dell'app. Questo è un punto fondamentale: al momento del crash, l'app non può garantire la trasmissione riuscita dei dati sulla rete. L'SDK scrive il rapporto nell'archivio locale e, al successivo avvio, lo invia tramite un thread in background. Secondo Firebase Engineering, 2024, questo approccio garantisce la consegna del 99,7% dei rapporti di crash.

Per le eccezioni non fatali (eccezioni gestite all'interno di try-catch), l'SDK invia il rapporto immediatamente poiché l'app continua a funzionare. I rapporti non fatali contengono gli stessi dati di un crash ma non interrompono la sessione utente. Ciò è particolarmente utile per tracciare errori di richieste API, validazione dei dati e logica di business.

Raggruppamento dei crash — un algoritmo server che unisce crash identici basandosi su un hash degli ultimi 5–10 frame dello stack. Ciò consente allo sviluppatore di vedere non 1000 rapporti individuali ma un issue con 1000 occorrenze su diversi dispositivi e versioni del sistema operativo.

Firebase Crashlytics: integrazione e funzionalità

Firebase Crashlytics è il servizio di crash-reporting più popolare per le app mobili, utilizzato in oltre 3 milioni di progetti in tutto il mondo. Il piano gratuito include rapporti illimitati, integrazione con Google Analytics e raggruppamento automatico dei crash.

Integrazione di Crashlytics su Android

Configurazione Crashlytics su Android è minima: aggiungi la dipendenza in build.gradle e inizializza l'SDK in Application.onCreate. Crashlytics imposta automaticamente il proprio Thread.setDefaultUncaughtExceptionHandler, intercettando tutte le eccezioni non gestite.

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

Funzionalità chiave di Crashlytics — chiavi e log personalizzati. Lo sviluppatore può aggiungere fino a 64 coppie chiave-valore a ogni rapporto di crash: stato dello schermo, piano selezionato, livello utente. Sono disponibili anche messaggi di log personalizzati che appaiono nel rapporto in ordine cronologico.

Velocity Alert — rilevamento automatico delle regressioni

Velocity Alert è una funzionalità di Crashlytics che monitora gli aumenti improvvisi del numero di crash per un issue specifico. Se dopo una nuova versione il numero di crash supera una soglia, il team riceve una notifica push ed email 5–15 minuti prima delle lamentele di massa degli utenti.

Impostazione della soglia di attivazione: 2x in 1 ora per issue critici. Secondo Google, 2024, i team con Velocity Alert attivato rilasciano versioni hotfix in media 40% più velocemente rispetto ai team che si affidano al monitoraggio manuale della dashboard.

Integrazione di Crashlytics su iOS

Su iOS l'SDK di Crashlytics si integra tramite CocoaPods o Swift Package Manager. L'SDK intercetta sia le eccezioni Objective-C (tramite NSSetUncaughtExceptionHandler) che i segnali del sistema operativo (SIGSEGV, SIGABRT) attraverso il proprio gestore di eccezioni mach.

Secondo Apple Developer, 2024, Crashlytics per iOS gestisce fino al 98% di tutti i tipi di crash, inclusi errori di memoria di basso livello che non vengono rilevati dagli strumenti standard. Questo rende Crashlytics lo standard de facto per lo sviluppo iOS.

Sentry e Bugsnag: piattaforme alternative

Sentry è una piattaforma open-source di monitoraggio degli errori che supporta 80+ linguaggi e framework. A differenza di Crashlytics, Sentry è orientato agli sviluppatori backend ma fornisce SDK completi per iOS, Android, React Native e Flutter.

Il vantaggio principale di Sentry è il Performance Monitoring in un'unica dashboard. Gli sviluppatori vedono non solo i crash ma anche le transazioni che li hanno causati: richieste di rete lente, blocchi dell'interfaccia utente, operazioni lunghe sul database. Secondo Sentry, 2024, il 40% dei crash ha problemi di prestazioni precedenti che rimangono inosservati senza questo approccio.

Bugsnag si differenzia nel suo approccio al raggruppamento degli errori — invece dello stack di chiamate, analizza il percorso dell'utente (user journey). Ogni rapporto di crash contiene la sequenza di schermate e azioni dell'utente che hanno portato all'errore. Ciò è particolarmente utile per processi aziendali complessi: evasione ordini, registrazione, pagamento.

I costi dei servizi variano: Crashlytics è gratuito all'interno di Firebase, Sentry offre un piano gratuito per 5000 eventi al mese, Bugsnag a partire da $29 al mese. Tutte e tre le piattaforme forniscono SDK open-source. La scelta del servizio dipende dalle dimensioni del team, dal budget e dai requisiti di sicurezza dei dati.

Crash Reporting su iOS: caratteristiche e NSException

Particolarità di iOS — un'architettura di gestione degli errori a più livelli. Gli SDK di crash-reporting devono intercettare le eccezioni Objective-C (NSException), gli errori Swift (Error), i segnali POSIX (SIGSEGV, SIGBUS) e le eccezioni mach. Ogni tipo richiede un meccanismo di intercettazione separato.

NSException è il tipo più semplice da intercettare tramite NSSetUncaughtExceptionHandler. Tuttavia, secondo Apple, 2024, solo il 30% dei crash nelle moderne app Swift sono NSException. Il restante 70% sono segnali del sistema operativo ed errori di runtime di Swift, che richiedono un meccanismo di gestore di eccezioni mach.

Gli sviluppatori iOS dovrebbero testare il crash-reporting attraverso la generazione locale di crash di diversi tipi: __builtin_trap() per i segnali, [NSException raise:...] per le eccezioni, fatalError() per Swift. Solo così si può garantire che l'SDK copra tutti i tipi di crash.

Crash Reporting su Android: ANR e crash nativi

Android aggiunge due tipi specifici di crash che non esistono su iOS: ANR (Application Not Responding) e crash nativo in codice C/C++. L'ANR si verifica quando il thread dell'interfaccia utente è bloccato per più di 5 secondi — il sistema mostra un dialogo "L'applicazione non risponde" e suggerisce di chiuderla.

Il Thread.setDefaultUncaughtExceptionHandler standard non intercetta l'ANR, poiché non è un'eccezione ma un segnale da ActivityManager. Per tracciare l'ANR, Crashlytics e Sentry utilizzano un thread watchdog in background che controlla la reattività del thread UI ogni 5 secondi. Secondo Firebase, 2024, il 15% di tutti i problemi su Android sono ANR, non crash.

I crash nativi su Android si verificano in codice C/C++ eseguito tramite JNI (Java Native Interface). Questi crash non sono eccezioni Java e non vengono intercettati da Thread.setDefaultUncaughtExceptionHandler. Per gestirli si utilizzano Google Breakpad o Crashpad, che installano gestori sigaction per i segnali SIGSEGV, SIGABRT, SIGBUS.

Secondo Google I/O 2024, il numero di crash nativi è in crescita con la diffusione di motori di gioco (Unity, Unreal Engine) e librerie di visione artificiale (ML Kit, OpenCV). Si raccomanda agli sviluppatori di app ibride di abilitare sempre il crash-reporting nativo.