A web app leans on timers, polling, and sync to stay alive — chat ticks, dashboards refresh, uploads finish, tokens renew. Inside a WebView that contract breaks the instant the app goes to the background. Android WebView pauses JavaScript when the activity pauses; pauseTimers() freezes every timer across the process; and on iOS, Apple's own engineers confirm a WKWebView's JavaScript "just pauses/freezes" when the app backgrounds — by design. There is no WebView-side Background Fetch, no Background Sync, no keep-alive. A host-owned runtime provides a real background task bridge — native scheduling, server-pushed deltas, and foreground checkpoints — so the experience survives the app going to the background.
The app backgrounds, and the page goes dark
On Android, WebView.onPause() pauses animations and geolocation, and the documented lifecycle pairs it with pauseTimers(), which stops "all WebView's layout, parsing and JavaScript timers" globally. Once the app is backgrounded, setInterval callbacks, fetch retries, and long tasks stop firing. On iOS the answer is blunter: a Frameworks Engineer reply on the Apple Developer Forum states this is "by design, for the same reasons any app that is suspended no longer gets to execute code," with only "a few seconds" of grace since iOS 13. WKWebView must even be attached to the view hierarchy to run JavaScript at all, and off-screen or backgrounded instances simply idle out.
No background fetch, no background sync
The web platform's answers to going offline-then-back — Background Fetch, Background Sync, and Periodic Background Sync — are absent inside a WebView. Even where a standalone browser supports them, the WebView does not bridge them to the OS. So an H5 that queues a failed upload to "retry when online" has nothing to wake it; a chat that polls every three seconds simply stops; a token refresh scheduled with setTimeout fires late or never.
What you lose when the page freezes
- Realtime stalls. Chat, presence, and live dashboards stop updating the moment the user switches apps.
- Uploads and sync abort. In-flight requests and queued writes never complete or retry.
- Tokens expire silently. A refresh scheduled in-page fires hours late, after the session already died.
- Retry loops die. Exponential-backoff timers are frozen, so recovery only happens on the next open.
- No offline-first guarantee. Service Worker background sync is unavailable in WebView (see the Silent Inbox piece), and the page cannot compensate.
The runtime fix
A host-owned runtime moves background work off the page. It provides a native task bridge below the WebView: the host schedules bounded background work through the platform's background-task APIs, pushes deltas to the page on foreground, and checkpoints state before the app suspends. The H5 keeps its timers for foreground use, but the runtime guarantees the work actually happens — resumable, observable, and not at the mercy of the engine's idle pause.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Background JS | Frozen by design | Native scheduling |
| Timers (setInterval) | Stop when paused | Bridge resumes on foreground |
| Background Fetch / Sync | Not available | Server-pushed deltas |
| iOS WKWebView | Suspended, seconds of grace | Host task, independent |
| Upload / sync retry | Dies in background | Queued + resumed |
| State checkpoint | None | On suspend / resume |
A browser tab can rely on the platform to keep its work alive. A stock WebView cannot. A runtime gives the page a background it can trust — one where going to the home screen does not mean going dark.
Sources
- Apple Developer Forums — WKWebView javascript execution when app is in background — Apple engineer: suspension "by design."
- AOSP — WebView lifecycle best practices (Chapter 45) — onPause/pauseTimers freeze all JS timers.
- Stack Overflow — WKWebView doesn’t run JavaScript when on background — WebView must be in the view hierarchy to execute.
- MDN — Background Synchronization API — the web answer WebView does not bridge.
- Apache Cordova — background JS unreliable in WKWebView — iOS pauses, Android not guaranteed.
