iOS 15.4.1 - Control UI fails to load with "Control UI did not start"

Summary

Control UI loads correctly on desktop (Chrome/Safari) and Android, but iOS 15.4.1 (both Safari and in-app WebView, e.g. fnnas app) shows "Control UI did not start" — the Lit openclaw-app custom element never registers, hitting the 12-second fallback timeout.

Environment

What I've tried

• Increased data-openclaw-mount-timeout-ms to 60s — no difference
• Clicked "Keep waiting" — still fails
• Direct access via http://<nas>:48415/... — server binds to loopback only (NAS restriction)
• The HTML page loads (styles render), but JS execution fails silently

Investigation

Scanned the bundled JS for iOS 15 compatibility:

1. replaceChildren — used 1 time, requires iOS 16+
2. structuredClone — used 1 time, requires iOS 16+ on main thread
3. Object.hasOwn — used 6 times, OK on iOS 15.4+
4. import.meta.url — used extensively for dynamic chunk imports
5. <link rel="modulepreload"> — 6 preload links, iOS 15 has incomplete support

The top-level index-DRTyMBOr.js is a ∼1MB ES Module bundle. iOS 15.4.1 WebKit is more strict than desktop Chrome/Safari about MIME type checking for ES Modules. The NAS reverse proxy rewrites Content-Type to text/plain for all proxied assets, but this alone shouldn't cause complete failure since:

• Chrome/Safari on desktop tolerate text/plain
• Android WebView tolerates text/plain
• iOS 15.4.1 may NOT tolerate text/plain for module scripts

However, since the owner reports that the page correctly shows OpenClaw branding (CSS loads), the HTML is served correctly. The issue is specific to JS execution.

Likely root cause

Two possibilities (or combination):

1. replaceChildren throws TypeError in iOS 15.4.1, which if called during component registration in Lit, would prevent openclaw-app from being defined
2. iOS 15.4.1 WKWebView rejects module scripts with incorrect Content-Type, causing the entire bundle to fail to parse

Request

• Add iOS 15 support (or graceful degradation) to the Control UI build
• Consider adding a nomodule fallback script for older browsers
• If replaceChildren is the culprit, a polyfill would fix this
• Alternatively, document minimum iOS version requirement if support cannot be added

Workaround for users

Use an Android phone or desktop browser to access Control UI until iOS 16+ is available.