Why We Still Build 3D Configurators for the Browser, Not an App Store

Every interactive 3D tool we have shipped recently, Marriott's Four Points Flex conversion tool, the Charlton House Estate interactive map, an embeddable product configurator, runs in a browser. None of them are native apps, and that has been a deliberate choice each time, not a default.

The clearest reason is distribution. A configurator that needs to sit on a partner's own website, embedded directly into their existing page, cannot be an app someone has to leave the browser and download first. Building it as a web-based 3D experience means it drops into an iframe on a retailer's product page with no friction between someone browsing and someone interacting with the model.

The second reason is who actually uses these tools. Marriott's conversion tool needs to work for independent hotel owners who are being introduced to a brand programme, not existing users of a Marriott app. Asking that audience to install something before they can see the product is an extra step most of them will not take. A link that opens straight into a working 3D scene has a far better chance of actually getting used.

Updates are the third factor, and probably the one that matters most once a project is live. A web build means our clients' teams can push a pricing change, a new finish option or a copy update without anyone submitting anything to an app store and waiting on review. For tools tied to live commercial offers, that turnaround time is not a nice-to-have.

None of this means native apps are wrong for every use case. But for the specific job these tools do, being seen quickly, used without commitment, and updated without friction, a browser is almost always the better platform. Three.js and React Native have got good enough that the performance argument for going native has mostly disappeared too.