What causes iOS Safari reloading or killing web games?

The tab exceeded iOS's tight memory limits — big textures and audio buffers, WebGL contexts holding large allocations, or leaks that grow until Safari reloads the page and eventually gives up with this message.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix iOS Safari Killing Your Web Game (“A problem repeatedly occurred”)

Quick answer: Cut peak memory hard for iOS (texture sizes, audio decode strategy), fix leaks, and test on real iPhones — the limits are far below desktop and below most Android devices.

Safari's memory watchdog reloads heavy pages, and after repeated reloads it shows this message. Web games hit it via textures and audio. iPhone-first budgeting is the fix. Here is where the memory goes.

How to fix it

1. Budget textures for iOS

Cap texture resolution on iOS (device-detect or WebGL limits probing), compress atlases, and free GPU resources on scene changes — a few 4096 atlases can be the whole budget on older iPhones.

2. Stream, don't decode, audio

Decoded audio buffers are huge (a 3-minute track decodes to ~30MB) — stream music via media elements and reserve WebAudio buffers for short SFX.

3. Prove the leak curve

Play a loop for 10 minutes with Safari's memory instrumentation (or navigator.deviceMemory-tiered telemetry): steady growth means leaks — usually undisposed textures, contexts, or ever-growing arrays.

4. Test the floor device

The oldest iPhone you support is the real constraint — a 5-minute session there before each release catches regressions your desktop and Android tests never will.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every HTML5 error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Ship the fix, watch the signature disappear from the next build. That's how you know it's really gone.