El crash de Firebase en iOS del 29 de septiembre no lo causó tu código: lo causó una respuesta mal formada que Google Analytics for Firebase envió desde sus servidores, y que cerraba las apps al abrirse. Google corrigió el problema a las 02:52 UTC, no hace falta actualizar el SDK y los casos residuales debían desaparecer antes de las 06:52 UTC.
Estado al momento de publicar esta nota (29 de septiembre de 2026): Google confirmó la corrección en el issue de GitHub, pero no había publicado la causa raíz. El Firebase Status Dashboard no mostraba ningún incidente.
¿Qué pasó con Firebase en iOS?
A las 00:41 UTC, el endpoint de experimentos sdk-exp de Google (app-analytics-services.com/sdk-exp) empezó a devolver una respuesta que el SDK de Analytics convertía en una clave nil de diccionario. El resultado era una NSInvalidArgumentException (key cannot be nil) no capturada en una cola en segundo plano, y el sistema mataba el proceso.
En hora local fueron las 21:41 del 28 de septiembre en Buenos Aires y Santiago, las 18:41 en Ciudad de México y las 02:41 del 29 en Madrid.
El primer reporte, el #16728, fue muy preciso:
- 56 crashes en 56 usuarios durante los primeros 18 minutos.
- Cuatro builds ya publicados empezaron a fallar en el mismo instante.
- En 42 de 42 crashes revisados, el cierre llegaba justo después de que el endpoint devolviera un HTTP 200 normal.
Otro desarrollador reportó unos 20.000 crashes antes de que pasara la primera hora.
El rango de versiones afectadas fue amplio: hay reportes con el SDK de Firebase 10.24.0, 12.14.0 y 12.17.0, y con GoogleAppMeasurement 12.10.0. Esa dispersión encaja con un disparador del lado del servidor, no con una versión defectuosa. Uno de los afectados notó que solo fallaba la primera apertura de la app y no las siguientes. Lo atribuyó al throttling del SDK: solo el primer fetch después de la ventana de espera recibía el payload dañado.
¿Tengo que actualizar el SDK de Firebase?
No. En su comunicado dentro del issue, Google indica que no se requiere ninguna actualización del SDK. Según Google, la corrección terminó de desplegarse a las 19:52 PDT del 28 de septiembre (02:52 UTC del 29). Por el comportamiento de la caché, algunas instancias de la app podían seguir fallando hasta cuatro horas después, es decir, hasta las 06:52 UTC.
Si en tus reportes de crashes ves esta firma en esa ventana, este incidente es tu explicación: -[__NSDictionaryM setObject:forKeyedSubscript:] con APMETaskManager fetchExperiments en el stack. Si el pico sigue mucho después de esa ventana, busca otra causa.
¿Por qué Firebase status no mostró el incidente?
El Firebase Status Dashboard no listaba ningún incidente mientras ocurría. La propia página explica por qué: los incidentes de Google Analytics se publican en el Ads Status Dashboard. Si tu monitoreo solo vigila la página de estado de Firebase, este incidente no apareció en ella.
¿Qué es Firebase y qué hace Google Analytics for Firebase en tu app?
Firebase es la plataforma de desarrollo de apps de Google. Reúne bajo una misma familia de SDKs la autenticación, las bases de datos, las notificaciones push, el reporte de crashes (Crashlytics), Remote Config y la analítica.
Google Analytics for Firebase es la pieza de medición. En iOS se distribuye como GoogleAppMeasurement, que registra eventos y propiedades de usuario. Como mostró este incidente, también descarga configuración de experimentos desde Google al iniciar la app. Ese fetch corre dentro de tu proceso, con los privilegios de tu app, y una respuesta mal formada bastó para cerrarla.
¿Desactivar Firebase Analytics protege tu app?
Con la evidencia de este incidente, no. El autor del #16729 tenía IS_ANALYTICS_ENABLED en false dentro de GoogleService-Info.plist y nunca llamaba a Analytics desde su código, y aun así su app se cerraba. Firebase/Core incluía FirebaseAnalytics como dependencia transitiva. Otro afectado ni siquiera usaba A/B Testing.
La documentación de Firebase ofrece dos claves en Info.plist:
FIREBASE_ANALYTICS_COLLECTION_ENABLEDpara pausar la recolección.FIREBASE_ANALYTICS_COLLECTION_DEACTIVATEDpara desactivarla de forma permanente en un build.
La documentación describe ambas en términos de recolección de datos. No dice que ninguna de las dos detenga los fetch de red del SDK. Al momento de publicar esta nota, Google no había aclarado si alguna habría evitado este crash.
La única garantía es no incluir el código. Revisa tu Podfile.lock o tu Package.resolved y busca GoogleAppMeasurement. Si aparece y nadie en el equipo decidió agregarlo, llegó como dependencia de otra cosa.
¿Firebase Analytics es gratis?
En precio, sí: Google lista Analytics sin costo tanto en el plan Spark como en el Blaze. El costo es otro. Estás ejecutando código de Google dentro de tu binario, configurado en tiempo de ejecución por los servidores de Google, al ritmo de publicación de Google. Anoche se vio lo que esa dependencia puede hacer en la práctica.
¿Qué debería cambiar un líder técnico después de esto?
Mi opinión: cualquier SDK que descarga configuración al iniciar la app es input de producción que no controlas, y hay que tratarlo como tal.
Inventario. Tienes que saber qué SDKs de terceros hacen llamadas de red durante el arranque. El equipo que escribió el Podfile muchas veces no lo sabe.
Alertas que no dependan de un release. La mayoría de las alertas de crashes se disparan después de un deploy. Aquí no hubo deploy, y los equipos que lo detectaron temprano miraban la tasa absoluta de crashes.
No es la primera vez. El autor del #16731 lo vincula con un crash anterior de la misma familia, el #16145: otra parte del parser de experimentos que fallaba ante un payload mal formado. Una respuesta mal formada es un incidente. Dos en el mismo subsistema son un patrón que vale la pena plantearle a tu proveedor.
Nada de esto significa abandonar Firebase. Significa asumir que un SDK sin costo puede tumbar un binario que publicaste hace cuatro meses.
Si estás evaluando alternativas de backend, analizamos una en InstantDB 1.0.