Firebase SDK Crashes Every iOS App Using It

At 00:41 UTC on September 29, 2026, a server-side change in Firebase Analytics began crashing every iOS app that had the Firebase SDK installed. No app update required. No code change on the developer side. The SDK fetched a new experiment configuration from Google's servers, tried to parse it, hit a nil key in an NSDictionary, and threw an NSInvalidArgumentException that killed the app. Every session. Every app. For hours.

The crash trace, documented in GitHub issue #16728 on the firebase-ios-sdk repository, tells the story. The SDK sends a POST request to app-analytics-services.com/sdk-exp. The server responds with HTTP 200. The SDK hands the response to APMExperimentWorkerQueue, which parses it into experiment snapshots. Somewhere in that parsing, a nil key ends up in a dictionary write. Objective-C's NSDictionary does not tolerate nil keys. The app dies.

One developer reported 56 crashes across 56 users in the first 18 minutes. The crash hit four already-released builds simultaneously. There was nothing developers could do except wait for Google to fix the server response. Gergely Orosz, author of The Pragmatic Engineer, called it out on X with frustration: "How amateur is all of this from any SDK, but especially one from a company with as high of an engineering bar like Google." His post gathered over 207'000 views.

Google resolved the server-side issue, but the damage window was wide. Apps with aggressive caching or slow rollout could still hit the bad config for up to four hours after the fix. And the SDK itself was never updated. There is no patched version. The fix was purely on the server side, which means the same crash could happen again tomorrow if another bad config gets pushed.

The Hacker News discussion, which reached 56 points and 29 comments in its first hour, surfaced the real question: why does a third-party SDK have the power to crash your entire app over a server response it does not control? One commenter put it plainly: "A dependency on code you can't read reaching out to servers you don't control is a recipe for disaster." Another pointed out that this is not even the first time. Facebook's SDK did the same thing to iOS apps in 2020. Same pattern: server sends something unexpected, SDK crashes, every app using it goes down.

The deeper problem is structural. Firebase is bundled into a huge portion of iOS and Android apps because push notifications effectively require it. Even developers who use alternatives like OneSignal still need a Firebase account and Firebase dependencies in their app. So when Firebase breaks, the blast radius is enormous. And developers have no way to sandbox the SDK, no way to intercept its network calls, no way to protect their app from a server-side config change they never approved.

This is not a Firebase-specific problem. It is a third-party SDK problem. Any SDK that phones home to a server you do not control and then processes that response on the main thread (or any thread that can crash the app) is a loaded gun pointed at your uptime. The fact that it comes from Google, a company with more engineering talent than most countries, makes it worse, not better. It means the problem is not capability. It is architecture.

On Hacker News, developers asked what the alternatives are. Supabase came up as the open-source self-hostable option, though it lacks Firebase's offline sync. Some suggested decoupling push notifications from the full Firebase SDK. Others pointed out that the real lesson is operational: canary rollouts, server-side schema validation, and SDKs that fail gracefully instead of crashing. None of these are new ideas. They just did not get applied.

For now, the issue is marked resolved. But "resolved" here means "Google fixed the server." The SDK still cannot handle a nil key in an experiment response. The next bad config will crash every iOS app again. That is not resolved. That is a ticking bomb.

Source: GitHub Issue #16728 [1]
Gergely Orosz on X (207'000+ views) [2]
Hacker News discussion (56 points, 29 comments) [3]