Actualiza al SDK de Firebase Crashlytics

Ahora puedes configurar Crashlytics en tu app con el nuevo SDK oficial de Firebase Crashlytics, que ofrece API mejoradas que son más coherentes con otros productos de Firebase y más intuitivas de usar. En esta guías se describe cómo actualizar al nuevo SDK de Crashlytics de Fabric. También se describen los cambios que traen las nuevas API, el motivo de los cambios y cómo actualizar tu código, si es necesario.

Si migraste tu app desde Fabric recientemente, revisa cómo la actualización al SDK de Firebase Crashlytics afecta tus datos de estadísticas de fallas.

Paso 1: Agrega un archivo de configuración de Firebase

  1. Abre la Configuración del proyecto. En la tarjeta Tus apps, selecciona el ID del paquete de la app cuyo archivo de configuración necesitas.
  2. Haz clic en Descargar GoogleService-Info.plist a fin de obtener el archivo de configuración de Firebase para iOS (GoogleService-Info.plist).

  3. Traslada el archivo de configuración al directorio raíz de tu proyecto de Xcode. Si se te solicita, selecciona la opción para agregar el archivo de configuración a todos los destinos.

Si tienes varios ID de paquete en tu proyecto, debes asociar cada uno de ellos a una app registrada en Firebase console para que cada app tenga su propio archivo GoogleService-Info.plist.

Paso 2: Agrega el SDK de Firebase Crashlytics

  1. En CocoaPods, reemplaza los Pods Fabric y Crashlytics con un Pod Firebase/Crashlytics en todos los destinos. Asegúrate de agregar la versión 4.0.0 o posterior (es obligatorio para que se muestren los informes de fallas en Firebase console).

    # Add the pod for Firebase Crashlytics
    pod 'Firebase/Crashlytics'
    # Recommended: Add the Firebase pod for Google Analytics pod 'Firebase/Analytics'
  2. Desinstala o quita dependencias de terceros directamente de Fabric, como dependencias de Fabric Answers y kits de terceros.

  3. Instala y actualiza los Pods y abre el archivo .xcworkspace para ver el proyecto en Xcode. Puedes hacerlo con los siguientes comandos:

    pod install
    open your-project.xcworkspace

Paso 3: Actualiza tu código

  1. En Xcode, vuelve a compilar la app y abre el archivo .xcworkspace.

  2. Revisa los siguientes cambios del SDK y realiza las actualizaciones correspondientes en tu código:


Las secuencias de comandos de símbolos de ejecución y carga ahora están disponibles en FirebaseCrashlytics.

Ahora puedes acceder a las secuencias de comandos run y upload-symbols desde la nueva biblioteca FirebaseCrashlytics. Ten en cuenta que aún puedes llamar a upload-symbols en cualquier punto del proceso de compilación a fin de subir los dSYM de forma manual.

Además, API_KEY y BUILD_SECRET de Fabric ya no se incluyen en el nuevo SDK. En su lugar, Crashlytics ahora usa el archivo GoogleService-info.plist de tu app para asociarla con el proyecto de Firebase y conservar tus datos de fallas históricas.

SDK de Fabric

${PODS_ROOT}/Fabric/run API_KEY BUILD_SECRET
/path/to/pods/directory/Fabric/upload-symbols

SDK de Firebase Crashlytics

${PODS_ROOT}/FirebaseCrashlytics/run
/path/to/pods/directory/FirebaseCrashlytics/upload-symbols

Motivo del cambio

Crashlytics ya no usa el SDK de Fabric como dependencia, por lo que trasladaremos nuestras herramientas de CLI a una biblioteca nueva.


La biblioteca de Crashlytics ahora se llama FirebaseCrashlytics.

En tu app, actualiza tus rutas de importación:

SDK de Fabric

Swift

import Crashlytics

Objective-C

@import Crashlytics

SDK de Firebase Crashlytics

Swift

import FirebaseCrashlytics

Objective-C

@import FirebaseCrashlytics

Motivo del cambio

Actualizar el nombre de la biblioteca Crashlytics hace que sea coherente con otras bibliotecas de Firebase (p. ej., FirebaseFirestore y FirebaseAuth).


FirebaseCrashlytics ya no funciona con el SDK de Fabric.

Ahora, FirebaseCrashlytics solo se puede inicializar con el SDK de Firebase Crashlytics. Puedes iniciar una instancia de FirebaseCrashlytics llamando a FirebaseApp.configure en Swift o [FIRApp configure] en Objective-C.

En tu application:didFinishLaunchingWithOptions, reemplaza las llamadas a Fabric.with y startWithAPIKey con una llamada a FirebaseApp:

SDK de Fabric

Swift

Fabric.with([Crashlytics.self])

Objective-C

[Fabric with:@[[Crashlytics class]]];
+ startWithAPIKey:
+ startWithAPIKey:delegate:

SDK de Firebase Crashlytics

Swift

FirebaseApp.configure()

Objective-C

[FIRApp configure];

Motivo del cambio

El uso de los nuevos métodos para inicializar Crashlytics es más coherente con la forma en que se inicializan otros servicios de Firebase.


Se quitaron los métodos crash y throwException.

El nuevo SDK ya no incluye los métodos crash ni throwException. En su lugar, usa fatalError en Swift o assert en Objective-C para forzar fallas.

SDK de Firebase Crashlytics

Swift

// Force a test crash
fatalError()

Objective-C

// Force a test crash
assert(NO);

Motivo del cambio

Los diferentes tipos de fallas pueden ocurrir por varias razones. Estos métodos no especificaban claramente si las fallas resultantes ocurrieron durante el tiempo de ejecución o en el SDK nativo de tu app.


El método sharedInstance ahora se llama crashlytics.

El nuevo SDK ya no incluye el método sharedInstance. Para inicializar Crashlytics, usa crashlytics (consulta la documentación de referencia de Objective-C o Swift para obtener más información). En el delegado de la app, actualiza la secuencia de comandos de inicialización de la siguiente manera:

SDK de Fabric

Swift

Crashlytics.sharedInstance()

Objective-C

[Crashlytics sharedInstance];

SDK de Firebase Crashlytics

Swift

Crashlytics.crashlytics()

Objective-C

[FIRCrashlytics crashlytics];

Motivo del cambio

Cambiamos el nombre del método get para captar instancias a fin de que sea coherente con otros SDK de Firebase.


Crashlytics ya no rota los ID cuando el ID de publicidad cambia.

Crashlytics ahora usa ID de instancia en lugar de ID de publicidad para identificar instancias de tu app y asociar los datos de los usuarios con sus dispositivos. Puedes usar los ID de instancia para ayudar a los usuarios a controlar los datos de app.

Motivo del cambio

El uso de ID de instancia es coherente con otros SDK de Firebase. Ahora puedes administrar de manera uniforme tus datos de ID de instancia en otros servicios de Firebase.


setUserIdentifier ahora es setUserID. Se quitaron setUserName y setUserEmail.

Anteriormente, podías configurar un nombre o correo electrónico asociado con una falla mediante setUserName y setUserEmail, pero estos métodos ya no se definirán. A fin de establecer ID para los usuarios ahora se prefiere el método setUserID.

SDK de Fabric

Swift

Crashlytics.sharedInstance().setUserIdentifier("user_id")

Crashlytics.sharedInstance().setUserEmail("user_email")

Crashlytics.sharedInstance().setUserName("user_name")

Objective-C

[[Crashlytics sharedInstance] setUserIdentifier:@"user_id"];

[[Crashlytics sharedInstance] setUserEmail:@"user_email"];

[[Crashlytics sharedInstance] setUserName:@"user_name"];

SDK de Firebase Crashlytics

Swift

Crashlytics.crashlytics().setUserID("user_id")

Objective-C

[[FIRCrashlytics crashlytics] setUserID:@"user_id"];

Motivo del cambio

Adoptamos el nombre de método setUserID para que sea coherente con otras API de Firebase y quitamos setUserName y setUserEmail a fin de evitar el registro de PII a través de Crashlytics.


CLSLogv y CLSNSLogv se reemplazan con funciones de registro.

El nuevo SDK ya no incluye las funciones CLSLogv o CLSNSLogv. Para agregar mensajes de registro personalizados, usa los nuevos métodos de registro en la biblioteca Crashlytics. Ten en cuenta que los métodos nuevos ya no se imprimen en stdout o NSLog (recomendamos que escribas un wrapper si deseas mantener este comportamiento).

SDK de Fabric

Swift

CLSLogv("%@, %@", getVaList([first_arg, second_arg]))

CLSNSLogv("%@, %@", getVaList([first_arg, second_arg]))

Objective-C

CLSLog(@"%@, %@", first_arg, second_arg);
CLSNSLog(@"%@, %@", first_arg, second_arg);

CLSLogv(@"%@, %@", args_va_list);
CLSNSLogv(@"%@, %@", args_va_list);

CLS_LOG(@"%@, %@", first_arg, second_arg);

SDK de Firebase Crashlytics

Swift

Crashlytics.crashlytics().log("\(first_arg), \(second_arg)")

Crashlytics.crashlytics().log(format: "%@, %@", arguments: getVaList([first_arg, second_arg]))

Objective-C

[[FIRCrashlytics crashlytics] log:@"first_arg, second_arg"];

[[FIRCrashlytics crashlytics] logWithFormat:@"%@, %@", first_arg, second_arg];

Si usaste CLS_LOG, agrega lo siguiente a un archivo de encabezado para seguir obteniendo nombres de archivos y números de líneas en las instrucciones de registro:

#define CLS_LOG(__FORMAT__, ...) [[FIRCrashlytics crashlytics] logWithFormat:@"%s line %d $ " __FORMAT__, __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__]

Motivo del cambio

Los nuevos métodos requieren instancias, lo que facilita la prueba del código.


setCustomValue reemplazará a setObjectValue, setIntValue, setFloatValue y setBoolValue.

Los métodos set personalizados ya no se incluyen en el nuevo SDK. Anteriormente, podías usar los métodos para configurar pares clave-valor y enviarlos junto con el informe de fallas. Ahora, puedes usar setCustomValue:forKey a fin de definir pares clave-valor para todos los tipos de datos.

SDK de Fabric

Swift

Crashlytics.sharedInstance().setObjectValue("value", forKey: "object_key")

Crashlytics.sharedInstance().setIntValue(100, forKey: "int_key")

Crashlytics.sharedInstance().setFloatValue(99.9, forKey: "float_key")

Crashlytics.sharedInstance().setBoolValue(true, forKey: "bool_key")

Objective-C

[[Crashlytics sharedInstance] setObjectValue:@"key" forKey:@"object_key"];

[[Crashlytics sharedInstance] setIntValue:100 forKey:@"int_key"];

[[Crashlytics sharedInstance] setFloatValue:99.9 forKey:@"float_key"];

[[Crashlytics sharedInstance] setBoolValue:YES forKey:@"bool_key"];

SDK de Firebase Crashlytics

Swift

Crashlytics.crashlytics().setCustomValue("value", forKey: "object_key")

Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

Crashlytics.crashlytics().setCustomValue(99.9, forKey: "float_key")

Crashlytics.crashlytics().setCustomValue(true, forKey: "bool_key")

Objective-C

[[FIRCrashlytics crashlytics] setCustomValue:@"value" forKey:@"object_key"];

[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

[[FIRCrashlytics crashlytics] setCustomValue:@(99.9) forKey:@"float_key"];

[[FIRCrashlytics crashlytics] setCustomValue:@YES forKey:@"bool_key"];

Motivo del cambio

El nombre del método nuevo es exclusivo de Crashlytics y deja en claro que Crashlytics no cumple con el formato clave-valor.


recordCustomExceptionName:reason:frameArray: se reemplaza por la API de Exception Model.

Si tu app se ejecuta en un entorno no nativo (p. ej., JavaScript o Unity), puedes usar la API de Exception Model para informar metadatos de fallas en el formato de excepción nativo de la app.

SDK de Fabric

Swift

let topFrame = CLSStackFrame() topFrame.symbol = "doSomethingBad" topFrame.fileName = "bad.cc" topFrame.lineNumber = 23

let middleFrame = CLSStackFrame()
middleFrame.symbol = "doOtherStuff"
middleFrame.fileName = "stuff.cc"
middleFrame.lineNumber = 23;

let bottomFrame = CLSStackFrame()
bottomFrame.symbol = "main"
bottomFrame.fileName = "main.cc"
bottomFrame.lineNumber = 123

Crashlytics.sharedInstance().recordCustomExceptionName("FooException",
                                                       reason: "There was a foo.",
                                                       frameArray: [topFrame, middleFrame, bottomFrame])

Objective-C

CLSStackFrame *topFrame = [[CLSStackFrame alloc] init];
topFrame.symbol = @"doSomethingBad";
topFrame.fileName = @"bad.cc";
topFrame.lineNumber = 23;

CLSStackFrame *middleFrame = [[CLSStackFrame alloc] init];
middleFrame.symbol = @"doOtherStuff";
middleFrame.fileName = @"stuff.cc";
middleFrame.lineNumber = 23;

CLSStackFrame *bottomFrame = [[CLSStackFrame alloc] init];
bottomFrame.symbol = @"main";
bottomFrame.fileName = @"main.cc";
bottomFrame.lineNumber = 123;

[[Crashlytics sharedInstance] recordCustomExceptionName:@"FooException"
                                                 reason:@"There was a foo."
                                             frameArray:@[topFrame, middleFrame, bottomFrame]];

SDK de Firebase Crashlytics

Swift

var  ex = ExceptionModel.init(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame.init(symbol:"makeError" fileName:"handler.js" lineNumber:495),
  StackFrame.init(symbol:"then" fileName:"routes.js" lineNumber:102),
  StackFrame.init(symbol:"main" fileName:"app.js" lineNumber:12),
]

crashlytics.record(exceptionModel:ex)

Objective-C

model.stackTrace = @[
  [FIRStackFrame stackFrameWithSymbol:@"makeError" fileName:@"handler.js" lineNumber:495],
  [FIRStackFrame stackFrameWithSymbol:@"then" fileName:@"routes.js" lineNumber:102],
  [FIRStackFrame stackFrameWithSymbol:@"main" fileName:@"app.js" lineNumber:12],
];

Motivo del cambio

Esta función se ha solicitado por mucho tiempo y te permite extender Crashlytics a otras plataformas, como Unity, Flutter o React Native.



CrashlyticsDelegate se reemplaza por métodos separados para manejar informes de fallas.

Ahora puedes usar un nuevo conjunto de métodos para manejar los informes de fallas:

  • didFinishLaunchingWithOptions ahora se reemplaza por el nuevo controlador checkForUnsentReportsWithCompletion.

  • crashlyticsDidDetectReportForLastExecution ahora se reemplaza por didCrashDuringPreviousExecution. didCrashDuringPreviousExecution te permite detectar de manera conveniente las fallas que ocurren durante la última ejecución de tu app.

  • crashlyticsCanUseBackgroundSessions ahora se configura permanentemente como true.

  • Ya no se admite la inspección del objeto CLSReport en el delegado.

De forma predeterminada, Crashlytics sube automáticamente los informes de fallas durante el inicio, antes se podía llamar a didFinishLaunchingWithOptions para permitir que los usuarios aceptaran el envío de informes de fallas. Ahora, cuando llamas a setCrashlyticsCollectionEnabled=false para desactivar los informes de fallas automáticos, Crashlytics llama a checkForUnsentReportsWithCompletion, lo que permite a los usuarios elegir si enviar o no informes cuando la app falla. Luego, puedes llamar a sendUnsentReports si el usuario acepta o adeleteUnsentReports si no.

Ten en cuenta que también puedes llamar a sendUnsentReports y deleteUnsentReports fuera de checkForUnsentReportsWithCompletion. Por ejemplo, es posible que quieras configurar o inhabilitar de forma permanente los informes de fallas si los usuarios te han dado aprobación o rechazo general para enviar informes de fallas. Ten en cuenta que es posible que nunca recibas informes de fallas si tu app falla al comienzo del ciclo de vida.

SDK de Fabric

Swift

class YourClassName: CrashlyticsDelegate {

  func application(_ application: UIApplication, didFinishLaunchingWithOptions

    ...
    Crashlytics.sharedInstance().delegate = self
    ...

    return true
  }

  func crashlyticsDidDetectReport(forLastExecution report: CLSReport, completionHandler: @escaping (Bool) -> Void) {
    /* ... handle unsent reports */
  }

  func crashlyticsCanUseBackgroundSessions(_ crashlytics: Crashlytics) -> Bool {
    return true
  }
}

Objective-C

@interface YourClassName <CrashlyticsDelegate> ()
@end

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

  ...
  [[Crashlytics sharedInstance] setDelegate:self];
  ...

  return YES;
}

-(void)crashlyticsDidDetectReportForLastExecution:(CLSReport *)report completionHandler:(void (^)(BOOL submit))completionHandler {
  // ... handle unsent reports
}

-(BOOL)crashlyticsCanUseBackgroundSessions:(Crashlytics *)crashlytics {
  return YES;
}

@end

SDK de Firebase Crashlytics

Swift

/* You must set setCrashlyticsCollectionEnabled to false in order to use
checkForUnsentReportsWithCompletion. */

Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(false)

Crashlytics.crashlytics().checkForUnsentReports { hasUnsentReport in
  let hasUserConsent = false
  // ...get user consent.

  if hasUserConsent && hasUnsentReport {
    Crashlytics.crashlytics().sendUnsentReports()
  } else {
    Crashlytics.crashlytics().deleteUnsentReports()
  }
}

// Detect when a crash happens during your app's last run.
if Crashlytics.crashlytics().didCrashDuringPreviousExecution() {
  // ...notify the user.
}

Objective-C

/* You must set setCrashlyticsCollectionEnabled to false in order to use
checkForUnsentReportsWithCompletion. */

[[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:false];

[[FIRCrashlytics crashlytics] checkForUnsentReportsWithCompletion:^(BOOL hasUnsentReports) {
  BOOL hasConsent = false;
  // ...get consent from user.

  if (hasConsent && hasUnsentReports) {
    [[FIRCrashlytics crashlytics] sendUnsentReports];
  } else {
    [[FIRCrashlytics crashlytics] deleteUnsentReports];
  }
}];

// Detect when a crash happens during your app's last run.
if ([[FIRCrashlytics crashlytics] didCrashDuringPreviousExecution]) {
  // ...notify the user.
}

Motivo del cambio

El nuevo conjunto de métodos te da más control sobre el comportamiento de los informes de fallas de la app. Además, ya no necesitas configurar CrashlyticsDelegate antes de inicializar Crashlytics.


firebase_rashpics_collection_enabled se reemplaza por FirebaseCrashlyticsCollectionEnabled.

Cuando configuras FirebaseCrashlyticsCollectionEnabled como false en tu Info.plist, Crashlytics deja de enviar automáticamente informes de fallas durante el inicio. Después de la primera ejecución de la app, también puedes inhabilitar los informes de fallas si configuras setCrashlyticsCollectionEnabled como false en Crashlytics.h, pero ten en cuenta que setCrashlyticsCollectionEnabled anula esta marca.

Para desactivar la recopilación automática, reemplaza la clave firebase_crashlytics_collection_enabled en Info.plist:

  • Clave: FirebaseCrashlyticsCollectionEnabled

  • Valor: false

Después de la primera ejecución de tu app, también puedes desactivar la recopilación automática si agregas lo siguiente a tu Crashlytics.h:

SDK de Firebase Crashlytics

Swift

// setCrashlyticsCollectionEnabled is set to true by default.
Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(false)

Objective-C

// setCrashlyticsCollectionEnabled is set to true by default.
[[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:false];

Motivo del cambio

Ahora tienes más control sobre la forma en que Crashlytics maneja los informes de fallas no enviados cuando inhabilitas los informes automáticos. Después de configurar FirebaseCrashlyticsCollectionEnabled como false, puedes llamar a checkForUnsentReportsWithCompletion desde cualquier lugar de la app y enviar o borrar informes no enviados, según lo que elija el usuario.


Ahora, Crashlytics siempre usa sesiones en segundo plano.

Antes, podías desactivar las sesiones en segundo plano si no querías admitir esta modalidad en tu app. Para ello, se debía configurar crashlyticsCanUseBackgroundSessions como false. Ahora, crashlyticsCanUseBackgroundSessions siempre está configurado como true.

Motivo del cambio

Ya no admitimos versiones de iOS anteriores a 7.0 o macOS anteriores a OS X 10.9, ya que no admiten sesiones en segundo plano.


Crashlytics solo puede usar los datos que recopila Google Analytics.

Una vez que actualices al SDK de Firebase Crashlytics, ya no podrás recopilar datos con Fabric Answers. Para obtener métricas de rutas de navegación y usuarios que no experimentaron fallas, cambia a Google Analytics. Ten en cuenta que los datos históricos de Answers no se pueden migrar a Firebase.

Visita Comienza a usar Google Analytics para obtener información sobre cómo agregar Google Analytics a tu app. Si utilizaste previamente Fabric Answers, descubre cómo convertir los eventos de Answers en eventos de Analytics.

Motivo del cambio

Ahora ofrecemos Google Analytics para ayudarte a recopilar datos de fallas más detallados. Con Analytics, puedes seguir recopilando estadísticas de tu app en Firebase console.

Próximos pasos