A Google Analytics for Firebase payload crashed thousands of iPhone apps at launchA Google Analytics for Firebase payload crashed thousands of iPhone apps at launch

Thousands of iPhone apps that use Google Analytics for Firebase began crashing on launch in the early hours of 29 September 2026.

The failure was recorded on Google's own issue tracker for the Firebase iOS SDK, where the report opens with production apps crashing from 00:41 UTC and counts 56 crashes across 56 users in the first eighteen minutes. The crash signature is a nil dictionary key, raised as the app starts. In every instance checked by the developers filing reports, it followed the response to a POST request the SDK makes to an endpoint named sdk-exp at app-analytics-services.com, which returned HTTP 200 rather than an error.

Nothing had been released. The affected apps were running Firebase SDK version 12.14.0, already in the App Store and already on users' phones. What changed was the payload the server returned, which the SDK parsed into a key it then could not use. Because Analytics initialises during startup, the result was an app that closed immediately on being opened rather than one that misbehaved later.

A Firebase maintainer, posting as ncooke3, pinned a statement to the thread giving the resolution time as 23:52 Pacific on 28 September, and noting that crash reporter latency would keep older crashes appearing in dashboards afterwards. The fix was applied on Google's side; no app update and no SDK upgrade was required, and developers were told no action was needed from them. MacRumors reported users seeing the crash in Tesla, Uber, Waymo and Valley Metro, and noted the timing coincided with Apple's iOS 27.0.1 release without being connected to it.

Google has said it is looking into the root cause and will publish what caused the incident and what will prevent a repeat. At the time of writing that account has not appeared, and the issue thread does not say what generated the malformed payload or why it reached production.

Who controlled what

What could a developer actually do?

Almost nothing, and that is the part worth sitting with. An app that crashes on launch cannot be fixed by an update, because the update has to be reviewed, released and then installed by a user who can no longer open the app to be prompted. Removing the SDK and shipping a build would have taken longer than the outage lasted. For roughly six hours the correct engineering response was to wait for someone else to deploy.

The usual defences did not apply either. This was not a bad SDK version that a pinned dependency would have avoided, because 12.14.0 had been running in production without incident. It was not caught by App Review, which inspects a binary and cannot inspect what a server will send it next week. It would not have been caught by staged rollout, because the change was not in the app. A test suite passes against the responses it is given, and this response did not exist when the tests were written.

Our take

APPDOOK's reading is that this is the clearest demonstration in a while of something the App Store's model quietly obscures: a third-party SDK is not a library, it is a live connection to somebody else's infrastructure, and it holds a code path that executes on your users' devices at a time the vendor chooses. You reviewed the code once. You did not review what it would be told to do.

The specific detail that makes this sharp is the HTTP 200. The SDK was not handling a server error, a timeout or an outage, all of which a defensive client is written to expect. It received a successful response with a body it could not parse and turned that into a fatal exception on the main path at launch. An SDK that ran this work off the startup path, or that treated its own parsing failures as a reason to disable itself rather than to crash, would have produced a degraded analytics feed and no user-visible symptom at all. That is a design choice inside a dependency, made by someone else, that decided whether an app opened.

For anyone shipping on Apple's platforms, the practical items are small and worth doing before the next one. Know which of your dependencies phone home during launch, because those are the ones that can take the app with them. Ask whether analytics needs to initialise before first paint, since almost none of it does. And where a vendor SDK offers a delayed or manual start, use it, not for performance but because it moves the failure out of the window where it is unrecoverable.

The last point is about what we tell users. During the outage the only honest message was that the app was broken, the cause was outside the company, and it would return when a third party fixed it. Very few teams have a way to say that, because the channel most would use is the app itself. A status page that lives somewhere other than your product is unglamorous and cheap, and this is the day it would have earned its keep.