What happened on September 29: app crashes caused by Google's server-side configuration
Published October 5, 2026 / Affects: iCap, iDig
In short: this was not a bug in the apps. It was a configuration sent from Google's servers.
From 9:41 to 11:47 (Japan time) on September 29, 2026, iCap and iDig could close unexpectedly while open. The cause was that a Google component built into the apps (Firebase) could not handle a configuration sent from Google's servers. After Google reverted it, the same crash has not been recorded again (checked through October 5). I'm sorry for the trouble.
What happened
On the morning of September 29, reports of the app closing suddenly while it was open rose sharply in Crashlytics (Google's service that automatically collects app crashes). It started at almost the same time in both iCap and iDig. On most devices it happened only once, and a second crash on the same device was rarely recorded.
| Time (Japan) | What happened |
|---|---|
| 9:41 | The first crash was recorded in iCap (iDig followed about five minutes later). |
| 9:40–11:20 | Roughly 200–320 reports every 10 minutes. The peak was 319 in the 11:10 slot (iCap). |
| From about 11:20 | Reports began to fall sharply, which looks like Google reverting the configuration. |
| 11:47 | The last crash was recorded. None have been recorded since. |
| 11:54 | After noticing the spike and investigating, I recorded that the cause was inside Google's component (about two hours after it began). |
| 13:01 | The once-a-day automatic check reported "23 times the usual". By then it had already stopped. |
How big was it?
| iCap | iDig | |
|---|---|---|
| Crashes from this issue | iCap 2,969 | iDig 188 |
| All crashes that day | iCap 3,196 | iDig 206 |
| A usual day (Sept 20–28) | iCap 62–160 | iDig 4–61 |
| The next day (Sept 30) | iCap 86 | iDig 11 |
It did not repeat on the same device: it was about once per device (about 2,970 devices for iCap and 188 for iDig). It spread across iOS 17 to 27 and about 78 device models, so it was not tied to a particular device or iOS version. It appears most in the latest iCap (8.7) simply because most people use the latest version; it happened in every version, iCap 7.5 to 8.7 and iDig 11.2 to 11.18.
The cause
iCap and iDig include a Google component called Firebase. It automatically collects crashes so I can notice and fix bugs quickly. Part of it (Firebase Analytics) occasionally receives "experiment settings" from Google's servers.
On the morning of September 29, an error occurred inside the component while it processed the configuration that arrived from those servers. The recorded error says it tried to put a value into a dictionary (a table of names and values) with an empty name, which suggests the data that arrived lacked a name it expected. According to the public report (as of September 29), the cause was a server-side configuration, which Google identified and reverted. The actual contents of the data were not published, so I am not going further than that.
Why I can say it was not a bug in the apps
- Every crash happened inside Google's component. The call history of the crash is entirely that component's code. iCap and iDig do not call this component's features directly.
- iCap and iDig started at the same time with the same content. Even the crash category matched exactly.
- It had nothing to do with when the apps were updated. Every version, including old ones, was affected at the same moment.
- Developers of other apps reported the same thing at the same time. Google's public report page (firebase-ios-sdk #16728) gives the same start time.
- It stopped when Google reverted it. Without any change to the apps, reports fell from about 11:20 and the last one was at 11:47.
Effect on your data
The crash happened inside analytics processing that runs behind the screen you are using. In what I could check, there were no reports, by contact form or by email, of saved videos or images being lost because of this. However, if you were in the middle of saving or converting at the moment of the crash, that work may have had to be redone. If something is wrong, please contact me.
What comes next
- For now: I confirmed Google removed the cause and I am keeping the component. Crash reporting (Crashlytics) is essential for fixing bugs quickly.
- If it happens again: I have a procedure to remove only the usage analytics component (Firebase Analytics) and keep crash reporting. Because there are reports of crashes even with it turned off, the plan is to remove it entirely rather than disable it.
- Noticing sooner: I watch crash counts on an admin page, and a once-a-day automatic check emails me when they jump above the usual level (the average from 8 to 15 days earlier). This time the notice came after it had stopped. A once-a-day check cannot catch it while it is happening.
Terms
- Firebase / Crashlytics: Components Google provides to developers. They automatically collect clues about why an app crashed.
- Firebase Analytics: The part of Firebase that counts how the app is used. This is where it crashed.
- Crash: The app closing unexpectedly.
Source of numbers: Firebase Crashlytics BigQuery export (counted on October 5, 2026). The export has no figure for how many people use the app, so I cannot say "what percent of everyone". Only counts of crashes and devices are shown.