WebAR vs Native AR App: Which to Build for Furniture

You run a furniture brand, or you are scoping the build, and one question sets everything else: should a shopper see your sofa in their room by tapping a link, or by installing your app? That is the WebAR versus native AR decision. It decides your reach, your budget, and how far a buyer can go before they check out.

What is WebAR?

WebAR is augmented reality that runs inside a phone's web browser, with no app to download. A shopper taps a link or an AR button on a page, points the camera at the floor, and places a 3D model at real scale. It works from the same URL on both iOS and Android.

From the shopper's side it feels like nothing was installed, because nothing was. They open your product page, tap an icon shaped like a cube or a phone, grant camera access once, and the sofa appears on their floor. They can walk around it and, on most devices, drag it into place and see it at the size it will really be. Then they close the tab and the AR is gone, which is both the strength and the limit of the approach.

Under the surface, WebAR is not one technology. It is three, chosen by device. On an iPhone, the browser hands the model to Apple's AR Quick Look, the system viewer built into Safari, using a USDZ file. On Android, the page opens Google's Scene Viewer with a glTF 2.0 or GLB file, which needs an ARCore capable device on Android 7.0 or later. For true in-page sessions, there is the WebXR Device API, which the browser runs directly.

Most teams do not wire these up by hand. They drop in Google's model-viewer web component, a single HTML tag that shows an interactive 3D model and offers an AR button that picks the right path per device. To feed it, you export each product twice, as GLB and as USDZ. We cover that split in detail in our guide to USDZ and glTF, the two AR 3D formats.

How is a native AR app different?

A native AR app is installed from the App Store or Google Play and runs on Apple's ARKit or Google's ARCore directly. With no browser in the way, it can read depth data, hide furniture behind real objects, scan a room, and hold a shopper's account and saved layouts. That direct access to the sensors is the whole point of going native.

The trade is friction and cost. Someone has to find, download and open the app before they see anything, and you now maintain two builds through every operating system update. Which framework you build on also matters more than most product owners expect, a choice we break down in ARKit versus ARCore for AR apps.

The reach versus capability trade-off

The decision reduces to one trade. WebAR wins on reach and friction: no install, one link, most phones. A native app wins on capability and retention: depth, occlusion, room capture, offline use and repeat visits. You rarely get both at once, so decide which one your product needs before you write a line of code.

The table below lines up the two side by side on the dimensions that actually change a build.

Tracking is the same, the powers are not

A useful thing to know before you choose: the motion tracking underneath is largely the same on both paths. WebAR on Android and a native ARCore app both rely on ARCore to find the floor and keep the model anchored, and on iPhone both ultimately lean on ARKit. So a model does not wobble more just because it sits in a browser. The gap is not tracking quality, it is what your code is allowed to do with the scene once it is tracked. WebAR is handed a placed model. A native app is handed the room.

Reach: the install is the tax

Every install is a step where shoppers drop off. WebAR removes that step. A view in your room link on a product page opens the camera in seconds, which is why it suits the top of the funnel, ads, email and social, where nobody wants to install anything to look at one chair.

The numbers that matter here are your own funnel numbers, not a market average, so do not let anyone sell you a native app on a borrowed statistic. Put a WebAR link live, watch how many shoppers open it and how many reach checkout, and you will know within weeks whether AR has earned an app.

The iOS catch nobody mentions

Here is the detail the agency posts skip. On Android, Chrome supports in-browser WebXR sessions, so a shopper can move around a model that stays anchored in the page. On iPhone, Safari does not support WebXR for AR. Real iPhone placement goes through Quick Look instead, which opens a separate system viewer on top of the page. The MDN reference is blunt that WebXR has limited availability and is not yet a baseline browser feature. So WebAR behaves differently on the two platforms, and any demo you approve should be tested on a real iPhone, not only on Android.

Capability: what the browser cannot reach

WebAR gives you placement and real scale. It does not give you the depth mesh, people and object occlusion, or room capture that a native app gets from the sensors. WebXR has a depth sensing module, but its availability is limited, and Quick Look and Scene Viewer do not hand your code a live depth map. If your experience needs a sofa to sit correctly behind a real coffee table, or needs the whole room measured, that is native territory. See whether you actually need LiDAR and what Apple RoomPlan captures before you assume you do.

Conversion depth: wide and shallow, or narrow and deep

This part is judgement, not a spec, so treat it as our read rather than a number. WebAR is a wide, shallow funnel: one product, one session, then the page closes. A native app is a narrow, deep one: fewer people install, but those who do get accounts, saved rooms, push reminders and a whole catalogue to browse. A brand with ten hero products wants width. A brand whose customers plan a whole room over weeks wants depth.

The platforms and formats you will actually use

Three building blocks cover almost every WebAR furniture project: model-viewer for the page itself, AR Quick Look with a USDZ file on iOS, and Scene Viewer with a GLB file on Android. When you need custom world tracking, image targets or branded effects that model-viewer does not offer, a commercial platform such as 8th Wall runs on top of the browser and works with engines like Three.js and A-Frame.

File size decides whether it opens at all

The quiet killer of WebAR is weight. Because the model downloads over mobile data the moment the shopper taps, a heavy file means a spinner, and a spinner means they leave. Keep each model small with compressed geometry and textures, and always ship the GLB and USDZ pair so both platforms load a native file rather than wait for a conversion. This is exactly where a rushed 3D pipeline shows up as lost sales. Our guide on how to make 3D models for an AR furniture app covers polygon budgets, compression and the dual export that keeps files light enough to open on mobile data.

When should a retailer start with WebAR?

Start with WebAR when the job is view this product in your room from a product page, your catalogue is small to medium, and you want the widest reach for the least build. It is the right first move for most furniture and homeware brands, because it proves whether shoppers use AR at all before you commit to an app.

Reach for WebAR first when:

• You want AR in ads, email and social, where an install would kill the click.
• You sell a focused range, not tens of thousands of products.
• Placement and correct scale are enough, and you do not need occlusion or room scanning.
• You want to test demand this quarter, not next year.

If you are still turning the concept into a plan, our walkthrough on turning an idea into an app helps you scope the smallest version worth shipping.

When does a native AR app pay off?

A native AR app pays off when AR is a repeat behaviour, not a one time look. If shoppers plan a whole room over several visits, if you have a large catalogue worth browsing in the app, or if occlusion, LiDAR based accuracy and saved layouts genuinely change the buying decision, the install cost buys you capability and retention that WebAR cannot match.

The matrix above is the quick version. Wide reach with simple placement sits in the top left and starts on the web. Loyal buyers who need depth and room capture sit in the bottom right and justify a native build. The awkward corner is wide reach that also needs deep capability, where the honest move is usually to ship WebAR now and earn the app later.

As a worked example, not a promise: picture a brand selling modular wardrobes that a customer configures over three or four visits. Saved rooms, exact measurements and occlusion all shape whether that customer commits, and each of those needs the sensors. Here the app is not a gimmick, it is the tool that closes the sale, so the install cost is easy to justify. Contrast a rug brand where one look in the room is the entire job, and an app would never pay for itself.

Native also makes sense once accurate measurement is part of the promise, for example letting a customer check that a wardrobe fits a wall. That leans on sensor access, and we cover the method in how to get accurate AR measurements.

When a native AR app is not worth it

A native AR app is not worth it when you have not yet proven that shoppers want AR at all. Building an app to test demand is the most expensive way to run that experiment. If your AR feature is see one product in the room, an app adds an install, two codebases and ongoing upkeep for a job WebAR already does from a link.

It is also the wrong call when your catalogue is tiny, when your buyers are one time purchasers who will never reopen the app, or when your models are not ready. AR magnifies the quality of your 3D assets, so a native app full of rough models is worse than a clean WebAR page with three good ones.

On cost, be honest about the full bill. A native AR app is not only the AR view, it is accounts, a catalogue, a backend and two platforms to maintain. Our published app builds start at $12,000, and larger, sensor heavy AR builds run up to about $150,000, with maintenance as a separate monthly plan. You can see the bands on our pricing page, and for a retail comparison, what a virtual try-on app like Zara costs gives a like for like sense of scope. When AR really is core to the product, a custom AR app development team can scope it properly rather than bolting AR onto a template.

Our take

For most furniture and homeware brands, WebAR first is the right answer, and it is not close. It reaches every shopper who can open a link, it costs a fraction of an app, and it tells you within a quarter whether AR moves your numbers. Ship model-viewer on your product pages, export clean GLB and USDZ models, and watch what happens.

Build native when the evidence says AR is a habit for your customers and you need the depth, the accuracy and the retention that only the sensors give. That is a decision to earn with data, not to assume on day one. If you want a straight read on which path fits your catalogue, our team can scope an AR build with you and tell you honestly when the app can wait.

Frequently asked questions