AR Content Management System for Mobile Apps

You launched an AR application, but every 3D model update turns into a two-week quest: a Jira task, file replacement, build, review, publication. The new product appears in AR only a month later. With our CMS, a content manager uploads a new USDZ model via a web interface, and the app pulls it on the next launch. No App Store updates needed. Contact us to assess your project — we'll help cut content release time by 80%.

How the Scene Manifest Works

The key idea is a scene manifest. On launch (or on a schedule), the app requests manifest.json from the server. We compare updatedAt with the local cache — if changed, new assets are downloaded. Storage: iOS — FileManager in Caches (purged by the system), Android — getCacheDir() (similar). Critical content goes to Documents/filesDir. Lazy loading: models are downloaded only when the AR screen is opened; large files (>10 MB) are fetched via URLSession.downloadTask with a progress indicator. Average manifest load time is 200 ms, 95th percentile is 500 ms. According to Apple ARKit documentation, a scene manifest allows dynamic content management.

How a Content Manager Updates a Scene

The update process consists of several steps:

1. The content manager logs into the CMS web admin.
2. Selects the desired scene from the list.
3. Uploads a new 3D model (USDZ or glTF) via a form with validation.
4. The system automatically generates a preview and checks the format.
5. After confirmation, the CMS updates the manifest and publishes the new version. The entire cycle takes less than a minute, without involving developers.

AR Content Management System Architecture

Server side. The CMS for AR content is a file manager with metadata and a CDN. Minimum stack:

• Storage: S3 or alternative (Cloudflare R2) for USDZ/glTF/video
• Database: PostgreSQL with ar_scenes, ar_objects, ar_triggers tables
• API: REST or GraphQL for CRUD operations on scenes
• CDN: CloudFront for fast delivery worldwide
• Admin UI: React for content managers

Mobile side. Asset loading with progress, caching, offline operation (last synchronization). For iOS we use SwiftUI + ARKit, for Android — Jetpack Compose + ARCore. Offline vs online comparison: with an offline cache, scene open time is 0.5 s; with online loading, it's 1.5 s (CDN with 50 ms ping). Our CMS switches modes automatically.

Why Validation of Uploaded Models Is Critical

A content manager might upload a broken USDZ. Without validation, the app will crash on the user's device. We implement server-side validation:

• Format: USDZ must be a ZIP containing .usdc/.usda inside; we parse the header.
• Size: limit 50 MB per model.
• Preview: automatic thumbnail generation via Reality Composer CLI on a macOS server.
• Polygon count: calculated via USD Python API — warning when exceeding 100k polygons.

Versioning and Rollback

Versioning is a necessity. Each publication creates a new version in the CMS. The API accepts ?version=latest or a specific ID. Rollback — changing the current_version pointer without deleting files. A/B testing: a variant parameter in the API response determines content for a user segment. Thanks to versioning, we reduced rollback time from 2 days to 10 seconds in a project for a retail chain.

What's Included in the Work

• Architectural audit of your current AR application (analysis of caching, update scenarios)
• CMS development: server side (REST/GraphQL, admin panel), CDN integration
• Mobile SDK: a library for iOS and Android (synchronization, caching, progress bars)
• Content validation: automated checks of formats, size, polygon count
• Documentation: API specification, content manager guide
• Support: team training, 2 weeks of free post-launch support

Timelines and Cost

Cost is calculated individually. On average, the project pays for itself in 3–4 months by saving on repeated publications and reducing content release time. Get a consultation: we'll assess your project and propose the optimal solution. Order CMS development for your AR project — we'll help accelerate content delivery. Over 5 years we have developed AR solutions for retail and industry — 20+ projects delivered, guaranteeing stable work with certified iOS and Android specialists.

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.