WebAR vs app-based AR: which one should you build?

What is the difference between WebAR and app-based AR?

WebAR runs inside the phone's existing browser. The customer scans a QR code or taps a link, grants camera permission, and the experience starts. App-based AR is a native iOS or Android application the customer downloads from a store before they can see anything.

Both can track faces, hands, bodies and surfaces. Both can render 3D products convincingly. The real difference is not visual quality, it is the step you ask the customer to take first, and what the device will let you do once they have.

Which one reaches more people?

WebAR, by a wide margin, and the gap is not close enough to be worth arguing about. Every additional step between seeing a campaign and experiencing it loses a share of the audience, and installing an app is the largest single step you can ask for. It requires store navigation, a download over whatever connection the customer has, storage space, and in many cases a login.

This matters most exactly where AR is most useful: at a shelf, at an event, on a poster, in a magazine. Those are moments of seconds. A customer standing in a store aisle will not install an application to try on a pair of glasses, and a queue at a stand will not wait through a 40MB download on venue wifi.

App-based AR earns its install when the customer already wanted the app for another reason. If you are a retailer whose app people use to shop, adding try-on to it is sensible, because the download already happened. Building a new app purely to house an AR experience almost never pays for itself.

Where is app-based AR genuinely better?

Native apps get deeper access to the device, and there are cases where that decides the project. ARKit on iOS and ARCore on Android expose persistent world tracking, plane detection, occlusion and depth data that browsers either restrict or expose inconsistently. If your experience needs a virtual object to stay anchored in a room while the customer walks away and returns, native is the safer route.

Native also wins where you need heavy on-device computation, offline operation, or LiDAR depth on supported iPhones. Room-scale interior design, industrial and field-service overlays, and anything requiring precise measurement usually belong in an app.

The honest test is whether the experience needs the device's full spatial capability, or whether it needs to reach as many people as possible. Those two goals point in opposite directions, and you cannot optimise for both.

Does WebAR work well enough on older phones?

It can, but this is where WebAR projects fail, and it is worth being blunt about it. A browser-delivered experience competes for resources with the browser itself, so the performance ceiling is lower than native. An experience built and tested on a current iPhone will often be unusable on a mid-range Android handset three or four years old.

We target 30 frames per second on that older hardware rather than on flagship devices, because that is what most customers are actually carrying. In practice that means constraining polygon counts and texture sizes, choosing tracking models by cost rather than by capability, and deciding early which visual flourishes get dropped on weaker devices instead of letting the frame rate collapse.

Ask any agency what device they tested on and what frame rate they held. A pitch that shows only a flagship phone in a controlled demo has not answered the question.

How does the cost compare?

WebAR is usually cheaper to build and considerably cheaper to keep running. There is one codebase rather than two, no store review cycle, and a fix is a deployment rather than a release the customer has to accept. App-based AR carries the ongoing weight of two platforms, store compliance, and users stranded on old versions.

The cost that surprises people in both cases is 3D asset production. Turning a product catalogue into models that look right under real lighting is frequently the largest line item and the usual cause of a slipped launch. Existing CAD files help, though they generally need substantial cleanup before they perform in real time.

Where WebAR carries a running cost native does not is server-side inference. If the tracking or segmentation model runs on your infrastructure rather than in the browser, every session costs compute, and campaign traffic is spiky by nature. That has to be sized for the launch day rather than the average day.

How do we decide?

We start from where the customer will be standing when they use it. If the answer is anywhere other than sitting at home with time to spare, the install step is usually fatal and WebAR is the answer.

Then we ask whether the experience needs to persist in space or just to sit on the customer. Try-on, filters, product visualisation and packaging activation sit on the customer and work well in a browser. Room-scale placement, measurement and industrial overlays need spatial persistence and point towards native.

If both are viable, we build the browser version first. It reaches more people, ships sooner, and tells you whether anyone wants the experience before you commit to two native codebases.