Crash Reporting en desarrollo móvil — qué es, servicios y configuración

¿Qué es Crash Reporting?

Crash Reporting es el proceso de recopilación automática de información técnica sobre caídas de la aplicación y su transmisión centralizada al servidor para su análisis. A diferencia del registro, crash-reporting captura específicamente situaciones de emergencia: el momento en que la aplicación fue terminada forzosamente por el sistema o SO.

Cada informe de crash contiene tres componentes clave: tipo de excepción (NullPointerException, SIGSEGV, NSInternalInconsistencyException), pila de llamadas completa con números de línea e información del entorno: versión del SO, modelo del dispositivo, tamaño de memoria libre. Según Sentry Engineering, 2024, la combinación de estos tres elementos permite reproducir y corregir el 85% de los errores críticos.

Los sistemas modernos de crash-reporting amplían su funcionalidad más allá de los crash comunes. Firebase Crashlytics agrupa automáticamente las caídas recurrentes en issues, Sentry rastrea regresiones entre versiones y Bugsnag muestra la ruta del usuario hasta el error. Los tres servicios admiten iOS, Android, React Native y Flutter.

Según Google I/O 2024, las aplicaciones sin crash-reporting tardan en promedio 3–5 días laborables en diagnosticar un solo error crítico, mientras que con Crashlytics toman 15–30 minutos. El ahorro de tiempo supera el 90% por cada incidente.

Cómo funciona el sistema de recopilación de informes de crash

Arquitectura del sistema crash-reporting consta de tres capas: SDK cliente instalado en la aplicación, API de servidor para recibir y procesar informes, y panel web para análisis. El SDK cliente intercepta excepciones no controladas, las serializa en JSON y las envía al servidor en el próximo inicio de la aplicación.

El envío del informe de crash ocurre de forma asíncrona después de reiniciar la aplicación. Este es un punto fundamental: en el momento del crash, la aplicación no puede garantizar el envío exitoso de datos por la red. El SDK escribe el informe en almacenamiento local y, en el próximo inicio, lo envía mediante un hilo en segundo plano. Según Firebase Engineering, 2024, este enfoque garantiza la entrega del 99.7% de los informes de crash.

Para excepciones no fatales (excepciones manejadas dentro de try-catch), el SDK envía el informe inmediatamente ya que la aplicación continúa funcionando. Los informes no fatales contienen los mismos datos que un crash pero no interrumpen la sesión del usuario. Esto es especialmente útil para rastrear errores de solicitudes API, validación de datos y lógica de negocio.

Agrupación de crash — un algoritmo del servidor que fusiona crashes idénticos basándose en un hash de los últimos 5–10 marcos de la pila. Esto permite al desarrollador ver no 1000 informes individuales sino un issue con 1000 ocurrencias en diferentes dispositivos y versiones del SO.

Firebase Crashlytics: integración y capacidades

Firebase Crashlytics es el servicio de crash-reporting más popular para aplicaciones móviles, usado en más de 3 millones de proyectos en todo el mundo. El plan gratuito incluye informes ilimitados, integración con Google Analytics y agrupación automática de crash.

Integración de Crashlytics en Android

Conexión Crashlytics en Android es mínima: agregue la dependencia en build.gradle e inicialice el SDK en Application.onCreate. Crashlytics establece automáticamente su propio Thread.setDefaultUncaughtExceptionHandler, interceptando todas las excepciones no controladas.

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

Capacidad clave de Crashlytics — claves y registros personalizados. El desarrollador puede agregar hasta 64 pares clave-valor a cada informe de crash: estado de la pantalla, plan seleccionado, nivel del usuario. También están disponibles mensajes de registro personalizados que aparecen en el informe en orden cronológico.

Velocity Alert — detección automática de regresiones

Velocity Alert es una función de Crashlytics que monitorea aumentos bruscos en la cantidad de crash para un issue específico. Si después de una nueva versión el número de caídas supera un umbral, el equipo recibe una notificación push y correo electrónico 5–15 minutos antes de las quejas masivas de usuarios.

Configuración del umbral de activación: 2x en 1 hora para issues críticos. Según Google, 2024, los equipos con Velocity Alert activado lanzan versiones hotfix en promedio un 40% más rápido que los equipos que dependen del monitoreo manual del panel.

Integración de Crashlytics en iOS

En iOS el SDK de Crashlytics se integra mediante CocoaPods o Swift Package Manager. El SDK intercepta tanto excepciones de Objective-C (a través de NSSetUncaughtExceptionHandler) como señales del SO (SIGSEGV, SIGABRT) mediante su propio manejador de excepciones mach.

Según Apple Developer, 2024, Crashlytics para iOS maneja hasta el 98% de todos los tipos de caídas, incluidos errores de memoria de bajo nivel que no son detectados por las herramientas estándar. Esto convierte a Crashlytics en el estándar de facto para el desarrollo iOS.

Sentry y Bugsnag: plataformas alternativas

Sentry es una plataforma open-source de monitoreo de errores que admite 80+ lenguajes y frameworks. A diferencia de Crashlytics, Sentry está orientada a desarrolladores backend pero proporciona SDK completos para iOS, Android, React Native y Flutter.

La ventaja clave de Sentry es Performance Monitoring en un solo panel. Los desarrolladores ven no solo los crash sino también las transacciones que llevaron a ellos: solicitudes de red lentas, congelamientos de UI, operaciones largas de base de datos. Según Sentry, 2024, el 40% de los crash tienen problemas de rendimiento precedentes que pasan desapercibidos sin este enfoque.

Bugsnag se diferencia en su enfoque de agrupación de errores — en lugar de la pila de llamadas, analiza el recorrido del usuario (user journey). Cada informe de crash contiene la secuencia de pantallas y acciones del usuario que llevaron al error. Esto es especialmente útil para procesos de negocio complejos: realización de pedidos, registro, pago.

Los costos de los servicios varían: Crashlytics es gratuito dentro de Firebase, Sentry ofrece un plan gratuito para 5000 eventos por mes, Bugsnag desde $29 por mes. Las tres plataformas proporcionan SDK de código abierto. La elección del servicio depende del tamaño del equipo, presupuesto y requisitos de seguridad de datos.

Crash Reporting en iOS: características y NSException

Particularidad de iOS — arquitectura multicapa de manejo de errores. Los SDK de crash-reporting deben interceptar excepciones de Objective-C (NSException), errores de Swift (Error), señales POSIX (SIGSEGV, SIGBUS) y excepciones mach. Cada tipo requiere un mecanismo de intercepción separado.

NSException es el tipo más simple de interceptar mediante NSSetUncaughtExceptionHandler. Sin embargo, según Apple, 2024, solo el 30% de los crash en aplicaciones Swift modernas son NSException. El 70% restante son señales del SO y errores de runtime de Swift, que requieren un mecanismo de manejador de excepciones mach.

Los desarrolladores de iOS deben probar crash-reporting mediante generación local de crash de diferentes tipos: __builtin_trap() para señales, [NSException raise:...] para excepciones, fatalError() para Swift. Solo así se puede asegurar que el SDK cubre todos los tipos de caídas.

Crash Reporting en Android: ANR y crashes nativos

Android agrega dos tipos específicos de caídas que no existen en iOS: ANR (Application Not Responding) y crash nativo en código C/C++. ANR ocurre cuando el hilo de UI está bloqueado por más de 5 segundos — el sistema muestra un diálogo "La aplicación no responde" y sugiere cerrarla.

Thread.setDefaultUncaughtExceptionHandler estándar no intercepta ANR, ya que no es una excepción sino una señal de ActivityManager. Para rastrear ANR, Crashlytics y Sentry usan un hilo watchdog en segundo plano que verifica la capacidad de respuesta del hilo de UI cada 5 segundos. Según Firebase, 2024, el 15% de todos los problemas en Android son ANR, no crash.

Crash nativo en Android ocurre en código C/C++ ejecutado mediante JNI (Java Native Interface). Estas caídas no son excepciones de Java y no son interceptadas por Thread.setDefaultUncaughtExceptionHandler. Para su manejo se utilizan Google Breakpad o Crashpad, que instalan manejadores sigaction para las señales SIGSEGV, SIGABRT, SIGBUS.

Según Google I/O 2024, la cantidad de crash nativos crece con la propagación de motores de juegos (Unity, Unreal Engine) y bibliotecas de visión por computadora (ML Kit, OpenCV). Se recomienda a los desarrolladores de aplicaciones híbridas conectar siempre crash-reporting nativo.