Quick answer: Corrupted save files almost always result from a save write being interrupted partway, by a crash, power loss, app kill, or storage removal, leaving a half-written, invalid file. The definitive fix is atomic writes: write the new save to a temporary file and only rename it into place once the write fully completes, so an interruption leaves the previous good save intact. Add backups and validation as additional safety nets against corruption.
Save corruption is one of the worst things that can happen to a player, their progress is destroyed, and it generates fury and refunds. The good news is that corruption has a well-understood primary cause and a well-established fix. Most corruption isn't random; it's a half-completed write, and writing saves atomically prevents it almost entirely.
Why Saves Get Corrupted
The dominant cause of save corruption is an interrupted write. When the game saves, it writes data to the file; if that write is interrupted partway, by a crash during saving, the app being killed, power loss, the player closing the game mid-save, or removable storage being pulled, the file is left half-written: partial, inconsistent, invalid. That partially-written file is the corruption, and it then fails to load (or loads as garbage).
Other causes are less common but exist: bugs that write invalid data, or storage-level corruption. But the overwhelming majority of save corruption is the interrupted-write scenario, which is why the fix centers on making writes safe against interruption. A telltale sign is corruption that appears after crashes or force-quits, the interruption corrupted the save in progress.
How to Diagnose It
Corrupted saves show up as load failures (deserialization errors) or as garbage/inconsistent loaded state, and they often correlate with prior crashes or force-quits (the interruption that caused them). If players report lost progress after a crash, or saves failing to load, suspect corruption from interrupted writes. The downstream symptoms, load crashes, crash loops on launch (loading a corrupt save), lost progress, all trace back to the corrupt file.
Bugnet captures crashes and reported issues with context and device info, so a pattern of load failures or crash loops correlated with prior crashes (and concentrated where writes get interrupted, e.g. devices with removable/managed storage) points at save corruption. Because corruption destroys player data, prioritize it highly regardless of how many reports you see, each one is a player who lost progress.
How to Fix It
Write saves atomically, this is the key fix. Instead of writing directly over the existing save, write the new save to a temporary file, ensure it's fully flushed to disk, and only then rename (atomically replace) it into the real save location. That way, if the write is interrupted, the temporary file is incomplete but the real save is untouched, so an interruption can never corrupt the actual save. The player keeps their previous save instead of losing everything.
Add defenses: keep a backup of the previous save (so even if the latest is somehow bad, you can fall back), validate saves on load and handle invalid ones gracefully (and optionally use a checksum to detect corruption), and handle storage-removal and write failures cleanly. For players who already have corrupted saves, falling back to a backup recovers them. After implementing atomic writes, verify that crashes/force-quits during saving no longer corrupt the save, and watch corruption-related load failures disappear. Atomic writes plus backups make save corruption a largely solved problem.
Save corruption is almost always an interrupted write leaving a half-written file. Write atomically, temp file then rename, so an interruption never touches the real save. Add backups too.