iOS/iPadOS 26.x: foreground WKWebView app left *suspended* after long background — frozen until force-quit (root-caused to an OS RunningBoard/WebKit suspend-resume bug, not Capacitor)

[stevestarck]

Sharing this in case others are hitting it, because it took a while to pin down and it is not the failure mode you'd assume.

Symptom. After the app sits backgrounded for a few hours, you return to it and it's frozen — content is fully drawn, but nothing responds: buttons stuck mid-animation, taps do nothing, no crash. A force-quit + relaunch is the only recovery. Device stays cool (not a CPU spin).

What it is NOT. This is not the usual WKWebView content-process reclaim. Capacitor's WebViewDelegationHandler.webViewWebContentProcessDidTerminate → bridge.reset() + webView.reload() never fires here, because the content process is never terminated. I added a swizzle to log that delegate callback, plus a JS↔native heartbeat watchdog, and got nothing from a frozen device — which turned out to be the clue.

Root cause. I captured a sysdiagnose while the app was frozen (volume-up + volume-down + top button). Two files from the same capture contradict each other:

• RunningBoard_state.log: the app and its WebKit.WebContent / GPU / Networking processes are all role: UserInteractiveFocal — i.e. the OS considers the app the frontmost, user-interactive app.
• spindump-nosymbols.txt: those same processes are suspended and idle — ~0.004s CPU, main thread parked in CFRunLoop → mach_msg, and Time Since Fork ~23h (same process, never reloaded).

So the OS marks the app frontmost/focal but leaves the process suspended and never resumes it. It's an OS-level suspend/resume failure, not anything in our JS or in Capacitor.

Why you can't self-heal it. When the whole app process is suspended, everything inside is suspended too — your JS, and any native watchdog timer. There is no in-app hook that can detect or recover this mode; a suspended process cannot reload itself. (This is also why field telemetry shows nothing for it.)

Scope. I've captured it on an iPad Air (M3), iPadOS 26.6 (23G71); I've also seen matching foreground freezes on my iPhone. Because the contradiction is at the OS process-lifecycle level, I suspect it can hit any WKWebView-based app on 26.x — but I've only confirmed it in my own Capacitor app, so I won't overstate that.

Filed. Apple Feedback Assistant (FB24270705, sysdiagnose attached) and WebKit Bugzilla (321511).

Ask. Has anyone else seen foreground freezes on iOS/iPadOS 26.x that produce no content-process-termination? If you can grab a sysdiagnose while frozen and compare the RunningBoard role vs. the process state in the spindump, corroboration/dupes would help Apple prioritize. Happy to compare notes.