fix: prevent iOS WKWebView JS throttling from zero-area frame

[panosinthezone]

Summary

Port of crossmint-sdk#1878 — same root cause, same fix, different platform.

A WKWebView(frame: .zero, ...) causes WebKit to clear ActivityState::IsVisible, which triggers updateThrottleState() → dropVisibleActivity() — the WebContent process loses its foreground assertion and becomes eligible for suspension, timer throttling, and priority termination under memory pressure.

Changes:

• CrossmintWebView.swift: WKWebView(frame: .zero, ...) → WKWebView(frame: CGRect(x: 0, y: 0, width: 1, height: 1), ...) so the backing layer is composited from creation
• View+NonCustodialSigner.swift: .frame(width: 20, height: 20) → .frame(width: 1, height: 1) + .opacity(0) — the previous 20×20 was unnecessary padding; a 1×1 composited layer is sufficient, and .opacity(0) ensures the view is truly invisible while keeping iOS's visibility flag set

WebKit source references: see detailed walkthrough.

Link to Devin session: https://crossmint.devinenterprise.com/sessions/aa42293821a24fee86c25e350715efd5
Requested by: @panosinthezone

[devin-ai-integration]

Original prompt from Panayiotis

#``# Context

In the Crossmint React Native wallets SDK, a hidden WKWebView is used to communicate with a signer relay (TEE). The WebView is rendered in:

Repository: Crossmint/crossmint-sdk
File: packages/client/ui/react-native/src/providers/CrossmintWalletProvider.tsx

Currently, the WebView is hidden using:

• A parent <View> with position: "absolute", width: 0, height: 0, overflow: "hidden" (lines 422-430)
• The <RNWebView> itself styled at width: 1, height: 1 (lines 481-484)

The wrapper component is at:
File: packages/client/rn-window/src/rn-webview/RNWebView.tsx (lines 142-153)

On iOS, the WebView sometimes fails to execute or pull JS code. There are already multiple recovery mechanisms (content process termination handling at lines 443-461, eager handshake at lines 249-272, handshake retry with reload), but the root cause is not well understood.

#``# Task

#``#``# Step 1: Research Apple's official WKWebView documentation

Search Apple's developer documentation (developer.apple.com) and WebKit source code/bug trackers for authoritative answers to these specific questions:

1. Does WKWebView throttle or suspend JavaScript execution when the view has zero visible area? Look for documentation on WKWebView process lifecycle, specifically whether the WebContent process behavior changes based on the view's frame size, visibility, or whether it's clipped by a parent view with overflow: hidden and zero dimensions.

2. What triggers webViewWebContentProcessDidTerminate:? Find the exact documented conditions. Is it only memory pressure? Does view visibility/size factor into the priority heuristic for which WebContent processes get terminated first?

3. Does iOS treat a 0x0 clipped WKWebView differently from a 1x1 visible one? Specifically, does the compositing/rendering layer report the view as "not visible" to the system, and does that affect the WebContent process priority?

4. **Are there any documented WKWebViewConfiguration... (3139 chars truncated...)

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix: prevent iOS WKWebView JS throttling..." | Re-trigger Greptile}