Which 3D Format for AR? iPhone, Android & Web Compared

The AR Format Landscape

If you have ever tried to add an "View in AR" button to a product page or portfolio site, you have likely discovered that there is no single 3D file format that works everywhere. Apple created its own format for AR on iOS. Google adopted a different format for Android. Web-based AR frameworks have their own preferences. The result is that delivering AR experiences to all users requires understanding multiple formats and, in many cases, providing the same model in more than one.

The good news is that the formats are not wildly different under the hood. They all describe textured polygon meshes with PBR materials. The differences are mostly about packaging, platform expectations, and which rendering features each platform supports. Once you understand the requirements, preparing models for cross-platform AR becomes a predictable, repeatable process.

iPhone and iPad: USDZ

Apple's AR platform uses USDZ, a zip-compressed package built on Pixar's Universal Scene Description (USD) format. When a user taps an AR link on an iPhone or iPad running iOS 12 or later, Safari opens the file in AR Quick Look, Apple's built-in AR viewer. The model appears floating in the user's real-world environment, rendered with Apple's own PBR engine that handles shadows, reflections, and environmental lighting automatically.

USDZ supports polygon meshes with PBR materials including base color, metallic, roughness, normal, emissive, ambient occlusion, and clearcoat. It also supports basic animations (skeletal and transform-based) and audio. However, it does not support all the extensions available in GLTF, and some material features behave slightly differently than their GLTF equivalents.

The key constraint with USDZ is that it only works within Apple's ecosystem. Safari on iOS and iPadOS will open USDZ files natively. No other browser on any platform supports USDZ natively. You cannot view a USDZ file in Chrome, Firefox, or Edge on any device. This means USDZ is exclusively for iPhone and iPad AR experiences.

Creating USDZ files can be done with Apple's Reality Converter app (macOS only), Blender with the USD export addon, or command-line tools like Apple's usdzconvert. Many workflows start with a GLTF/GLB master file and convert to USDZ as a build step, which ensures consistency between the web and iOS versions of the model.

Android: GLB via Scene Viewer

Google's approach to AR on Android centers on GLB files viewed through Scene Viewer, a component of Google Play Services for AR (formerly ARCore). When an Android user taps a properly formatted AR link, the system opens the GLB file in Scene Viewer, which places the model in the real world using the phone's camera and motion sensors.

GLB is the binary variant of GLTF, the open standard maintained by the Khronos Group. It supports PBR materials with all the standard maps (base color, metallic, roughness, normal, occlusion, emissive), skeletal animations, morph targets, and scene hierarchies. For AR purposes, Scene Viewer supports most core GLTF features plus a few Google-specific extras like animation autoplay settings.

The advantage of using GLB for Android AR is that GLB is also the dominant format for web-based 3D. The same file you use for Android AR can be used for your website's 3D viewer, for WebXR experiences, and for Google Search 3D results. You do not need a separate conversion step or a separate asset pipeline.

Scene Viewer is available on most Android phones running Android 7.0 or later with Google Play Services. It is not available on devices without Google Play Services, such as some Huawei phones and Amazon Fire tablets. For those users, web-based AR via WebXR is the fallback.

Web-Based AR: GLB via WebXR and model-viewer

Web-based AR uses the WebXR Device API combined with a 3D rendering library (typically Three.js or Babylon.js) to place models in the real world through the phone's browser. The most accessible way to implement this is Google's model-viewer web component, which wraps Three.js, Scene Viewer, and AR Quick Look into a single HTML element.

The model-viewer component is particularly elegant because it handles platform detection automatically. You provide a GLB file for the 3D preview and Android AR, and optionally a USDZ file for iOS AR. On desktop, it shows the interactive 3D viewer. On Android, the AR button opens Scene Viewer with the GLB. On iOS, the AR button opens Quick Look with the USDZ. One component, three experiences, zero JavaScript required from the developer.

For web AR without model-viewer, the WebXR API provides lower-level access to AR features. You load a GLB model using your 3D library's loader, create a WebXR session with immersive-ar mode, and render the model into the AR scene. This approach gives you more control over the experience but requires significantly more code.

Preparing Models for AR

AR imposes stricter performance requirements than desktop 3D viewing because the renderer must maintain 60 frames per second while simultaneously running camera tracking, plane detection, and lighting estimation. A model that runs smoothly on a desktop 3D viewer might stutter or lag in AR on a mid-range phone. Preparation is essential.

Polygon Budget

Keep your models under 100,000 triangles for reliable performance on mid-range phones. High-end devices can handle more, but your audience will include older and budget devices. For e-commerce product visualization, 10,000 to 50,000 triangles is a practical sweet spot that provides good visual quality without taxing the GPU. Use normal maps to add apparent surface detail without increasing polygon count. A 10,000-triangle model with a well-crafted normal map can look nearly identical to a 500,000-triangle model without one.

Texture Optimization

Textures are often the largest part of an AR model file. Use JPEG for base color and emissive maps, and PNG only when you need transparency. Resize textures to the minimum resolution that still looks good at the expected viewing distance. For most product AR experiences, 1024x1024 textures are sufficient. Use 2048x2048 only for hero products or objects with fine surface detail. Larger textures consume GPU memory and slow down loading without visible benefit on a phone screen.

Consider using KTX2 texture compression (via the KHR_texture_basisu GLTF extension) for the web version. GPU-compressed textures load faster and use less memory, though they are not supported in USDZ, so you will need uncompressed textures in the iOS version.

File Size Targets

AR models should load quickly because users are holding their phone up, waiting. Aim for total file sizes under 5 MB. Under 2 MB is even better. Users will not hold their phone steady in AR position for 30 seconds while a model downloads. Every second of loading time increases the chance they give up and put the phone down. Use Draco compression for geometry and optimize textures aggressively.

Scale and Origin

AR places models in the real world, so physical scale matters. A chair model should be the size of a real chair, not a thumbnail or a building. Ensure your model is exported at real-world scale in meters (GLTF and USDZ both use meters as the default unit). Place the model's origin at the bottom center so it sits naturally on a detected floor plane rather than floating or intersecting the ground.

Cross-Platform AR Strategy

The recommended workflow for cross-platform AR is to maintain a single master model in GLB format and convert to USDZ only for iOS distribution. This keeps your asset pipeline simple and ensures consistency. Author your model in Blender or your preferred 3D tool, export to GLB with PBR materials, verify it looks correct in a browser-based viewer, then convert to USDZ using Reality Converter, usdzconvert, or an automated build script.

On your website, use Google's model-viewer component and provide both the GLB source and the USDZ fallback for iOS. This gives every user the best possible experience: interactive 3D on desktop, native AR on Android and iOS, and graceful fallbacks everywhere else.

Test on real devices. AR performance varies significantly between devices, and what runs smoothly on a flagship phone may struggle on a three-year-old budget device. Test your models on at least one mid-range Android phone and one older iPhone (iPhone SE or iPhone 11) to ensure acceptable performance across your audience.