--- title: What file formats do I need for AR content in my app description: Learn which file formats work for AR apps, how glTF and USDZ compare across ARKit, ARCore and WebAR, and why format choice matters from the start. image: https://weareaffective.com/hubfs/learning-centre-images/what-file-formats-do-i-need-for-ar-content-in-my-app.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-file-formats-do-i-need-for-ar-content-in-my-app#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What file formats do I need for AR content in my app Table of Contents The question arrives early in most AR projects, and it sounds simple: what file format do we need? The answer depends on which platform you are building for, what level of API access you have, how complex your 3D assets are, and whether you need animations to survive the delivery pipeline intact. Get it wrong at the start, and you will be rebuilding parts of the architecture once the project is well underway. Get it right, and the rest of the pipeline follows logically from it. > The format question is really a set of questions about platform, pipeline, and experience. We see this play out most clearly at the point where a team has already committed to a 3D asset library and then discovers the target platform will not accept the format those assets were produced in. The conversion is never free. Something always changes in translation, whether that is texture fidelity, material properties, or animation behaviour. The format question is really a set of questions about platform, pipeline, and what the experience actually needs to do. We learned some of this directly on a production management product we built for the motion picture industry. We went in expecting clean API access to existing third-party platforms, and found those systems were far more locked down than anticipated. The architecture had to change. The lesson extended beyond that specific project: the access you have to underlying systems shapes every technical decision that follows, including format choice for any media-heavy feature. AR is no different. The format is downstream of the architecture, and the architecture is downstream of what you can actually connect to. ## The core formats: glTF, USDZ, and why those two dominate Two formats do most of the work in AR delivery: glTF and USDZ. They did not achieve that position by accident. Each was designed with a specific ecosystem in mind, and each has become the de facto standard within it because it handles the constraints of real-time 3D rendering on a mobile device better than the alternatives. glTF, developed by the Khronos Group, is an open format built for efficient transmission and loading of 3D scenes and models. It stores geometry, materials, textures, and animations in a structure designed to minimise the processing needed at load time. The format has two common variants: the standard .gltf file, which references external texture files, and the self-contained .glb binary, which packages everything together. For web-based AR and Android delivery via ARCore, glTF and glb are the standard starting point. USDZ is Apple's format, derived from Pixar's Universal Scene Description specification and adapted for AR delivery on iOS. It is a zip-compressed archive containing geometry, materials, and textures in a single file, and it is the required format for ARKit's native AR Quick Look feature. You cannot swap glTF into an ARKit Quick Look workflow and expect it to work. The two formats are not interchangeable. #### What about FBX, OBJ, and others? FBX and OBJ are common in 3D production pipelines, but they are intermediate formats rather than delivery formats. They carry more data than real-time AR needs, and they do not map cleanly onto the material models either ARKit or ARCore use. They belong in the authoring stage, not the delivery stage. ## What each platform actually accepts: ARKit, ARCore, and WebAR compared The three primary AR delivery platforms each have specific format requirements, and they do not align perfectly. Understanding what each accepts is the first step to deciding whether a single format can serve your product or whether you need more than one. | Platform | Primary format | Animation support | Notes | | --- | --- | --- | --- | | ARKit (iOS) | USDZ | Yes, via USD animations | Required for AR Quick Look. Reality Composer extends this. | | ARCore (Android) | glTF / glb | Yes, via glTF animations | Scene Viewer uses glb directly from a URL. | | WebAR | glTF / glb | Yes, via glTF animations | Libraries like model-viewer and 8th Wall use glb. Some support USDZ for iOS fallback. | ARKit's native viewer, AR Quick Look, accepts USDZ and nothing else at the system level. If you are building a native iOS app and want to use ARKit's built-in placement and rendering, your assets must be in USDZ. ARCore's Scene Viewer, the Android equivalent, accepts glb files served from a URL. WebAR frameworks generally use glTF or glb, with some allowing a USDZ fallback for iOS devices where the browser cannot otherwise trigger AR. Over 90% of current smartphones support at least one AR form, according to [XICTRON, 2026](https://www.xictron.com/en/blog/augmented-reality-online-shop-ar-commerce-2026/), which means the format decision is about which AR, not whether AR is viable at all. ## The design layer your *developers* need We deliver complete UX/UI design and technical specifications your development team can build from immediately. No guesswork, no back and forth, no mid-project surprises. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Why format choice is made at architecture stage, not export stage A common assumption is that format is an export decision: you build your 3D asset, then choose which format to export it in at the end. That works when you are producing a small number of assets for a single platform with a consistent material model. It stops working when you have a large asset library, [multiple platforms, animation requirements](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem), or an asset pipeline that involves multiple teams or tools. The format determines which renderer you are writing for. Different renderers interpret materials, lighting, and shading differently. A material that looks correct in a glTF renderer on Android will not automatically reproduce faithfully in USDZ on iOS, because the two formats use different material specifications. If you build your asset library for one renderer and then convert for another, you are relying on the conversion to bridge a gap it was never guaranteed to close perfectly. > The format determines which renderer you are writing for, and material fidelity does not survive conversion automatically. We built a holistic mental health and wellness product that required us to make [architecture decisions early that constrained every technical choice downstream](https://weareaffective.com/app-architecture-design-we-are-affective). We evaluated serverless architecture and ruled it out because the endpoint usage pattern would have created unacceptable cold-start latency. The same kind of reasoning applies to AR format choice: the decision you make at architecture stage closes and opens doors that you will feel the effects of much later. Choose the renderer first, then design the asset pipeline around it, not the other way around. Decide your target renderer before commissioning or converting any 3D assets. The material specification baked into an asset at production time is hard to change cleanly later. ## How API access shapes what formats are even possible Format choice does not exist in isolation from the technical environment the app lives in. The APIs and system-level features you can access determine which AR workflows are even available to you, and those workflows each carry format requirements. On the production management product we built for the motion picture industry, we expected clean access to third-party platforms via their APIs and found the systems were far more locked down than anticipated. We had to pivot to ingesting emails tied to specific production roles to process data indirectly, rather than integrating directly. That kind of constraint changes the entire technical approach. AR delivery has an equivalent: if you are building a native iOS app and want to use ARKit's AR Quick Look for in-app AR without building a custom renderer, you need USDZ and you need the system to be able to load that file. If your content is hosted behind authentication or in a format AR Quick Look cannot read, the native route is closed. #### Third-party AR SDKs and format flexibility Some AR SDKs, such as 8th Wall, abstract some of the format complexity by accepting glb and handling device-level delivery themselves. But using a third-party SDK means accepting its constraints and pricing model alongside the format flexibility it offers. The API access question becomes: are you [working within the system's intended boundaries](https://weareaffective.com/learning-centre/7-new-tech-terms-your-app-developers-need-to-know-to-sound-smart), or are you trying to work around them? We learned on the memory-sharing proof-of-concept project that switching from Spotify to Deezer and using the official API as intended simplified both the architecture and the compliance burden considerably. The same principle holds for AR: working with the platform's intended delivery method, and the format it requires, is almost always simpler than building around it. ## Textures, compression, and file size: the constraints that decide quality A format is not just a container for geometry. It also determines how textures are stored, which compression schemes are supported, and how much of the file budget is spent on data the device cannot use efficiently. These constraints are where most of the visible quality difference between AR implementations comes from. glTF supports KTX2 texture compression with Basis Universal encoding, which allows a single compressed texture to be transcoded to the format the device GPU natively supports at runtime. This is meaningful for AR because mobile GPUs vary considerably, and serving uncompressed textures wastes memory and slows load time. USDZ does not currently support KTX2. It uses standard image formats such as PNG and JPEG inside the archive, which means larger file sizes for equivalent texture resolution. #### The cost of high-resolution assets 3D asset production for AR typically costs between $100 and $1,000 or more per SKU, according to [Frame Sixty](https://framesixty.com/ar-product-visualization/), and production cost is usually the largest budget line in an AR project. Spending that budget on high-resolution assets and then compressing them to the point where quality is lost at delivery is a waste of both the production investment and the opportunity. The texture compression decision is therefore not just a technical one. It connects directly to the [asset production brief, which should specify target resolution](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) and compression requirements from the start rather than leaving those as export-time choices. Specify texture resolution and compression targets in your asset production brief. Adjusting them after the asset library is built is expensive and rarely recovers the full quality of a correctly specified original. ## Animation and interactivity support across formats Both glTF and USDZ support animations, but they do so differently, and the difference matters for what the experience can actually do once it is in the user's hands. glTF stores animations as keyframe sequences that can be played back by a compatible renderer. Most WebAR and ARCore implementations support glTF animations well, and frameworks like model-viewer provide straightforward controls for triggering and looping them. The animation data travels with the model in the glb file, so what you produce in the authoring tool is what the renderer receives, subject to the usual material translation caveats. USDZ supports animations through the USD schema, including skeletal animation and transform animation. Apple's Reality Composer and Reality Composer Pro extend this with behaviour-based interactivity, allowing objects to respond to tap gestures, proximity, and other triggers without writing custom code. This is a meaningful capability for product AR experiences where a user tapping to open a lid or trigger a colour change is the interaction. But it is only available within the Apple ecosystem, and it requires authoring in Apple's tools or exporting from a pipeline that correctly outputs USD behaviours. - glTF animations work across WebAR, ARCore, and most third-party SDKs - USDZ animations work natively on ARKit and AR Quick Look - Reality Composer behaviours add interactivity to USDZ but are iOS-only - Cross-platform interactivity requires a custom renderer or a third-party SDK The interactivity question is therefore a format question in disguise. If the experience needs a user to tap an object and trigger a response, that requirement points toward a specific platform and therefore a specific format before any visual design work has begun. ## When one format is not enough: multi-platform delivery A product targeting both iOS and Android with native AR experiences needs both USDZ and glb. There is no format that the native AR viewers on both platforms accept. This is a deliberate outcome of two separate platform ecosystems with different rendering architectures. The practical consequence is a dual-format asset pipeline. You produce or convert assets into both formats, serve the appropriate one based on the user's device, and maintain both versions when assets are updated. That maintenance cost is real and should be budgeted for explicitly. An asset library of 50 products means 50 USDZ files and 50 glb files, and any update to the 3D geometry or materials means updating both. WebAR reduces some of this complexity. A web-based AR experience using a framework that serves glb as the primary format can use a USDZ fallback for iOS devices that trigger AR through Safari's AR Quick Look integration from a web page. This is not a perfect solution: the experience in AR Quick Look is more constrained than a full custom renderer, and the material rendering may differ between the two paths. But for products where web delivery is acceptable, a glb-plus-USDZ-fallback approach covers both platforms without maintaining two entirely separate native AR experiences. If you are building for both iOS and Android, budget for two separate asset versions and [a delivery layer that detects the device](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) and serves the correct format. Do not treat conversion as a one-time task: every asset update touches both formats. ## Conversion pipelines and what gets lost in them Converting between glTF and USDZ sounds like a solved problem. Several tools claim to handle it automatically. In practice, conversion introduces losses that range from minor to significant, depending on the complexity of the source material and the rendering features it relies on. The most common losses are in material fidelity. glTF uses a PBR material model based on metallic-roughness parameters. USDZ uses a different PBR model with some overlapping properties but also meaningful differences. A material that uses emissive maps or certain texture channel configurations in glTF may not convert accurately into USDZ without manual adjustment. Transparency, clearcoat effects, and transmission materials are particularly prone to degrading in conversion. Animation data generally survives better than materials, but rigging complexity is a factor. Simple keyframe animations on transforms convert reliably. Complex skeletal rigs with blend shapes are more likely to require manual review after conversion. #### Managing conversion in a live pipeline Conversion pipelines that run automatically as part of a content management system need a review step. An asset that converted cleanly at project launch may not convert cleanly after the source file is updated. The safest approach is to author for the more constrained format first and then convert upward rather than the reverse. Since USDZ is the more constrained of the two in terms of material features, authoring for USDZ material constraints first and then converting to glTF tends to produce more consistent results than the other direction. ## How format decisions constrain the experience before design begins A format decision made at architecture stage does not just constrain the pipeline. It constrains what the experience can look like and how it can behave. This is the link that gets missed most often, and it is where the cost of getting the format question wrong is felt most acutely by the design team. If the format decision rules out certain material types, the visual design has to work within those constraints. A product with a complex translucent material, a glass perfume bottle for instance, will look different in USDZ than in a glTF renderer that supports transmission. If the design was specified against the more capable renderer and then the platform requires USDZ, the design needs to change. That change happens late, when it is expensive. We saw a version of this on a wellness genetics product where [a luxury-looking design was handed to developers](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) working with an existing codebase, and the gap between what the visual design specified and what the code could support created significant rework. The design had been created with assumptions about implementation that the implementation could not meet. Format constraints in AR are the same kind of assumption. A designer who does not know the target format will make choices the format cannot support. The fix is to bring the format decision into the design brief explicitly. The brief should state which platform and renderer the experience targets, what the material constraints of that renderer are, and what animation and interactivity capabilities are available. Shoppers spend 75 seconds with a 3D viewer versus 49 seconds without one, according to [XICTRON, 2026](https://www.xictron.com/en/blog/augmented-reality-online-shop-ar-commerce-2026/), which indicates the experience quality is worth protecting. Protecting it starts with [the designer and the architect agreeing on format](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) before the first asset brief goes out. ## Conclusion AR file formats are a technical subject, but the decision about which format to use is a product decision made at architecture stage. It shapes the asset pipeline, the rendering quality, the animation and interactivity options, the maintenance burden for multi-platform delivery, and the boundaries within which the design team can work. Treating it as an export-time detail leads to expensive corrections later. The practical answer for most products is glb for web and Android delivery, USDZ for native iOS delivery, and a conversion pipeline with a manual review step rather than fully automated output. Author for the more constrained format's material limits first. Specify texture compression targets before commissioning assets. Bring format requirements into the design brief alongside visual requirements so the two do not conflict mid-project. The access question matters too. As we found on the motion picture industry project, the systems you expect to connect to are not always as open as they appear. For AR delivery, that means confirming API access and system-level format support before committing the asset pipeline to a direction you may not be able to complete. If you are planning an AR feature and want to work through the format and pipeline decisions before they constrain your options, [let's talk about your AR project](https://weareaffective.com/get-started). ## Frequently Asked Questions What are the two main file formats used for AR content delivery? The two dominant formats are glTF and USDZ. glTF is the standard for web-based AR and Android delivery via ARCore, whilst USDZ is Apple's format and is required for ARKit's native AR Quick Look feature. Can I use the same file format across both iOS and Android? No, glTF and USDZ are not interchangeable. You will likely need to maintain both formats if you are delivering AR content across iOS and Android, which means planning your pipeline to accommodate that from the start. What is the difference between a .gltf file and a .glb file? A standard .gltf file references external texture files, whilst a .glb file is a self-contained binary that packages everything together. For most delivery scenarios, .glb is more practical because it keeps all assets in a single file. Can I use FBX or OBJ files for AR delivery? FBX and OBJ are not suitable as delivery formats for AR. They are better suited to the authoring and production stage, as they carry more data than real-time AR needs and do not map cleanly onto the material models used by ARKit or ARCore. What happens if I choose the wrong file format early in a project? Choosing the wrong format can mean rebuilding parts of your architecture once the project is already underway. Converting between formats is never a clean process, as texture fidelity, material properties, or animation behaviour can all change in translation. What is USDZ and where does it come from? USDZ is Apple's AR delivery format, derived from Pixar's Universal Scene Description specification and adapted for use on iOS. It is a zip-compressed archive containing geometry, materials, and textures in a single file, and it is required for ARKit's AR Quick Look feature. Does the format choice depend on anything beyond the target platform? Yes, format choice is also shaped by the level of API access you have, the complexity of your 3D assets, and whether animations need to survive the delivery pipeline intact. The format decision is really downstream of your overall architecture, which is itself shaped by what systems you can actually connect to. Is glTF an open format or is it tied to a specific company? glTF is an open format developed by the Khronos Group, designed for efficient transmission and loading of 3D scenes and models. Because it is open and widely supported, it has become the de facto standard for web-based AR and Android delivery. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.