VR and AR Development: Anti-Patterns, Numbers, the Platform Landscape, and Resources

Part 5 of 5 of the VR and AR Development reference (plugin vr-ar-development), covering §12–§17. Sibling skills: xr-perceptual-constraints-displays-and-tracking (§0–§3), xr-rendering-input-and-spatial-understanding (§4–§6), xr-platforms-audio-and-comfort (§7–§9), xr-ux-design-and-performance-budgeting (§10–§11). Section numbers are shared across the set; a reference written as §N → skill points into that sibling skill.

Currency: The perceptual constraints are human physiology and permanent; the platform and hardware landscape moves fast. See §14 below for the current picture.

Scope. Assumes a graphics reference for the rendering fundamentals (rasterization, PBR, the rendering equation) and a computer-vision reference for SLAM and multi-view geometry. This is the XR-specific layer built on top of both.

⚠️ GOTCHA boxes mark what makes users physically ill or breaks presence.

The three facts that make XR its own discipline:

1. ⚠️ You are rendering to a nervous system, not a screen. The frame budget is set by human perception, and missing it doesn't drop quality — it makes people nauseated (§1 → xr-perceptual-constraints-displays-and-tracking). No other software has this property.
2. ⚠️ Latency is the master constraint and it is not a performance metric. Motion-to- photon under ~20 ms is the consensus threshold, and it governs your entire architecture (§1.1 → xr-perceptual-constraints-displays-and-tracking).
3. ⚠️ Presence is fragile and asymmetric. It takes sustained correctness to build and one bad frame, one wrong-scale object, one mistracked hand to destroy. Everything in §9 → xr-platforms-audio-and-comfort and §10 → xr-ux-design-and-performance-budgeting is about protecting it.

§12. Anti-Patterns

§13. Numbers

LATENCY  ⚠️ THE CONSTRAINT
Motion-to-photon target      <20 ms  ⚠️ the consensus rule
Gaze-to-photon (foveation)   42–91 ms tolerable; artifacts unchanged under ~60 ms
                             ⚠️ a different, looser budget than head MTP

FRAME BUDGET
72 Hz → 13.9 ms · 90 Hz → 11.1 ms · 120 Hz → 8.3 ms   ⚠️ for BOTH eyes
Low persistence illumination ~2 ms

OPTICS
⚠️ Human acuity ~60 PPD (the "retinal" target)
Render target typically 1.2–1.4× display resolution (distortion headroom)
IPD range ~54–72 mm typical adult

SENSORS
IMU ~1000 Hz, low latency, ⚠️ unbounded drift
Camera/SLAM 30–60 Hz, drift-free, ⚠️ high latency
→ fuse for both (§3)

UX
Comfortable content depth ~0.5–20 m · reading sweet spot ~1–3 m
Primary content within ~±30° of forward gaze
⚠️ Looking up is worse than looking down

§14. The Platform Landscape — verified August 2026

⚠️ GOTCHA — this section decays fastest in the document, and the sourcing is weaker than the rest. Much of what follows comes from XR trade press, vendor blogs, and development agencies marketing their services. ⚠️ The structural picture is corroborated across sources; specific prices, percentages and roadmap dates are not measurements. Verify before making a platform commitment. §1–§11 → xr-perceptual-constraints-displays-and-tracking, xr-rendering-input-and-spatial-understanding, xr-platforms-audio-and-comfort, xr-ux-design-and-performance-budgeting do not depend on any of it.

14.1 The three-platform picture

⚠️ The consistent framing across sources is that platform choice follows use case, not quality:

• Meta Quest — ⚠️ the installed base and mature catalogue; the default for scale and lowest per-seat cost. One trade study found Meta or Quest referenced in 38% of XR stories over a four-month 2026 window, more than the next two companies combined. ⚠️ Horizon OS still favours Meta's own hardware and store, though it does support OpenXR.
• Apple Vision Pro / visionOS — ⚠️ vertically integrated, premium fidelity; the pick for visualization, design review and executive demos. ⚠️ Coverage in 2026 has been substantially retreat-flavoured — a reduced headset roadmap and cancelled products are reported, alongside a 2025 refresh with an upgraded processor and improved headstrap.
• Android XR (Google + Samsung + Qualcomm) — ⚠️ the fastest-rising, and reported as the #2 platform by coverage share. Runs standard Android apps, supports Unity 6, OpenXR 1.1 and WebXR, with Samsung Galaxy XR shipping and XREAL glasses in the ecosystem. The explicit strategy is the Android playbook applied to XR.

Also: Valve's Steam Frame announced, PICO (Project Swan flagship indicated for late 2026), Varjo for high-end enterprise/simulation, HoloLens 2 in maintenance mode with enterprise hardware like HMS SiNGRAY G2 positioned for that gap. ⚠️ And the sector is volatile — one source notes four VR studios closing within a single week in 2026.

⚠️ Smart glasses are the growth story, not headsets: reported at 42% of XR coverage, with Meta's Ray-Ban line including a display model. Displays are OLED-on-silicon near-term with MicroLED in development.

14.2 ⚠️ The genuinely actionable finding — OpenXR and WebXR

This is the part I'd act on regardless of how the hardware race resolves.

• ⚠️ OpenXR is the hedge. Applications built against it run on any conformant headset unmodified; Unity and Unreal both recommend it; Android XR supports OpenXR 1.1, which means the same rendering pipeline reaches Quest. ⚠️ A multi-platform program is increasingly the realistic answer, which is exactly the argument for an OpenXR-based, engine-portable strategy now.
• WebXR adoption reportedly grew 40% in 2026, with Interop 2026 proposing WebXR as a focus area — meaning browser vendors coordinating to close compatibility gaps. ⚠️ One codebase across Quest, Vision Pro, Galaxy XR and phone browsers is a real proposition now, with the usual web trade-offs in performance and device access.

§15. Resources

§16. Quick Reference

16.1 Picker

16.2 Ship checklist

• Native frame rate hit without relying on reprojection? (§4.2 → xr-rendering-input-and-spatial-understanding)
• Frame-time histogram clean — no 1% spikes? (§11 → xr-ux-design-and-performance-budgeting)
• Profiled on device, thermally soaked 20+ minutes? (§11 → xr-ux-design-and-performance-budgeting)
• Tested with users who have never used XR? (§1.2 → xr-perceptual-constraints-displays-and-tracking)
• Comfort options: vignette, snap turn, teleport, seated mode, height? (§9 → xr-platforms-audio-and-comfort)
• Camera never moves without user input? (§1.2 → xr-perceptual-constraints-displays-and-tracking, §10 → xr-ux-design-and-performance-budgeting)
• Text legible on device, not just in the editor? (§10 → xr-ux-design-and-performance-budgeting)
• UI body-locked or diegetic, not head-locked? (§10 → xr-ux-design-and-performance-budgeting)
• Audio head-tracked? (§8 → xr-platforms-audio-and-comfort)
• Tracking-loss and relocalization failure handled gracefully? (§3 → xr-perceptual-constraints-displays-and-tracking, §6 → xr-rendering-input-and-spatial-understanding)
• AR: anchors used, occlusion and contact shadows present? (§6 → xr-rendering-input-and-spatial-understanding)
• Accessibility: seated, one-handed, subtitles, non-stereo fallback? (§9 → xr-platforms-audio-and-comfort)
• Guardian/boundary interaction sane? (§9 → xr-platforms-audio-and-comfort)

§17. Method

§1–§11 → xr-perceptual-constraints-displays-and-tracking, xr-rendering-input-and-spatial-understanding, xr-platforms-audio-and-comfort, xr-ux-design-and-performance-budgeting rest on perceptual research and stable engineering practice — LaValle, Jerald, the platform best-practice documents, and the IEEE VR / ISMAR literature. ⚠️ Human physiology does not version, which is why §1 → xr-perceptual-constraints-displays-and-tracking is the most durable part of this document and the part I'd read first.

Scoped to complement: rasterization, PBR and the rendering equation sit in a graphics reference; SLAM, VIO and multi-view geometry in a computer-vision reference. ⚠️ §3 → xr-perceptual-constraints-displays-and-tracking and §6 → xr-rendering-input-and-spatial-understanding deliberately point at those rather than restating them.

Two searches were run in August 2026: the platform and hardware landscape, and the perceptual thresholds (motion-to-photon, cybersickness factors, VAC, foveated rendering latency).

Confidence. High in §1 → xr-perceptual-constraints-displays-and-tracking — the 20 ms MTP consensus, the four primary cybersickness contributors, the VAC consequence list, and the 42–91 ms foveated-rendering latency tolerance all come from peer-reviewed sources and are consistent across them. ⚠️ The §1.1 → xr-perceptual-constraints-displays-and-tracking point that gaze latency and head latency are different budgets by roughly 3× is worth internalizing and is frequently conflated in practitioner writing. High in §2–§11 → xr-perceptual-constraints-displays-and-tracking, xr-rendering-input-and-spatial-understanding, xr-platforms-audio-and-comfort, xr-ux-design-and-performance-budgeting, which are established practice.

⚠️ §14 is explicitly the weak section and is flagged as such in place. The sourcing is XR trade press, vendor blogs, and development agencies who sell XR services — several of the comparison articles returned are marketing for consultancies. The structural claims are corroborated across independent sources (OpenXR as the portability layer; Android XR rising; Quest holding installed-base advantage; smart glasses growing faster than headsets). ⚠️ The specific figures — the 40% WebXR growth, the 38% coverage share, the 15–25% PolySpatial overhead, prices and roadmap dates — are single-source or vendor-adjacent, and I have attributed rather than asserted them. Verify before committing budget.

§14.2 is the part I'd act on: ⚠️ the OpenXR argument holds regardless of which hardware vendor wins, which is precisely what makes it the safe architectural bet.