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 a

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
AR Product Catalog: Technical Implementation Guide
Complex
~2-4 weeks

Our competencies:

Frequently Asked Questions

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    897
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    784
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1216
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1081
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    1004
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    599

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

Criteria iOS (ARKit + RealityKit) Android (SceneViewer + ARCore)
Model format USDZ GLB
Implementation complexity High (native SDKs) Medium (depends on Google Play Services for AR version)
Available gestures Built-in recognizers Via Sceneform / SceneView
Performance Excellent on devices with A12+ Good on ARCore-certified devices

Timeline and Investment

Feature Timeline
Basic AR viewer for one item 1–2 weeks
AR catalog with caching and color variants 4–6 weeks
Full system with CMS, analytics, iOS+Android 3–5 months

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.

Tips for preparing 3D models
  • Use meters as units.
  • Ensure correct orientation (Y axis up).
  • Optimize polygon count: for furniture ~50k triangles.
  • Compress textures to 2K.
  • Test models on real devices.