The Firebase crash on iOS on September 29 wasn’t caused by your code: it was caused by a malformed response that Google Analytics for Firebase sent from its servers, which closed apps on startup. Google fixed the issue at 02:52 UTC, no SDK update is necessary, and residual cases should have disappeared by 06:52 UTC.
Status at the time this note was published (September 29, 2026): Google confirmed the fix in the GitHub issue, but had not published the root cause. The Firebase Status Dashboard showed no incidents.
What happened with Firebase on iOS?
At 00:41 UTC, Google’s experiments endpoint sdk-exp (app-analytics-services.com/sdk-exp) started returning a response that the Analytics SDK converted into a nil dictionary key. The result was an uncaught NSInvalidArgumentException (key cannot be nil) in a background queue, and the system killed the process.
In local time it was 21:41 on September 28 in Buenos Aires and Santiago, 18:41 in Mexico City, and 02:41 on September 29 in Madrid.
The first report, #16728, was very precise:
- 56 crashes in 56 users during the first 18 minutes.
- Four already-published builds started failing at the same moment.
- In 42 of 42 crashes reviewed, the crash occurred right after the endpoint returned a normal HTTP 200.
Another developer reported around 20,000 crashes before the first hour had passed.
The range of affected versions was wide: there are reports with Firebase SDK 10.24.0, 12.14.0, and 12.17.0, and with GoogleAppMeasurement 12.10.0. That dispersion fits with a server-side trigger, not with a defective version. One of those affected noticed that only the first app launch failed, not subsequent ones. He attributed it to SDK throttling: only the first fetch after the timeout window received the corrupted payload.
Do I need to update the Firebase SDK?
No. In its statement within the issue, Google indicates that no SDK update is required. According to Google, the fix finished rolling out at 19:52 PDT on September 28 (02:52 UTC on September 29). Due to cache behavior, some app instances could continue crashing for up to four hours after that, that is, until 06:52 UTC.
If you see this signature in your crash reports during that window, this incident is your explanation: -[__NSDictionaryM setObject:forKeyedSubscript:] with APMETaskManager fetchExperiments in the stack. If the spike continues much after that window, look for another cause.
Why didn’t Firebase Status show the incident?
The Firebase Status Dashboard listed no incidents while it was happening. The page itself explains why: Google Analytics incidents are published on the Ads Status Dashboard. If your monitoring only watches the Firebase status page, this incident didn’t appear on it.
What is Firebase and what does Google Analytics for Firebase do in your app?
Firebase is Google’s app development platform. It brings authentication, databases, push notifications, crash reporting (Crashlytics), Remote Config, and analytics together under one family of SDKs.
Google Analytics for Firebase is the measurement piece. On iOS it’s distributed as GoogleAppMeasurement, which records events and user properties. As this incident showed, it also downloads experiment configuration from Google when the app starts. That fetch runs inside your process, with your app’s privileges, and a malformed response was enough to close it.
Does disabling Firebase Analytics protect your app?
Based on the evidence from this incident, no. The author of #16729 had IS_ANALYTICS_ENABLED set to false in GoogleService-Info.plist and never called Analytics from their code, yet their app still crashed. Firebase/Core included FirebaseAnalytics as a transitive dependency. Another affected developer didn’t even use A/B Testing.
Firebase documentation offers two keys in Info.plist:
FIREBASE_ANALYTICS_COLLECTION_ENABLEDto pause collection.FIREBASE_ANALYTICS_COLLECTION_DEACTIVATEDto deactivate it permanently in a build.
The documentation describes both in terms of data collection. It doesn’t say that either one stops the SDK’s network fetches. At the time this note was published, Google had not clarified whether either would have prevented this crash.
The only guarantee is not to include the code. Check your Podfile.lock or your Package.resolved and look for GoogleAppMeasurement. If it appears and no one on the team decided to add it, it arrived as a dependency of something else.
Is Firebase Analytics free?
In price, yes: Google lists Analytics at no cost on both the Spark and Blaze plans. The cost is something else. You’re running Google code inside your binary, configured at runtime by Google’s servers, at Google’s release cadence. Last night showed what that dependency can do in practice.
What should a tech leader change after this?
My opinion: any SDK that downloads configuration at app startup is production input you don’t control, and you need to treat it as such.
Inventory. You need to know what third-party SDKs make network calls during startup. The team that wrote the Podfile often doesn’t know.
Alerts that don’t depend on a release. Most crash alerts fire after a deploy. There was no deploy here, and the teams that detected it early were watching the absolute crash rate.
It’s not the first time. The author of #16731 links it to an earlier crash from the same family, #16145: another part of the experiments parser that failed with a malformed payload. A malformed response is an incident. Two in the same subsystem are a pattern worth raising with your vendor.
None of this means abandoning Firebase. It means accepting that a free SDK can take down a binary you published four months ago.
If you’re evaluating backend alternatives, we analyze one in InstantDB 1.0.