Contexte de l’incident

Le 29 septembre 2026, plusieurs développeurs iOS ont signalé sur X que le SDK Firebase provoquait des crashs immédiats sur l’ensemble des sessions d’application. Les messages indiquent plus de 110 000 plantages recensés en quelques heures, affectant toutes les versions du SDK intégrées dans les applications iOS. Aucun incident n’était annoncé sur le tableau de statut de Firebase, ce qui a accentué la confusion.

Mécanismes du SDK Firebase iOS

Le SDK Firebase pour iOS s’appuie sur le runtime Objective‑C pour injecter du code via le method swizzling. Cette technique permet à des services comme Analytics, Crashlytics ou Remote Config de remplacer dynamiquement des implémentations système (par ex. application:didFinishLaunchingWithOptions:) afin de collecter des métriques sans modifier le code de l’application. Le SDK est distribué sous forme de framework binaire (.framework) et se met à jour via CocoaPods, Swift Package Manager ou Carthage.

import Firebase

FirebaseApp.configure()

Lors de l’initialisation, le SDK charge des ressources depuis les serveurs Google (ex. configuration Remote Config, clés d’API). Toute modification de ces ressources peut impacter le comportement du code injecté.

Analyse des causes possibles

Les tweets font état d’un « server‑side change » qui aurait déclenché le plantage. Deux scénarios techniques sont plausibles :

1. Modification du fichier de configuration Remote Config contenant des valeurs utilisées lors du démarrage du SDK. Si une clé attendue était supprimée ou si un type de donnée était changé (ex. chaîne attendue remplacée par un entier), le code swizzlé pourrait lever une exception non interceptée, entraînant un crash dès le premier appel.

2. Déploiement d’une nouvelle version du binaire de service côté serveur (ex. Firebase Analytics) qui impose une version minimale du SDK. Si le serveur renvoie des réponses incompatibles avec les versions antérieures, le SDK peut tenter d’accéder à des méthodes inexistantes, provoquant un unrecognized selector sent to instance fatal.

Dans les deux cas, l’absence de validation côté client (pas de fallback, pas de vérification de version) conduit à une interruption totale. Le fait que le tableau de statut n’ait pas affiché d’incident suggère un défaut de monitoring interne : le crash a été détecté uniquement par les rapports de crash de tiers (ex. Crashlytics, App Store Connect).

Conséquences et recommandations

Le blocage complet des applications impacte la disponibilité des services dépendants de Firebase (authentification, base de données, notifications). Les développeurs doivent envisager des stratégies de mitigation : désactiver temporairement le SDK via un flag de compilation, ou remplacer l’initialisation par un wrapper qui capture les exceptions pendant configure(). À plus long terme, Firebase devrait implémenter :

  • un mécanisme de versionnage strict des réponses serveur, avec validation de compatibilité avant exécution ;
  • une page d’incident en temps réel alimentée par les métriques de crash ;
  • une documentation claire sur les exigences de version minimale du SDK pour chaque modification serveur.

Les équipes iOS sont également encouragées à surveiller les rapports de crash dès le déploiement d’une mise à jour du SDK et à tester les réponses Remote Config dans un environnement isolé avant la mise en production.