xr-target-and-engine-selectionlisted

# XR Target & Engine Selection The first and most expensive XR decision: what device class you target and what you build it on. Everything downstream — frame budget, available input, comfort ceiling — is fixed by this choice, so make it deliberately. > **Engineering judgment, device landscape is volatile.** Headset specs, runtime/OpenXR support, and engine XR-feature parity change with every SDK release. Every device/version specific here is `[verify-at-use]` — confirm against the vendor/runtime docs before it drives a build commitment. No PII. ## Workflow 1. **State the use-case and audience.** Training, location-based entertainment, design review, consumer game, and enterprise AR have different fidelity, session-length, and distribution needs. 2. **Pick the device class on the use-case.** Standalone (mobile SoC, untethered, mass reach) vs PC-VR (tethered/streamed, high fidelity) vs WebXR (browser, zero-install, tight budget) vs mobile-AR (phone/tablet, widest install base). The class fixes the perf universe. 3. **Choose the engine on team + target.** Unity (broad XR device reach, C#, mature XR Interaction Toolkit), Unreal (fidelity, C++/Blueprint), native/OpenXR (max control, no engine tax), WebXR (reach, tightest budget). Name the trade — don't default to what the team last used without checking it fits the target. 4. **Commit OpenXR-first.** Build to the vendor-neutral runtime, isolate per-device concerns (passthrough, hand-tracking, controller profiles) behind seams,