AR Product Catalog: Technical Implementation Guide

AR Product Catalog: Technical Implementation

When developing an AR catalog, the main challenge is loading and displaying 3D models on mobile devices without delays. A user opens a product card and expects the model to appear within 2–3 seconds. Any longer — conversion drops by 20%. The standard approach of bundling all models in the app is not scalable: a catalog of 1000 items weighs over 10 GB. The solution is on-demand loading from CDN with local caching. In this article, we break down the architecture, typical issues, and our automation experience. We build AR catalogs for mobile apps with CMS integration and support for USDZ and GLB formats. Loading time savings reach 40% compared to non-caching solutions.

Problems We Solve

Loading and Caching 3D Models

An AR catalog with hundreds of items cannot store all models in the app bundle. On-demand download from CDN is required. Standard approach:

1. Product catalog from CMS contains model_url — a URL to USDZ (iOS) or GLB (Android).
2. When a product card opens — check local cache (FileManager).
3. If not present — download in background via URLSession.downloadTask, show progress bar.
4. After download — initialize AR scene.

func loadModel(url: URL, completion: @escaping (ModelEntity?) -> Void) {
    let cacheURL = cacheDirectory.appendingPathComponent(url.lastPathComponent)
    if FileManager.default.fileExists(atPath: cacheURL.path) {
        completion(try? ModelEntity.loadModel(contentsOf: cacheURL))
        return
    }
    URLSession.shared.downloadTask(with: url) { tempURL, _, _ in
        guard let tempURL else { completion(nil); return }
        try? FileManager.default.moveItem(at: tempURL, to: cacheURL)
        DispatchQueue.main.async {
            completion(try? ModelEntity.loadModel(contentsOf: cacheURL))
        }
    }.resume()
}

Model size matters. Furniture: 5–15 MB USDZ is normal. 50+ MB — user waits and leaves. Optimization: TextureConverter for texture compression to ASTC, Draco geometry compression (via usdz_converter or Blender pipeline).

Scaling and Precise Placement

Basic plane detection → raycast → placement is well described in the ARKit documentation. In an AR catalog, we add:

Scaling with real size preservation. USDZ models must have correct scale: a 2-meter sofa should be 2 meters in AR. If size is in CMS metadata — apply via ModelEntity.scale. If not — set through model configuration. The user should not have to scale manually — that ruins the perception of real size.

One-finger rotation. EntityRotationGestureRecognizer in RealityKit is the simplest path. But rotation only around the Y axis (vertical): furniture does not tilt, it rotates around itself. Fix the axis using constraints:

entity.components[PhysicsMotionComponent.self] = PhysicsMotionComponent()
// Rotation constraint — only Y

Variant/color switching without reloading the model. A sofa available in 5 colors. Loading 5 models is expensive. Correct: one geometry, different materials. In USDZ, materials can be changed via ModelComponent.materials:

var materials = entity.model?.materials ?? []
materials[0] = SimpleMaterial(color: .init(selectedColor), isMetallic: false)
entity.model?.materials = materials

For PBR materials with textures — PhysicallyBasedMaterial with loaded textures.

How to Speed Up Model Loading?

Loading via CDN is on average 3x faster than from the bundle when the model is larger than 10 MB. We use URLSession with a progress indicator and caching in FileManager. For even greater speed, we implement parallel downloads — up to 3 models simultaneously. We also implement prefetching: load the model upon clicking a product card before the user presses ‘View in AR’. This approach reduces waiting time by 50%.

Why Real Scale Matters?

Accurate size display is the main trust factor. If a sofa in AR is smaller or larger than real, the user will be disappointed. We guarantee correct scale thanks to normalization scripts during conversion from source formats. In our practice, we encountered 3D models from suppliers in arbitrary units (1 unit = 1 inch for one, 1 centimeter for another). We wrote a script that automatically reads real dimensions from the product specification and adjusts the scale. This reduced manual model verification time by 80%.

How to Integrate AR Catalog with Existing CMS?

Typical scenario: Shopify, WooCommerce, or custom CMS on the backend. We add a custom field ar_model_url to the product. On the mobile client — the ‘View in AR’ button appears only if the field is filled.

For 3D content management without programmers — a simple CMS or admin panel with USDZ/GLB file upload and automatic server-side optimization (conversion, compression, upload to CDN). This removes developer dependency when adding new products.

Case: Conversion Automation for 2000 Items

Our client — an e-commerce furniture store with 2000+ items. Priority: cover top 100 SKUs with AR models. Phased: first iOS (ARKit + USDZ), after 2 months Android (SceneViewer + GLB). Conversion from supplier’s FBX models to USDZ/GLB — automated pipeline via Blender Python scripts + reality-converter CLI. Time per model: 3–7 minutes. The main non-technical issue — different units in source models. Solved with a scale normalization script that validates real dimensions from the product specification. After launch, conversion in the AR section increased by 25%.

What’s Included in the Work

• AR module for iOS and/or Android using ARKit/RealityKit or SceneViewer.
• Model caching system with download progress indication.
• CMS integration — adding AR model field, API for data retrieval.
• Admin panel for uploading and managing 3D models (optional).
• Model conversion pipeline from source formats to USDZ/GLB with scale normalization.
• Analytics — tracking views and interactions.
• Documentation and training of the customer’s team.
• 3-month warranty support after launch.

Comparison: iOS vs Android

Timeline and Investment

Cost is calculated individually based on catalog size and need for model conversion. Investment in an AR catalog pays off through increased conversion and improved user experience. Contact us for a consultation and preliminary estimate. Order AR catalog development — get a solution that boosts conversion.

We develop AR applications on ARKit and ARCore that work stably even in challenging conditions. Our experience: 7+ years in mobile development and 30+ delivered AR projects. Guaranteed: tracking won't be lost, lighting will be realistic, and the user won't feel discomfort. Certified Apple and Google developers.

Why does tracking get lost and how to fix it?

ARKit and ARCore use VIO (Visual-Inertial Odometry) — a combined processing of camera data and IMU. Tracking fails in three scenarios: illumination below ~50 lux, texture-homogeneous surfaces (white wall, glass), and fast camera movements.

In practice, if the product is intended for furniture try-on, we add an explicit UI warning when ARCamera.TrackingState.limited(.insufficientFeatures). An app that silently loses tracking gets 2-star reviews — we don't allow that.

Plane detection is configured via ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Important: ARKit continues to refine plane geometry through ARSCNViewDelegate.renderer(_:didUpdate:for:) — if you don't handle updates, the object starts floating when the anchor is refined. Our team solves this at the architecture stage, not during testing.

AR Foundation: cross-platform with nuances

Unity AR Foundation is an abstraction layer over ARKit and ARCore. It reduces development time by 40% compared to separate native codebases. But some features (e.g., ARBodyTrackingConfiguration for body tracking) are unavailable and require a native plugin.

For React Native and Flutter, direct AR Foundation is missing. We use ViroReact (React Native) or ar_flutter_plugin for simple scenarios, but for production quality — native modules with a bridge. Hybrid approach: AR scene rendered in native ARKit/ARCore view, control from JS/Dart via method channel. Included in our standard delivery.

Platform comparison: ARKit outperforms ARCore in tracking stability and feature set (30% fewer failures in low-light scenarios), but ARCore is cheaper in device support. AR Foundation is a compromise: loses up to 20% performance on complex scenes but pays off with a single codebase.

Try-on: product fitting via AR

Fitting glasses, jewelry, cosmetics — a separate class of tasks. Here, face tracking is needed, not plane detection.

ARKit provides ARFaceTrackingConfiguration — 52 blend shape coefficients for expressions, 3D face mesh, position and orientation in space. Works only on devices with TrueDepth camera (iPhone with Face ID).

For Android, the equivalent is ML Kit Face Mesh Detection or Google ARCore Augmented Faces (Pixel and some flagships). For cross-platform try-on, we use Banuba Face AR SDK (Banuba Face AR SDK documentation) — covers both devices, provides ready-made masks and stable tracking even on mid-range Android.

Try-on quality critically depends on 3D product models. Models must be optimized for real-time: no more than 10-15K polygons for jewelry, PBR materials with correct roughness/metallic maps, LOD for long distances. Within our engagement, we provide ready-made optimization guides.

How to achieve realistic lighting in AR?

ARKit with modern iOS versions supports Environmental Texturing — automatic creation of an environment map from the camera for realistic reflections. Enabled via ARWorldTrackingConfiguration.environmentTexturing = .automatic. Without it, metallic and glass materials look plastic.

ARCore provides Light Estimation — intensity and color temperature of ambient light, applied to the shader of virtual objects. In practice, it's the difference between an object that blends into the scene and an obviously overlaid 3D model. We guarantee that the final image doesn't betray virtuality.

What's included

• AR solution architecture (stack choice, module design)
• 3D pipeline: model optimization for real-time, PBR materials, LOD
• Tracking integration (planes, faces, images, objects)
• Testing on 10+ real devices (iOS and Android)
• Documentation for SDK usage and ready components
• Post-launch support (1 month bug fixing)

Timeline and estimation

Simple AR scene with placing one 3D model on a plane — 1-2 weeks. Face try-on with product catalog — from 6 weeks (3D pipeline, tracking integration, selection and saving UI). Full AR shopping with cloud anchors and multiplayer — from 3 months. We'll estimate your project in 1 day — contact us to discuss your AR idea.