Why does my game crash with out-of-memory errors on some devices?

Because its memory footprint exceeds what those devices have. A bloated footprint, often from holding assets and caches you don't currently need, or from a memory leak that grows over time, runs fine on your high-memory machine but triggers out-of-memory crashes on lower-memory hardware. Reducing what you hold resident lets the game fit and run on those devices.

How do I reduce my game's memory footprint?

Unload assets you don't currently need (free them when leaving areas), clear caches, avoid loading everything up front, and check for a memory leak that makes the footprint grow over a session. Capturing memory-related crashes by device shows you where the pressure is worst, and verifying afterward confirms the out-of-memory crashes on low-memory devices actually stopped.

How Do I Handle Out-of-Memory Crashes?

Q: How do I handle out-of-memory crashes?

Capture OOM crashes tagged by device to see which hardware hits them (they mostly affect lower-memory devices you don't test on), reduce your memory footprint by unloading what isn't currently needed and checking for leaks, and verify with field data that the crashes stopped on the affected devices. OOM crashes are invisible on your high-memory dev machine, so capturing them by device is essential.

Quick answer: Capture out-of-memory crashes tagged by device to see which hardware hits them, reduce your memory footprint by unloading what isn't needed and checking for leaks, and verify the crashes stop on the affected devices.

Out-of-memory (OOM) crashes happen when your game uses more memory than the device has, and they mostly hit lower-memory devices you don't test on, so they're easy to miss. Here's how to find and handle OOM crashes before they cost you those players.

See Which Devices Hit OOM Crashes

OOM crashes are invisible on your high-memory dev machine, they only happen on devices with less RAM than your game needs. Capturing crashes tagged by device reveals which hardware hits out-of-memory errors, so you can see a problem that's affecting a segment of players you'd never notice otherwise.

Bugnet captures memory-related crashes tagged by device, so OOM crashes on lower-memory hardware surface in your data. Seeing which devices hit them is the first step, you can't handle out-of-memory crashes you don't know are happening on hardware you don't own.

Reduce Your Memory Footprint

Handling OOM crashes means fitting within the memory the affected devices have. Reduce your footprint by unloading assets you don't currently need, freeing caches, and not loading everything up front, and check for a memory leak, which causes footprint to grow until it exceeds the limit.

Bugnet helps you find what's driving memory pressure and whether a leak is involved. Reducing the resident footprint is the core fix for OOM crashes, holding only what the current moment needs lets your game fit and run on lower-memory devices that were crashing.

Verify the Crashes Stop

The payoff of a footprint reduction is fewer OOM crashes on lower-memory devices, so verify there. Confirm with field data that the footprint dropped and the out-of-memory crashes on those devices stopped, which tells you the fix reached the players who needed it.

Bugnet captures memory-related crashes by device, so you can confirm OOM crashes on low-memory hardware actually went away. Handling out-of-memory crashes is seeing which devices hit them, reducing your footprint, and verifying the crashes stopped, which lets your game run where it couldn't before.

Capture OOM crashes by device to see which hardware hits them, reduce your footprint by unloading what isn't needed and checking for leaks, and verify the crashes stop. OOM mostly hits low-memory devices you don't test.