ARKit or WebXR? Choosing an AR stack for retail

Almost every retail AR project starts with the same argument. One side wants WebXR because nobody will install an app to try on a pair of glasses. The other wants native because the WebXR prototype looked wrong in a real shop. Both are right, which is why the argument goes in circles.

The way out is to stop treating it as a technology preference and start treating it as a question about what your experience actually requires. Three properties decide it, and only three.

The three properties that decide it

Does the experience need to persist across sessions? Does it need depth or occlusion to be believable? And how much does the install step cost you in conversion?

Persistence means a user can return tomorrow and find the same virtual content in the same physical place. That requires saving and relocalising against a map of the environment — ARWorldMap on iOS, Cloud Anchors on Android. WebXR has no equivalent. If your experience needs memory, the decision is already made.

Occlusion means virtual objects are correctly hidden behind real ones. Without it, a virtual sofa floats in front of the coffee table instead of behind it, and everyone can see the trick. Native gives you depth APIs and, on LiDAR devices, scene reconstruction. WebXR gives you a plane and your best guess.

Install friction is the one people quantify wrongly. An app install does not cost you a percentage of users — it costs you almost all of the ones who arrived from a link and were merely curious. If your traffic is cold, that is decisive. If people arrive already intending to buy, it barely registers.

The comparison, honestly

iOS Safari support for WebXR remains the single most common reason retail projects end up native. If a meaningful share of your customers are on iPhone — and in most Western retail they are — a WebXR-only strategy means a broken experience for them, not a degraded one.

Where each one genuinely wins

WebXR wins when the experience is a single throwaway interaction driven by cold traffic. A furniture placement widget linked from a product page. A QR code on packaging. A campaign that runs for three weeks. Anything where the install step would cost you more users than the fidelity gap would.

Native wins when the experience is the product rather than a feature of the page. Virtual try-on that needs accurate face tracking and measurement. Anything requiring persistence, indoor navigation, or LiDAR scanning. Anything where a customer will use it more than once.

• Try-on with real measurement — native, because face tracking maturity decides the result
• Place-this-in-your-room from a product page — WebXR, because cold traffic will not install
• Indoor navigation or wayfinding — native, because it needs persistence and relocalisation
• Short campaign or packaging activation — WebXR, because the update cycle matters more than fidelity
• A repeat-use tool for existing customers — native, because they will install once and use it often

The mistake that costs the most

Prototyping in WebXR because it is faster, validating the concept in a well-lit office with a clean floor, then discovering during the build that the experience actually needed persistence. At that point you are not porting — you are starting again, because the whole interaction model assumed something the stack cannot give you.

The three questions above take an afternoon to answer honestly. Answering them late costs weeks.

A note on drift

Whichever you choose, indoor tracking drifts. Rooms have repetitive surfaces, poor lighting and reflective floors, and the tracking will lose confidence. The projects that survive contact with a real shop are the ones that treat drift as a normal operating condition rather than an error — detecting when the user has gone off-route, re-anchoring against known features, and degrading gracefully instead of freezing.

That is an interaction design problem as much as a technical one, and it is where most of the difference between a demo and a product actually lives.