Decide: does orientation bypass the bridge via DeviceOrientationEvent in the WebView? #17

New Issue

2026-08-11T15:58:29Z

lars commented

2026-08-11 15:58:29 +00:00

Question

Surfaced by #3's second addendum. prototyping-session.md assumes device orientation is read natively with expo-sensors and pushed into the WebView with position. But WKWebView supports DeviceOrientationEvent/DeviceMotionEvent natively, so the WebView could read orientation itself with zero bridge hops — and orientation is the DoF the eye notices most when it lags.

The trade:

Bypass (web-side orientation). No bridge cost for 3DoF. Costs a patch to react-native-webview — it doesn't implement requestDeviceOrientationAndMotionPermissionForOrigin, so iOS 15+ re-prompts forever (#3408); the fix is one method returning WKPermissionDecisionGrant, widely used but unmerged. A patched dependency is a maintenance liability and must be recorded as such.
Native-side orientation (as originally planned). One source of truth for the whole pose, no patched dependency, and orientation stays fusable with ARKit's tracking — but every update pays the ~10ms channel floor.

Settle:

Which path Session 1 takes, and whether the answer differs for the prototype versus a shipped app.
If bypassing: how web-side orientation and native-side position stay time-aligned — two sources with different clocks and rates, and a visible mismatch between where the camera points and where it stands.
Whether this splits the pose contract (#7) into two independently-delivered parts, which would be a real change to its shape.
Whether ARKit's own orientation (already fused, drift-corrected, and needed anyway for #15's origin story) makes the bypass moot — VIO gives orientation and translation from one source, and mixing in a second orientation estimate may be strictly worse.

Note the interaction with #15: if ARKit is the positioning system, orientation arrives with it for free, and this decision may collapse. Decide it after #16 has numbers.

Part of the wayfinder map #1.

## Question Surfaced by #3's second addendum. `prototyping-session.md` assumes device orientation is read natively with `expo-sensors` and pushed into the WebView with position. But **WKWebView supports `DeviceOrientationEvent`/`DeviceMotionEvent` natively**, so the WebView could read orientation itself with **zero bridge hops** — and orientation is the DoF the eye notices most when it lags. The trade: - **Bypass (web-side orientation).** No bridge cost for 3DoF. Costs a **patch to `react-native-webview`** — it doesn't implement `requestDeviceOrientationAndMotionPermissionForOrigin`, so iOS 15+ re-prompts forever ([#3408](https://github.com/react-native-webview/react-native-webview/issues/3408)); the fix is one method returning `WKPermissionDecisionGrant`, widely used but unmerged. A patched dependency is a maintenance liability and must be recorded as such. - **Native-side orientation (as originally planned).** One source of truth for the whole pose, no patched dependency, and orientation stays fusable with ARKit's tracking — but every update pays the ~10ms channel floor. Settle: - Which path Session 1 takes, and whether the answer differs for the prototype versus a shipped app. - If bypassing: how web-side orientation and native-side position stay **time-aligned** — two sources with different clocks and rates, and a visible mismatch between where the camera points and where it stands. - Whether this splits the pose contract (#7) into two independently-delivered parts, which would be a real change to its shape. - Whether ARKit's own orientation (already fused, drift-corrected, and needed anyway for #15's origin story) makes the bypass moot — VIO gives orientation *and* translation from one source, and mixing in a second orientation estimate may be strictly worse. Note the interaction with #15: if ARKit is the positioning system, orientation arrives with it for free, and this decision may collapse. Decide it after #16 has numbers. --- Part of the wayfinder map #1.

lars added this to the Wayfinder: RN prototyping spec milestone 2026-08-11 15:58:29 +00:00

lars added the wayfinder:grilling label 2026-08-11 15:58:29 +00:00

lars added a new dependency 2026-08-11 15:58:29 +00:00

#16 Measure the RN → WebView pose-bridge latency

lars added a new dependency 2026-08-11 15:58:29 +00:00

#14 Write the Session 1 spec (pose to splat rendering)

lars commented

2026-08-11 16:00:28 +00:00

The calculus for this decision has weakened — read #3 addendum 3 before working it.

This ticket was created because the bridge looked expensive (~10ms per call). That figure is Android-only; on iOS evaluateJavaScript is ~0.2–1.5ms one-way. So the bypass buys perhaps a millisecond, against the cost of a patched react-native-webview carried indefinitely.

That likely settles it toward no bypass — but two things still deserve deciding here:

If ARKit is the positioning system (#15), orientation arrives fused with translation from one source. A second, independent web-side orientation estimate would then be strictly worse, not cheaper. This may collapse the ticket entirely.
The genuinely useful part survives: whatever the orientation source, prediction must happen inside the WebView, since WKWebView has no late-warp hook. That is an architecture requirement regardless, and it belongs in #14 rather than here.

Consider resolving this as "no bypass, and here's why" rather than as an open trade — it may be a five-minute close once #15 and #16 land.

**The calculus for this decision has weakened — read #3 addendum 3 before working it.** This ticket was created because the bridge looked expensive (~10ms per call). That figure is **Android-only**; on iOS `evaluateJavaScript` is ~0.2–1.5ms one-way. So the bypass buys perhaps a millisecond, against the cost of a **patched `react-native-webview`** carried indefinitely. That likely settles it toward *no bypass* — but two things still deserve deciding here: 1. If **ARKit is the positioning system** (#15), orientation arrives fused with translation from one source. A second, independent web-side orientation estimate would then be strictly worse, not cheaper. This may collapse the ticket entirely. 2. The genuinely useful part survives: **whatever the orientation source, prediction must happen inside the WebView**, since WKWebView has no late-warp hook. That is an architecture requirement regardless, and it belongs in #14 rather than here. Consider resolving this as "no bypass, and here's why" rather than as an open trade — it may be a five-minute close once #15 and #16 land.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Blocks

#14 Write the Session 1 spec (pose to splat rendering)

lars/splat-indoor-navigation

Depends on

#16 Measure the RN → WebView pose-bridge latency

lars/splat-indoor-navigation

Reference: lars/splat-indoor-navigation#17