Reliable testing for shared AR sessions on smart glasses

Time needed about 30–45 minutes for a focused demo; allow a loaner week for full validation

The steps

1. Prepare devices and appInstall and sign in to the vendor app on every device, enable camera and motion permissions, and connect all devices to the same Wi‑Fi or hotspot.You should see: Each device shows the app's shared‑session screen with a clear 'ready' or 'join session' indicator.
2. Place an anchorParticipant A creates an anchor in a visible, well‑lit spot following the app's placement flow.You should see: Participant B immediately sees a marker or virtual object at the same physical location and orientation.
3. Walk to check driftParticipant A walks 3–5 metres around the anchor at a steady pace while both users watch for 30–60 seconds.You should see: The anchor remains fixed relative to the room on all devices with only small, correctable jitter and no creeping offset.
4. Add a same‑model user and test syncAdd Participant C using the same device model as A and have C manipulate the object (rotate or scale) while others observe.You should see: C's manipulations appear on A and B with minimal visual lag and the object stays in the same physical spot.
5. Add a mixed‑device user and test alignmentAdd Participant D on a different model or an Android XR device and have D view and manipulate the anchor.You should see: D sees the anchor at the same physical spot and manipulations reflect without large offsets or re‑scaling.
6. Annotate and manipulate objectsOne user places an annotation or label and another moves the object; repeat in different orders while recording.You should see: Annotations and transforms appear on all devices in the same place and order, matching the latency you measured on camera playback.
7. Test occlusion and scalePlace the anchor next to a real object and move so cameras naturally occlude parts of the virtual object.You should see: Occlusion behaves consistently across devices and virtual object size matches real‑world proportions across viewports.
8. Simulate disconnect and reconnectionTurn off Wi‑Fi or enable airplane mode on one device for 10–30 seconds, then restore the connection or restart the app.You should see: The returning device rejoins the session and finds the same anchor in the original place without requiring re‑placement.

How to run a focused demo that proves shared AR works

Run a tight 6–8 step hands‑on checklist during a 20–30 minute demo. Verify anchor placement and alignment first, then test drift while moving, same‑model and mixed‑model viewpoint sync, annotation/object sync, occlusion and scale, reconnection/persistence, and latency under a throttled network. Require the vendor to repeat failures until you observe a pass.

• Use the vendor's recommended app for shared sessions.
• Bring the device mix you expect in production: same model and mixed models.
• Allocate time to simulate a poor network and repeat a reconnection test.

The 6–8 checks to run and how a pass looks

Run checks in this order: anchor placement and alignment, drift with motion, same‑model viewpoint sync, mixed‑device viewpoint sync, object/annotation sync, occlusion and scale, reconnection/persistence, and throttled‑network latency. A pass is an observable, repeatable result for each check, not a vendor claim.

• Anchor placement & alignment — pass: both users see the anchor at the same physical position and orientation.
• Drift — pass: anchor remains fixed to the room while one user walks 3–5 metres and during a one‑minute active session.
• Same‑model viewpoint sync — pass: manipulations on one device appear on the other with minimal visual lag.
• Mixed‑device viewpoint sync — pass: a different model shows the anchor at the same position without large offset or re‑scaling.
• Annotation/object sync — pass: labels and transforms appear in the same place and order on all devices.
• Occlusion and scale — pass: virtual objects are occluded by the same real objects and match real‑world size across viewports.
• Reconnection/persistence — pass: after a short network drop or restart the device rejoins and finds the anchor in place.
• Latency under throttling — pass: annotations and manipulations update within the practical limits you measured.

Device and OS mixes to insist the vendor demonstrates

Require demos of same‑model, different‑model, and headset‑or‑phone plus glasses mixes. If your fleet mixes iOS and Android XR, insist on an iOS vs Android XR demo. Mixed testing commonly fails because sensor stacks, coordinate systems and cloud anchors differ between models and platforms.

• Same model: baseline control; stop if this fails.
• Different model: tests SDK and sensor interoperability.
• Headset or phone + glasses: tests UI, scale and mirroring differences.
• iOS vs Android XR: insist on a demo if you will mix those platforms.

Network and cloud dependencies to confirm and how to simulate poor links

Confirm whether anchors are local/P2P, vendor cloud, or platform services (check the maker support page or app listing). Ask whether internet is required for session continuity and whether anchors can be exported. Simulate poor networks with a mobile hotspot or a configurable AP that can limit bandwidth and add packet loss.

• Local P2P anchors: lower latency but often limited to same‑model or same network.
• Vendor cloud anchors: require internet and add latency and residency concerns.
• Platform anchors: check vendor support and export options in the app listing.
• Simulate packet loss and bandwidth caps and observe whether anchors persist and handoffs succeed.

How to measure latency during the demo and which thresholds matter

Measure end‑to‑end latency by recording both viewports while performing a visible action (tap to create a dot or annotation) and comparing frames. Use an external camera to capture both screens at once, step through frame‑by‑frame, and convert frames to milliseconds by dividing by the camera frame rate.

• Under 80 ms is near real‑time; 80–200 ms is usable for walkthroughs; above 200 ms causes misaligned annotations and awkward manipulation.
• Record both displays once per check to create objective evidence.
• Require the vendor to repeat the action three times for a stable sample.

Operational checks vendors often omit

Ask about session size limits, session recovery after disconnect, battery and thermal impact during long sessions, enterprise/MDM support, and data residency for anchors and logs. These determine whether the solution works for a full training day, not just a demo.

• Session size: vendor must state limits and demonstrate practical operation.
• Recovery: vendor must show reconnection without re‑placing anchors.
• Battery/thermal: observe for throttling in a 20–30 minute run.
• MDM/enterprise: confirm configuration, remote wipe and update paths.
• Privacy: request documentation on anchor data residency and recording indicators.

Common failure sequence and how to respond

Typical failures unfold as: anchors appear, drift on motion, mixed devices show offsets, and reconnect wipes anchors. Run reconnection and mixed‑device checks early to avoid wasting time on polished but brittle demos. If you see a failure, ask the vendor to reproduce it three times and to name the anchor service used.

• Fail fast: mixed‑device misalignment often kills projects.
• Drift with motion points to weak sensor fusion or insufficient anchor updates.
• Anchor loss on reconnect indicates cloud‑only or non‑persistent anchors.

After the demo: next steps to validate a candidate

Run the same checklist on every candidate model, record the evidence, and schedule a loaner period to repeat the tests in your target environment with representative users and devices. Cross‑check vendor claims about apps and anchor/cloud options in our apps directory and device pages such as Android XR and the XREAL Air 2 Ultra listing.

• Repeat the checklist per candidate model.
• Collect recorded latency measurements and reconnection logs.
• Compare app support and anchor/cloud policies in the apps directory.

Sources and further reading

• OpenXR's new spatial containers let several XR apps share one space — Google News
• I've never owned smart glasses, but Samsung's Android XR glasses may change that — Google News

Where this usually goes wrong

• Anchor shifts slowly when a user walksInsufficient anchor updates or weak sensor fusion between inertial sensors and visual trackingRequest live logs and retry with a same‑model device; if drift persists, rule the solution out for mobile training scenarios
• Different model shows the anchor metres off or at wrong scaleIncompatible anchor formats or missing cross‑platform translation between coordinate systemsAsk for the anchor standard (platform, vendor cloud) and an export/migration demo; treat mixed‑device support as unproven if unsupported
• Annotations arrive late or jump during manipulationHigh end‑to‑end latency from cloud routing or poor network conditionsMeasure visual latency using recorded dual‑viewport playback and ask the vendor to show a local‑anchor or lower‑latency configuration
• Anchor disappears after a restart or short network lossAnchors stored only in volatile cache or tied to a temporary cloud session without persistenceInsist on a documented persistence policy and a reconnection demo; mark the solution risky if the vendor cannot show persistence
• App reduces graphics quality or disconnects after 20–30 minutesThermal or battery management reducing tracking fidelity under sustained loadRun a 20–30 minute session and observe; if quality drops, ask the vendor for session limits or recommended mitigation

The checklist

• Prepare devices and app
• Place an anchor
• Walk to check drift
• Add a same‑model user and test sync
• Add a mixed‑device user and test alignment
• Annotate and manipulate objects
• Test occlusion and scale
• Simulate disconnect and reconnection

Frequently asked questions