Firebase iOS SDK crashes apps across all sessions, developers report live incident

What happened

Early on September 29, developers began reporting that iOS apps embedding Firebase's SDK were crashing. Gergely Orosz, posting on X, said the SDK had started crashing "ALL iOS apps that were using it, for ALL sessions," leaving the affected apps with no way to respond from their side. He called the situation amateurish for any SDK, and pointedly so for one maintained by Google, a company he described as holding a high engineering bar.

The post gained traction quickly — the source summary counts roughly 143,700 views — and the discussion reached the front page of Hacker News, which for many developers was likely the first coherent explanation for crash spikes appearing in their own products.

What the reports say

Replying to Orosz, developer Vijay Tholpadi linked to an issue on Firebase's GitHub repository and said iOS apps had been "intermittently crashing since today morning." The wording differs in one important way from Orosz's account: Orosz describes every session failing, while Tholpadi describes intermittent crashes. The two agree that the trouble began in the morning and that Firebase's SDK, rather than anything in the apps themselves, is the common factor.

Neither post specifies a technical cause. As of the summarized reports, there is no detail on whether the trigger is a defective SDK build distributed to apps, a change on a Firebase backend or in remote configuration that the SDK reacts to, or something else entirely. Tholpadi's appeal — a direct plea for Firebase to help — captures the position many teams found themselves in: waiting on the vendor.

Echoes of an earlier ecosystem-wide crash

Tholpadi compared the incident to what he called the Facebook swizzling crash. The best-known parallel is May 2020, when a change on Facebook's side caused its widely embedded iOS SDK to crash a large number of third-party apps at startup. App developers could not ship fixes fast enough for it to matter; recovery depended on Facebook reverting its own change. The comparison does specific work here: it suggests an SDK vendor's remote decision can take down apps that did nothing wrong, and that recovery runs through the vendor rather than the app teams.

Why it matters

Firebase is one of the most commonly embedded SDKs in the iOS ecosystem, covering analytics, crash reporting, messaging and more, so an SDK-level crash is not a single-product outage but a potential event spanning many unrelated apps at once. As reported, this incident is a concrete example of that concentration risk.

It also highlights the asymmetry of mobile incidents. Server operators can roll back a bad deploy in minutes; an iOS app broken by a dependency generally cannot respond faster than App Store review allows. When the failure lives in a vendor's SDK, the app teams are spectators.

For engineering teams, incidents like this are the standing argument for treating third-party SDKs as untrusted infrastructure: keeping their startup work minimal, wrapping their entry points so an SDK crash cannot take the whole app down, and favoring vendors that ship behind kill switches and gradual rollouts. For Google, the immediate questions are what triggered the crashes, why whatever gate could have caught it did not, and how quickly the SDK can be stabilized — questions that, at the time of these posts, remained unanswered.