Mobile app development for AR scene content management

Why a mobile app and AR CMS diverge in data

Typical breakdown: a guide edits the order of steps and captions in the control panel, clicks "publish," and an hour later the tablets on site still show the same old scene.

The mobile app for AR pulls the data set once at launch and keeps it in local cache — without version checking and without forced update. Scene version mismatch becomes not a failure but the normal mode of operation.

The cost of the error isn't cosmetic.

The guide leads a group along a route that no longer exists on the device, markers on physical objects don't match virtual layers, and the on-site operator doesn't understand whose version is "correct." Every edit turns into a roll call: who updated, who didn't pull it, who needs to reinstall the app manually.

The root is usually that scenes are assembled in editors like Adobe Aero, published through a separate panel, and the media library lives on its own. The scene manifest references files by names, not by content, so replacing a model under the same name is invisible to the cache.

Publication is non-atomic: the description is updated, heavy models are still loading — and the device assembles a scene from a mix of old and new.

Next — how this is closed: versioning of scenes, synchronization of the media library by checksums, and predictable delivery of builds to the entire fleet of site devices.

What app integration with AR CMS gives: measurable effects

Updating scenes without a rebuild

Editing text or object position in a scene used to mean a new build and re-review in stores — the update reached users in days. Now the app fetches the scene manifest from AR CMS at startup, and publication in the editor becomes visible in minutes, without releasing a build.

Single source of content

Scenes, captions, markers and display rules are described by one data model read by the app and the web version. The editor changes a record in the interface — both surfaces show the same thing; on Strapi this scheme is assembled with standard tools, without duplicates in tables.

Update release time

The typical cycle "edit — review — publish" shrinks from several days to a couple of hours: content passes a test scene and goes to devices. Planned releases remain — but only for changes in the app logic itself.

Reduction of manual edits

A noticeable part of requests like "fix the caption" is closed by the editor independently, with roles and change history.

The share of tasks reaching developers drops severalfold — the team deals with scene mechanics, not cosmetics, and the volume of manual support decreases.

Outdated content and recovery speed

Versioning removes the case when part of the devices retains an old scene version: the state snapshot is tied to publication and distributed with a version tag.

Rollback to the previous one takes minutes and is done from the panel, and if the service is unavailable the app works on the last locally saved copy.

Methods of delivering AR content to a mobile device

An AR scene is not a picture, but a bundle of models, textures, videos and anchor markup. If you pull it at display time, on a site with weak connection the user gets an empty screen instead of an overlay.

Therefore the content delivery mode to the device is chosen for the work scenario, not for build convenience.

We assemble scenes into the open glTF format with a package manifest: composition, version, checksum, build date.

The app compares the manifest with local content storage and downloads only changed files — preloading at a new site takes minutes, rather than re-downloading the entire set.

We fix the delivery mode at the design stage together with the scenario: where the user works, whether there is connection, how fast display should start, who updates scenes.

Then this turns into a preload schedule, storage policy and version revocation rules — so an edit on the server doesn't break display for those who already went offline.

Stages: media library audit, synchronization scheme, acceptance

Development starts not with code, but with inventory: what is already in the media library, in what formats scene resources are stored and who uploads them. Without this, the synchronization scheme is built at random, and mismatches between devices surface already at acceptance. Below are seven stages that we go through on every project.

1. Media library audit. We make an inventory of scenes and related resources, mark duplicates, outdated versions and materials that are not exposed to the app. We get a list: what we migrate, what we archive, what we rebuild from scratch.
2. Scene access rules. We describe entities — scene, version, target device, role — and the permission matrix: who edits, who approves publication, who can roll back changes.
3. Synchronization scheme. We define the source of truth, the order of resolving simultaneous edits and how the app downloads the changed fragment without re-downloading the entire scene.
4. Testing the scheme on a real set. We run synchronization on a media library copy: we look at the volume of transmitted changes, behavior without network and return to the previous scene version.
5. Implementation of the editor and client. We build the scene management interface and the app that displays them on one data model — there's nowhere for a mismatch between them to come from.
6. App acceptance. We go through scenarios by checklist: publication, rollback, edit conflict, weak network. We close every defect before handover, not after launch.
7. Handover and support. We hand over the build, data model description and procedure: how to add scenes, how to grant access, how to update the app without stopping editorial work.

Delivery package: builds, storage schemes, accesses, procedures

After handover, the customer retains not only a working app, but the entire set of artifacts from which it can be built, updated and developed without our involvement. Everything listed is registered to your accounts and media — not ours.

• Builds and signing keys. Release and test builds for Android and iOS, signing keys, instructions for re-releasing a new version on your own.
• Source code. Client applications, server side of the content management panel, change history and release branches in your code repository.
• Content storage schemes. Directory structure of AR scenes, versioning rules, formats of models, textures and sound, links between scene and marker.
• App documentation. Description of modules, integration points, environment parameters, build order, publishing in stores and rollback to the previous release.
• Accesses. App store accounts, content management panel, servers, file storage and analytics — with roles and permission restrictions.
• Support procedures. Content update order, role model of editors, backup schedule, actions on scene loading failure.
• Instructions for editors. How to upload a scene, link it to a marker, check on a device, publish and roll back to the previous version.
• Acceptance checklist. Permission matrix, known limitations log, test results on real devices and in a weak network.

The point of such a package is simple: support can be transferred to another team or run on your own, without reconstructing the architecture from memory and without buying back accesses.

Case: scene media library and faster update release

Customer — a network of exhibition venues: a mobile app guides the guest along AR routes that change for each event.

Scenes lay as archives at venues and were assembled manually: an update reached all points in three weeks, and build mismatch between halls was discovered from guest complaints.

What changed in the media library and synchronization

We moved scenes into a single library with content-addressable identifiers: identical models, textures and sound are stored once, not as a copy for each venue.

Delivery goes in deltas — only the changed scene layer in glTF format goes to the device, and local cache keeps the previous version for rollback without reinstalling the app.

Metrics before and after: update release shrank from three weeks to four days, media library volume decreased almost threefold due to deduplication, the share of scenes that reached all venues without manual edits grew from 70% to 99%. Sorting out version mismatches left routine administrator tasks.

Post-launch support is built on telemetry: the app itself reports failed loading or checksum mismatch, and engineers learn about failure before the guest. A new scene first passes validation at one venue — rollout to the entire network goes only after confirmed metrics.

Native build or cross-platform: what to choose

For an AR scene editor, the choice between native and cross-platform build is decided not by team taste, but by the depth of work with platform augmented reality kits.

If camera, position tracking and lighting are taken from the platform, and the scene is assembled in a common layer, the cross-platform path pays off: one codebase, one set of automated tests, synchronized releases.

As soon as you need custom effects and precise surface detection, the common layer hits platform limitations.

On complex editors, the mixed option more often wins over extremes: the common layer holds the scene catalog, interface and synchronization, while camera, tracking and background model loading remain platform-dependent.

We decide by metrics — time to first AR frame, build weight, share of platform-dependent code, update frequency.

If differences between platforms fit into one or two modules, a cross-platform core removes half of the support work. If divergences go deeper, it's cheaper to write natively right away than to cut out the common layer later.

Common technical doubts before project start

Engineering doubts before start usually concern not functionality, but operating conditions: resilience at a site without stable connection, project handover to your team, already assembled media library and rights of different roles. We address each point specifically.

What happens after project handover to our team?

We hand over the repository, build configurations, data schemes and release procedure — your team builds and publishes the release independently. Further support goes by criticality levels: content update, fixes, functionality improvements.

We already have a deployed media library — will it have to be rebuilt?

No. We migrate in stages: first inventory of assets, metadata and links between scenes, then import with link validation, publication — only after reconciliation. Previous materials remain available until correctness of the new ones is confirmed.

How is access divided between roles?

We separate roles by tasks: scene author, editor, publisher, observer. Rights are granted at object and group level, every action goes into the log, login is through corporate identity so access is revoked when an employee changes.

Let's discuss the task: how we start work

Starting a substantive conversation is easier than preparing a full technical specification. Send what you have: description of scenes and AR content, how it currently gets into the app, who changes it and how often, on which platforms the audience works.

If you have an interface draft, storage scheme or examples of model and texture files — attach them, they'll help us understand the scope faster.

In response you'll receive an estimate and work plan: what we do at the AR CMS design stage, what at the development stage, where your decisions are needed, and where we propose a default option. We separately discuss source code handover, so code and accesses remain on your side.

• breakdown of editor scenarios: how a content manager assembles a scene without a developer
• data scheme and storage structure of scenes, assets and versions
• role and permission model: who publishes, who approves, who rolls back
• architecture of synchronization between the panel and applications and offline cache
• stage-by-stage work plan with acceptance points at each
• handover composition: repositories, build configurations, API documentation
• support order: scene catalog updates, app version compatibility

Describe the task in any convenient form — we'll return with an estimate and work plan and propose a project start date.