Compatibility and performance checks that keep XR apps stable
XR compatibility is not “it installed”. XR performance is not “it felt fine to the lead engineer”. A headset app is compatible when every claimed runtime maps inputs, tracking, and compositor features the same way the design expects. It performs when frame-time stays inside a budget you wrote down, including after the device is warm. QualityReality’s live services already name compatibility, performance, and user-experience testing for XR apps. This article is the working checklist behind those names.
QualityReality is GameCloud’s XR and Metaverse division. GameCloud is a 16-year-old company. Use the parent catalogue for named test types; run the XR row here.
Compatibility: what has to be true on every claimed runtime
Write the claim as a list of runtimes and optional extensions. Name them. Optional features (hand tracking, eye tracking, passthrough, scene understanding, body tracking) are required, optional-with-fallback, or out of scope. If you do not write the fallback, testers cannot fail it.
Install and identity. Package name, permissions, guardian/boundary, account. A runtime that requires a flatscreen companion is a compatibility row, not a footnote.
Input mapping. The same logical action (grab, fire, teleport, menu, recentre) must be reachable on every claimed controller and on hand tracking if claimed. Log the physical control. “Grab works” is not a result if grab is trigger on one device and squeeze on another without onboarding.
Tracking spaces. Seated, standing, room-scale, unbounded mixed reality. Recentering. Floor height. A title that assumes a large empty playspace will fail in a seated review environment - decide whether that environment is in the claim.
Extension absence. Optional APIs must degrade. If hand tracking is missing, the app must say so and offer controllers, or it must refuse to start with a clear reason. Silent empty hands are a compatibility fail.
System UI and overlays. OS keyboard, permission dialogs, boundary redraw, passthrough peek. If your compositor layer fights the system layer, that is a runtime-compat defect.
Resume and switching. Headset remove, runtime pause, Bluetooth audio connect, IPD change mid-session. Compatibility includes the ugly paths.
Display modes. Refresh-rate options, resolution scaling, mixed-reality camera. A title that only runs at the development-kit default is compatible with one preset, not with the SKU list.
Do not treat “ran on the engineer’s headset” as a matrix. Compatibility is comparative: same script, two or more rows, differences logged.
Performance: budget, then evidence
Pick a frame-time budget from the runtime’s published recommendation for that headset class, or from your own written target. Then measure. Opinions about smoothness are not the report.
GameCloud’s performance testing on Core Services already lists FPS, CPU, GPU, memory, network, and power - use that catalogue when the same title must also hold a frame on PC, iOS, Android, Web, TV, XR and other emerging platforms. On the headset, add the XR-only signals:
- App frame-time vs compositor frame-time. The simulation can be late while the compositor still shows a reprojected frame. Players feel both. Log both.
- Reprojection / spacewarp use. Note when the runtime is synthesising frames. That is a mitigation, not a pass. If the design cannot tolerate artefacts (UI text, fine motion, mixed-reality alignment), treat heavy reprojection as a fail.
- Dropped frames and stagger. A regular pattern is a different bug from a random hitch. Capture a trace, not a single FPS number.
- Thermal fade. Early minutes versus a worn session. Headsets downclock. A five-minute demo is not the session you will ship.
- Tracking load vs rendering load. Dark rooms and busy shaders both cost. Separate them.
- Memory. Soft leaks after several don/doff cycles. XR apps pause and resume more than many flatscreen titles.
- Power. Standalone battery versus tethered. Fine on wall power and unplayable on battery is a performance finding.
- Network, if any. Multiplayer, voice, cloud anchors, content streaming. A stalling asset bundle is still performance.
Name the profiler. The overlay must be off for comfort sessions so it does not contaminate the view.
Comfort is downstream of frame-time
Motion discomfort in XR is not only locomotion design. It is also late frames, unstable world lock, and mismatched IPD. Performance work that ignores comfort will “pass FPS” and still lose testers.
If you change resolution scale to hit the budget, re-run the comfort path. If you enable a comfort vignette, measure GPU cost - a vignette that drops you into reprojection is a failed trade. If you cap simulation rate to save thermals, check controller prediction. Input late by a frame is a grab-fail.
QualityReality’s homepage already treats motion sickness as an XR testing concern. Honour it by recording stop/continue against the performance trace.
A compact script (every claimed runtime, same order)
- Cold install, first boundary, first tutorial. Capture start-up hitch.
- Core loop, default quality, long enough to be a session rather than a glance. Trace on.
- Repeat after the headset is warm.
- Every claimed control, including menu and recentre.
- Disable optional extensions if the build allows it; confirm fallback.
- Resume from headset-off.
- One lighting change for tracking.
- Stop. Export traces. Note any tester stop for discomfort with the minute mark.
If a runtime cannot complete step 1, it is a blocker and the rest of the row is “not run”.
When the title will still change after this snapshot, a one-off matrix is not enough - that is a Game Assurance conversation (iterations and retest), not a single evening on one headset.
Do not claim a global FPS number without the headset, runtime, and quality preset, and do not claim coverage of a runtime that was not in the matrix. Current GameCloud platform language is PC, iOS, Android, Web, TV, XR and other emerging platforms.
QualityReality owns the XR row. GameCloud owns the wider catalogue. For a scoped compatibility/performance pass, write to Sales@GameCloud-Ltd.com with runtimes, the frame-time budget, and whether mixed reality is in the claim.
