Where do the two approaches diverge?
| Criterion | WebAR | App-based AR |
|---|---|---|
| Access | One tap from the browser | Download + install + open |
| Format | USDZ (iOS), glTF/GLB (Android) | The app's own asset pipeline |
| Distribution | A product page link, shareable | Through an app store |
| Updating | Change the file on the server, propagates instantly | Requires an app version update |
| Technical control | Bounded by the platform AR viewer | Full control, custom interaction possible |
| Fit for e-commerce | High — does not break the purchase flow | Low — breaks the flow |
The decisive row is access. In e-commerce, AR comes into play on the product page at the moment the decision is made; insert an app download into that moment and most shoppers never complete it, so the moment is lost.
Which devices does WebAR work on?
| Device | AR technology | Required format | Condition |
|---|---|---|---|
| iPhone / iPad (Safari) | AR Quick Look | USDZ | iOS 12 and later, ARKit-capable device |
| Android (Chrome) | Scene Viewer | glTF / GLB | Google Play Services for AR must be installed |
| Desktop browser | No AR | glTF / GLB | 3D viewer is shown instead |
A correctly built WebAR integration detects device type and hides the button where AR is unsupported. Showing a button that does nothing is a worse experience than having no AR at all.
When is app-based AR the right choice?
Although app-based AR is the wrong tool for an e-commerce product page, it is right in some scenarios: assembly guides used by field service teams, presentation tools used by in-store sales staff, and professional applications used repeatedly. What they share is a reason strong enough for the user to accept the download step.
- Purchase decision on the product page → WebAR
- In-store staff tool → app-based AR worth considering
- Field assembly and service guide → app-based AR
- One-off campaign experience → WebAR