AR Quick Look vs Scene Viewer: what actually differs

The shape of the problem

On the web, both paths are usually reached through Google's <model-viewer>, whose ar-modes attribute lists them in priority order: webxr (in-browser AR on Android), scene-viewer (the Android system AR app) and quick-look (iOS). The model-viewer FAQ explains why WebXR is preferred on Android — "it is faster (no redownload of model), has consistent rendering, and stays in the browser" — while Scene Viewer and Quick Look are "independent apps and only customizable through URL parameters".

Android is the tighter constraint

This surprises people, because Apple's ecosystem has the reputation for being fussy. But Apple mostly publishes no numbers, while Google publishes hard ones: 15 MB maximum, 10 MB recommended ("Bigger models may result in poor user experience"), 100,000 triangles recommended, ten materials, one UV set per mesh. Scene Viewer's validator reports errors for morph targets, vertex colours, multiple UVs and non-triangle primitive modes.

The one-UV rule is the sharpest edge. A model with a separate lightmap UV — perfectly normal in a game-engine pipeline — is a Scene Viewer error, not a warning. So is a mesh carrying vertex colours, which is exactly what many photogrammetry and AI-generation pipelines emit by default. If your GLB works in <model-viewer> on the page and fails when the AR button is pressed, this list is where to look first.

iOS is looser on paper and stricter in memory

Apple publishes no triangle budget, no material cap and no file-size limit for Quick Look. What it has instead is a memory ceiling that produces the message "This file is too large to open in Quick Look" — and developers have hit it on files as small as 1.6 MB, because the check is on the in-memory footprint of decoded textures and geometry, not on bytes.

Two formats, one source of truth

The sane pipeline keeps GLB as the authored source and derives USDZ from it, because the conversion runs in that direction cleanly and not the other. <model-viewer> will even generate the USDZ on the fly if you do not supply ios-src — and per its FAQ that has a real advantage, since "material edits in 3D mode propagate into QuickLook, which is not possible in SceneViewer due to redownloading from the original URL".

On-the-fly generation is convenient and it is also a black box. If the iOS render matters commercially — and with Safari 27's <model> element it now shows up on the page, not just behind an AR button — you want to control the USDZ, review it, and ship it via ios-src. See Safari `<model>` requirements.

What breaks in one and not the other

• Transmission and volume glass renders correctly on Android via WebXR/model-viewer, and turns opaque in Quick Look. Bake it — see converter issues.
• Vertex-coloured meshes render on iOS with a proper material, and are a hard error in Scene Viewer.
• Multiple UV sets are fine in USDZ, an error in Scene Viewer.
• Large 4K texture sets sail past Scene Viewer's file-size gate if compressed well, then trip Quick Look's memory ceiling.
• Non-uniform scale on skinned nodes is a portability hazard in both, and one the glTF validator will warn you about.

A workable target for both

One asset that satisfies both platforms is achievable, and the binding constraints come from Android: under 10 MB, under 100,000 triangles, ten materials or fewer, one UV set per mesh, no vertex colours, no morph targets. Then, for the iOS derivative, keep decoded texture memory modest — 2048 px maps unless the product genuinely needs more — and bake any material extension USDZ cannot represent.

That set of rules is mechanically checkable, which is the point: shipping to two AR runtimes is not hard, it is just detailed, and detail is what tooling is for. The pre-publish version of the list lives in the e-commerce 3D checklist.