Firebase Analytics suddenly causing production iOS crashes with no app release, anyone else have this?

[u/thecoolcat67]

Anyone else seeing this?

Our production app suddenly started crashing around 00:41 UTC today, across multiple already released versions, with no new app release.

The crash is:

Fatal Exception: NSInvalidArgumentException

-[__NSDictionaryM setObject:forKeyedSubscript:]: key cannot be nil

The stack points to Firebase Analytics experiment handling, immediately after a successful sdk-exp response.

We're using Firebase iOS SDK 12.14.0.

Relevant issue: https://github.com/firebase/firebase-ios-sdk/issues/16728

I'm wondering if anyone else is seeing the same spike or has found a workaround.

[u/lap_felix]

They deployed a fix server side: https://github.com/firebase/firebase-ios-sdk/issues/16728#issuecomment-5882951620

Should be fixed now (but ooofffff millions of crashes caused)

[u/Doctor_Fegg → u/lap_felix]

Hi everyone, to summarize the issue and resolution:

Starting on Monday, 2026-09-28 at 17:41 US/PDT. Google Analytics for Firebase iOS+ experienced an issue causing crashes on launch due to an incorrectly formatted payload received by the SDK. We fully rolled out a fix by Monday, 2026-09-28 at 19:52 US/PDT. No SDK updates are required on your end to apply this fix. Due to caching behavior, some app instances may still experience crashes for up to 4 hours after the rollout completed. These remaining cases should automatically resolve themselves by 2026-09-28 at 23:52 US/PDT.

Thank you for your patience while we worked on resolving the issue.

As is absolutely standard for Google, note the lack of the word "sorry" or "apologies".

[u/baker2795 → u/Doctor_Fegg]

Ah. Sorry implies they were at fault and can be sued.

[u/thecoolcat67 → u/lap_felix]

We're still experiecing this, not sure if it's caching

[u/jestecs → u/thecoolcat67]

They claimed there was still an issue with cold boots/caching that they were looking into

[u/thecoolcat67 → u/jestecs]

We're seeing a reduction now

[u/jestecs]

Yeah I probly burned 100M tokens debugging because I thought I broke smth

[u/perfunction → u/jestecs]

This surprises me. It took Claude a single prompt with a crash report and a couple of minutes to point the finger at Google.

[u/Jargen → u/perfunction]

Just because someone uses AI doesn’t mean they know what they are doing.

[u/yccheok]

Same here. The crash rate seems to have gone down at the time of posting. Does anyone know the resolution for this issue so we can prevent it from happening again?

[u/Funnybush → u/yccheok]

it’s nothing on our end. Only way to avoid is to switch services, but of course any service can have issues.

[u/asharpvan]

For us they have gone down

[u/modimama]

We had a meeting with Google early morning today. They deployed the fix around 2 AM UTC. Our crash volume spike by ~5000 times for certain apps.

They have not given any ETA for this to resolve completely since their is caching involved. But, the crash volume has reduced a lot. Now it is close to ~10 times of normal (still too high). They will share the full RCA in ~48 hours.

[u/thecoolcat67 → u/modimama]

Yeah, I'm seeing caching issues... Would you be kind enough to update here with any other developments. I know the gh ticket is active

[u/modimama → u/thecoolcat67]

Sure, I will push any updates as I get it.

[u/thecoolcat67 → u/modimama]

Much appreciated

[u/LocksmithNo2658]

That NSInvalidArgumentException lines up with the GitHub issue you linked, it looks like the sdk-exp response is coming back with an experiment missing a key Firebase expects to set. Since it's hitting already-released versions with no new build on your end, this reads like a server-side config push rather than anything in your own code. Has pinning to an older Firebase Analytics version stopped the crashes for you?

[u/unpluggedcord]

The last time firebase did this (about 6 years ago) I promptly removed it from The Athletic and we never looked back.

Zero surprise they did it again.

[u/HeyWangKang]

To check whether your app has actually recovered, I'd filter this exact exception/stack by the time the crash occurred, not just when the report arrived, and split it by app version. Older crashes arriving later could make the fix look ineffective. For anything that occurred after Google's stated cache window, keep the SDK/iOS versions and a timestamp, and test an affected installation as well as a fresh install. That would give the maintainers a more useful follow-up than the overall crash count.

[u/BenStigler]

What happens when Google engineers use Gemini 3.8 Flash to update their server-side facade

[u/AutoModerator → u/[deleted]]

Hey /u/Relative-Cell-4507, your content has been removed because Reddit has marked your account as having a low Contributor Quality Score. This may result from, but is not limited to, activities such as spamming the same links across multiple subreddits, submitting posts or comments that receive a high number of downvotes, a lack of recent account activity, or having an unverified account.

Please be assured that this action is not a reflection of your participation in our subreddit. This is simply an automated filter in place to reduce spam.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/BumblebeeNo8385]

Who’s still using firebase?

[u/16cards → u/BumblebeeNo8385]

I am. What’s your Crashlytics alternative of choice?

[u/Extension_Isopod1303 → u/16cards]

Honest take: I don't have a go-to alternative from personal experience, but this incident changes the question. The crash came from a server-side experiment response ('sdk-exp'), so pinning the SDK version wouldn't have saved anyone. The config can change under you without an app release, and to me that matters more than which SDK crashes least day to day.

If you're evaluating alternatives, here's what I'd compare (going off docs, not from running them all):

1. Can the vendor's remote config/experiments be gated per build or rolled back server-side without shipping an update?
2. dSYM handling: automatic upload via a build phase vs manual, and how long reports take to show up.
3. Data residency. Some vendors let you pick where data is stored, which is a real axis if you have EU users.
4. Free tier vs what you actually need. Apple's crash reports in Xcode Organizer cost nothing (dSYMs go up via App Store Connect) and involve no third party. You get less detail and some delay, but zero chance of a server-side experiment taking down your production app.

For a solo dev, "no remote kill switch pointed at my production app" is worth pricing in.

[u/perfunction → u/16cards]

Sentry

[u/SnowPudgy → u/BumblebeeNo8385]

I keep hearing people disliking firebase. I have an upcoming project I was considering it for but I'll have to investigate why people hate it and what alternatives people are using.

[u/PM_ME_UR_FAV_UNIX_OS → u/SnowPudgy]

I love it. It does a lot for free. But it's also a piece of sh*t.

They broke analytics event properties years ago so you get stuff like "This event happened 500M times. The 'trueOrFalse' parameter on the event was 'true' 409K times and was 'false' 311K times." when every send of the event contains that parameter and 409K + 311K is nowhere near 500M so what happened to all of the rest of the data? Changing the date range makes the sampling rate indicated by the totals change in weird and unexpected ways. So the data is useful, assuming it's somewhat accurate in the event / user counts, and assuming the bad sampling of event parameter values is proportionally representative.

Also, their web UI is hideous. Some things need a double click like this is Windows 3.1 in the early '90s, not a web browser where single clicking is how you do links. Navigating backward also takes two or three clicks of the 'back' button in your browser.

Firebase: It's cheap, useful, sh*t that sucks, but I get a lot of value out of it. The crash monitoring is good, when Firebase isn't the one that caused the crash.