AR Model Requirements iOS, Android, and Web

Apple AR Quick Look is the built-in AR viewer on iOS and iPadOS. It launches automatically when a user taps a link to a USDZ file in Safari, Messages, Mail, or any app that uses the Quick Look framework. AR Quick Look requires iOS 12 or later and a device with an A9 chip or newer.

File format: USDZ only. USDZ is an uncompressed ZIP archive that contains a USD or USDC scene file along with PNG or JPEG textures. All assets are bundled into a single file with 64-byte alignment for efficient memory mapping. No other 3D format is accepted.

Polygon budget. Apple recommends 100,000 polygons or fewer for devices with higher memory (iPhone 7 Plus and later, iPad Pro). Older or lower-memory devices perform best with 30,000 to 50,000 polygons. Quadrilateral faces count as two triangles each, so a model with 50,000 quads has 100,000 triangles at render time.

Textures. Use 2048 x 2048 pixels for a single PBR texture set. Apple accepts up to 4096 x 4096, but the memory cost is significant: a single 4K texture can occupy around 85 MB of RAM once decompressed on the GPU. Dimensions must be powers of two (512, 1024, 2048, 4096). Supported image formats are PNG and JPEG.

Materials. USDZ uses UsdPreviewSurface, which supports physically based rendering through the metallic/roughness workflow. Available properties include base color, metallic (0 to 1), roughness (0 to 1), normal map, ambient occlusion, emissive color, opacity, clearcoat, and index of refraction. Base color textures should be in sRGB color space. All other maps (normal, metallic, roughness, AO) should be linear.

Animation. AR Quick Look supports skeletal and transform animations up to 10 seconds per clip. Animations loop continuously. Objects should stay centered at the origin with a consistent bounding box throughout playback, because the first frame is used to generate the shadow map.

File size. Aim for 4 to 8 MB for fast loading in Safari and Messages. Files up to 50 MB will technically load, but download times on cellular connections make larger files impractical.

Scale. AR Quick Look uses 1 unit = 1 meter. Models should be exported at real-world dimensions. A coffee mug should be about 0.1 units tall, not 10.

Google Scene Viewer is Android's native AR viewer. It is powered by ARCore and available on devices running Android 7.0 (API level 24) or later that have Google Play Services for AR installed. The full list of supported devices is published on the ARCore device list.

File format: GLB (binary glTF 2.0). Scene Viewer accepts GLB files served over HTTPS. Standard glTF with separate files also works, but GLB is preferred because it loads in a single request.

Polygon budget. Google recommends 30,000 to 50,000 triangles for optimal performance. Models with up to 100,000 triangles are tolerated, but frame rate on mid-range Android phones drops quickly above that threshold.

Textures. Maximum resolution is 2048 x 2048 pixels per texture. Supported formats are PNG and JPEG. JPEG is preferred when the texture has no transparency, because JPEG files are smaller and faster to decode.

Materials. Scene Viewer requires PBR metallic/roughness materials (the glTF 2.0 default). Supported properties include base color, metallic factor, roughness factor, normal map, ambient occlusion, and emissive. Models can have up to 10 materials total, and only 2 of those can use alpha transparency.

Skeleton limits. Animated models can have at most 254 bones (joints). Each vertex supports a maximum of 4 bone weights. Only the first animation track in the file will play.

File size. Google sets a 10 MB maximum. Files should ideally be under 5 MB for fast loading on mobile networks. Draco geometry compression can dramatically reduce file size, but the decoder library adds about 100 KB of overhead, so it only pays off when the savings exceed that.

Coordinate system. glTF 2.0 uses a right-handed coordinate system with +Y up. Scene Viewer expects 1 unit = 1 meter, the same as iOS. Make sure to render all surfaces of the model, including the bottom, because users can view the object from any angle.

Web AR runs entirely in the browser using the WebXR Device API. There is no app download, which removes friction for users. The tradeoff is that browser overhead eats into the performance budget, so models need to be more aggressively optimized than native AR equivalents.

Browser support. WebXR AR sessions are supported in Chrome for Android (version 79+), Samsung Internet (12.0+), and Edge on Android. Desktop browsers support WebXR for VR but generally not AR. Safari on iOS does not support WebXR at all. On iPhone and iPad, AR is handled through AR Quick Look with USDZ files, not through the browser's rendering engine.

File format. GLB is the standard for WebXR applications. Most WebXR frameworks (three.js, Babylon.js, A-Frame) use GLTFLoader or equivalent to parse GLB and glTF files at runtime.

Performance budgets. Target 50,000 to 100,000 triangles for a single object on mid-range mobile hardware. Texture resolution has a larger impact on mobile GPU performance than polygon count, because of limited VRAM and texture cache size. Keep textures at 1024 x 1024 when possible, or 2048 x 2048 at most.

File size. Aim for 2 to 5 MB total. A 5 MB GLB file can consume up to 9x its file size in memory during parsing due to texture decompression. Basis Universal (KTX2) texture compression helps by reducing both download size and GPU memory usage at the same time.

HTTPS required. The WebXR API only works on secure origins. All model files, textures, and scripts must be served over HTTPS. The page also needs the xr-spatial-tracking permission in the Permissions-Policy header.

Google's <model-viewer> web component is the simplest way to deliver AR on both iOS and Android from a single web page. It renders a 3D preview inline, then launches the appropriate native AR experience when the user taps the AR button.

The component accepts two model sources. The src attribute takes a GLB file for the inline 3D viewer and for Android AR (Scene Viewer). The ios-src attribute takes a USDZ file for Apple AR Quick Look. When a user on iPhone taps the AR button, model-viewer passes the USDZ file to Quick Look instead of attempting WebXR.

This means you need two versions of your model: one GLB and one USDZ. Both should be optimized separately for their respective platforms, since the polygon and texture budgets differ.

Practical workflow:

• Prepare a source model in your DCC tool (Blender, Maya, etc.) at the highest quality you need.
• Export a GLB with Draco or meshopt compression for Android and web viewing. Target under 5 MB.
• Export a USDZ using Reality Converter (Mac), Xcode, or Polyforge's GLB to USDZ converter. Target 4 to 8 MB.
• Test both files on actual devices. Simulators and emulators do not accurately reflect AR performance.

AR runs on mobile hardware with limited GPU power, battery life, and thermal headroom. Models that look fine in a desktop viewport can stutter or crash on a phone. These guidelines help you stay within safe limits.

Reduce draw calls. Merge materials where possible. Use a single texture atlas instead of many small textures. Scene Viewer limits you to 10 materials per model, but fewer is better on every platform.

Bake everything. AR viewers do not support procedural textures, shader graphs, or complex material setups from DCC tools. All visual detail must be baked into standard PBR texture maps (base color, normal, metallic, roughness, AO) before export.

Mind your normals. Use normal maps to add surface detail without extra geometry. A 5,000 polygon model with a good normal map can look as detailed as a 50,000 polygon model in AR, where viewing distances are typically a few feet.

Compress for GLB. Apply Draco geometry compression to reduce mesh data by 70% to 90%. Use KTX2 (Basis Universal) for textures to cut both file size and GPU memory usage. Polyforge's optimizer for AR supports Draco compression for GLB output.

Avoid oversize textures. A 4096 x 4096 RGBA texture occupies roughly 64 MB of GPU memory after decompression. Most AR objects do not need that level of detail. Start with 1024 x 1024 and only increase if the model genuinely looks better on device.

Test on real phones. Do not rely on desktop previews or emulators. Test on a mid-range Android device (not your flagship) and an iPhone from two or three generations back. If it runs smoothly there, it will work for most users.