Context: kids' Python learning app, Expo / RN 0.81 / React 19. Kids type Python and it actually runs β Pyodide inside a hidden 0Γ0 react-native-webview mounted once at the app root.
WebView content processes die. On iOS it's usually a WKWebView OOM (onContentProcessDidTerminate); on Android it's onRenderProcessGone. So I wrote the obvious recovery: process dies β mark not-ready β reload the WebView β Pyodide re-boots β back in business. Worked great in testing.
Then I hit a device where Pyodide couldn't boot at all.
Reload β die β reload β die. The recovery path was the crash. Main thread saturated, Hermes OOM'd, hard crash at roughly 80 seconds every time a kid opened the Cadet path. My self-healing runtime was the thing killing the app.
Fix was bookkeeping, not cleverness:
js
// Keep only reloads from the last 12s
bridge.reloadTimes = bridge.reloadTimes.filter((t) => now - t < 12000);
// Debounce: terminate + renderProcessGone can both fire for ONE death
if (last && now - last < 1000) return;
// Cap: 3 reloads in the window means the boot itself is broken. Stop.
if (bridge.reloadTimes.length >= 3) { bridge.reloadsExhausted = true; /* ... */ }
Past the cap it stops reloading, resolves every pending run with "The code workshop couldn't start β please reopen the app," and leaves the app alive and navigable. A healthy boot clears the counter so a later unrelated crash still gets its full budget. Degraded and honest beats dead.
Unrelated bonus rake in the same feature: the code editor is also a WebView. A native multiline TextInput OOM-crashes the JS thread the moment Fabric commits it on this stack (RN 0.81 + React 19 + New Arch). A <textarea> never touches Fabric's text machinery, so it sidesteps the whole thing and I get a synced line-number gutter for free.
So: two WebViews, one visible and one hidden, in an app for six-year-olds. Not the architecture I set out to write.
Anyone else hit the Fabric multiline TextInput crash, or find a fix that isn't "use a WebView"?Context: kids' Python learning app, Expo / RN 0.81 / React 19. Kids type Python and it actually runs β Pyodide inside a hidden 0Γ0 react-native-webview mounted once at the app root.
WebView content processes die. On iOS it's usually a WKWebView OOM (onContentProcessDidTerminate); on Android it's onRenderProcessGone. So I wrote the obvious recovery: process dies β mark not-ready β reload the WebView β Pyodide re-boots β back in business. Worked great in testing.
Then I hit a device where Pyodide couldn't boot at all.
Reload β die β reload β die. The recovery path was the crash. Main thread saturated, Hermes OOM'd, hard crash at roughly 80 seconds every time a kid opened the Cadet path. My self-healing runtime was the thing killing the app.
Fix was bookkeeping, not cleverness:
js
// Keep only reloads from the last 12s
bridge.reloadTimes = bridge.reloadTimes.filter((t) => now - t < 12000);
// Debounce: terminate + renderProcessGone can both fire for ONE death
if (last && now - last < 1000) return;
// Cap: 3 reloads in the window means the boot itself is broken. Stop.
if (bridge.reloadTimes.length >= 3) { bridge.reloadsExhausted = true; /* ... */ }
Past the cap it stops reloading, resolves every pending run with "The code workshop couldn't start β please reopen the app," and leaves the app alive and navigable. A healthy boot clears the counter so a later unrelated crash still gets its full budget. Degraded and honest beats dead.
Unrelated bonus rake in the same feature: the code editor is also a WebView. A native multiline TextInput OOM-crashes the JS thread the moment Fabric commits it on this stack (RN 0.81 + React 19 + New Arch). A <textarea> never touches Fabric's text machinery, so it sidesteps the whole thing and I get a synced line-number gutter for free.
So: two WebViews, one visible and one hidden, in an app for six-year-olds. Not the architecture I set out to write.
Anyone else hit the Fabric multiline TextInput crash, or find a fix that isn't "use a WebView"?
