Persistent AR: why scenes are not saved between sessions
The problem is almost never in recognition, but in the fact that an object's anchoring lives within a single session. The camera builds a map of the environment, the engine attaches virtual labels to it — and as soon as the app closes, that map dies along with the process.
On the next launch, the device sees the same room, but for it this is already a new scene: AR scene saving does not happen because there is nothing to save — the anchoring is not fixed anywhere.
The second reason is the absence of server-side synchronization. Even if the app caches a local map, it is tied to a specific device and its calibration. A second user entering the same point builds their own map, and the labels of the two devices do not match in space.
Objects "drift," duplicate, or disappear — this is exactly the data loss between sessions that the client sees as "the app forgot everything we placed."
The third reason is anchoring to a marker instead of anchoring to geometry. As long as there is a recognizable image in the frame, the label holds; the moment it is removed or the lighting changes, the anchoring breaks.
Persistent AR requires that an object be anchored to stable features of the space, not to a temporary visual anchor.
The root of the problem is one: the scene has no external state storage. As long as the map, the coordinates of the labels, and their identifiers are not taken outside the session and reduced to a common coordinate system, any AR scene saving remains an imitation. Let's break down how this is solved at the architecture level.
What AR scene persistence delivers: the effect in numbers
Persisting AR scenes between sessions is first and foremost an engineering discipline, not a visual effect.
When an app remembers spatial anchors and object state, the user doesn't have to re-map the room and re-place the scene: they open the app and land at the exact point where they left off.
This is where the measurable benefits show up — recalibration time, the share of successful returns to the scene, and the class of failures when anchors are lost.
Recalibration time is the most sensitive metric. Without scene persistence, every entry starts from scratch: finding reference points, manual mapping, waiting for tracking to stabilize.
With persistent AR, this stage shrinks to checking the saved map: the app compares the current camera position against the recorded anchors and either instantly restores the scene or offers a short top-up.
In practice, this is the difference between "half a minute to get in" and "a couple of seconds to a working state."
The share of successful returns to the scene depends on how robustly the anchors are stored. If the map is tied to a single point and the user approaches from the other side, restoration breaks down.
That's why we store multiple reference anchors and allow partial matching: the scene assembles even if not all of the geometry is recognized.
This raises the share of successful returns and eliminates the most common frustration scenario — "the app forgot everything again."
The class of failures when anchors are lost also changes. Instead of a hard drop into an empty scene, the app switches to a soft degradation mode: it preserves the last known state, shows a recovery hint, and doesn't lose user data.
We design this behavior upfront — at the level of the scene storage model, not as a patch on top. We've honed this approach in projects on ARKit and similar platforms, where anchor stability directly affects retention.
Anchor stability is also a matter of versioning. A scene saved on one version of the app must open correctly after an update, otherwise the user loses accumulated content. We lock down the storage format and provide for migration so that an update doesn't wipe the scenes.
Taken together, these measures deliver a predictable return to the scene and fewer failures — what the client sees as "the app works reliably."
Approaches to storing anchors: comparison of methods
An AR scene anchor is the coordinates and orientation of the anchor in physical space plus metadata: an identifier, creation time, and binding to a user or device.
Where this data lives determines whether a guest will see their scene after restarting the app and whether a colleague on another device will find it. Below are three schemes that are realistically chosen between at the start of a project.
| Option | When it fits | Limitations |
|---|---|---|
| Local anchor cache | One user, one device, scene needed offline | The scene does not survive app reinstallation and is not visible to others; when switching devices, the anchor is lost |
| Cloud synchronization | Multiple users, shared scenes, device switching | A stable channel is required; if the connection drops, the scene does not load, and conflict resolution is needed for simultaneous editing |
| Hybrid scheme | Production with offline scenarios and shared objects | Harder to maintain: two sources of truth, an explicit merge policy and versioning of records are needed |
The local cache provides minimal latency — the anchor is read from disk in milliseconds and works without a network, but it is a dead end for team scenarios.
The cloud decouples the anchor from the device, but adds a network dependency and the question of whose edit wins when the anchor is changed simultaneously.
The hybrid covers both cases: a fresh anchor is written locally and goes to the cloud, changes are pulled in at startup, and discrepancies are resolved by the time of the last edit.
The storage limitations here are not about volume — there are few records — but about lifetime: stale anchors accumulate and produce false matches, so a cleanup policy based on age and activity is needed.
How we implement persistent AR: stages of work
Implementing persistent AR begins with an audit of what already exists in the app: how the scene is structured, where object anchors to real surfaces are stored, and what data is lost when a session closes.
At this stage, we document the current architecture, failure points, and requirements for scene restoration — everything downstream depends on this.
After that, the work proceeds in stages, each ending with a verifiable result:
- AR scene audit — we analyze the current implementation, determine which objects must persist between sessions, and identify where state loss occurs.
- Anchor scheme design — we describe how objects are anchored to real points and surfaces so the scene restores correctly on relaunch.
- Synchronization setup — we establish data exchange between the device and storage: what goes to the server, what stays local, and how conflicts are resolved during desynchronization.
- Scene restoration implementation — the scene is rebuilt from saved anchors, including object positions, their state, and display order.
- Stability testing — we test scenarios with connection loss, device changes, re-entry, and long pauses between sessions.
- Documentation handover — we deliver the anchor scheme description, storage operation regulations, and instructions for ongoing support.
What we check at each step
We separately run edge cases: what happens if a user returns to the scene a week later, switches devices, or loses network connectivity at the moment of saving.
Such checks reveal where the anchor scheme holds up under load and where it breaks — and allow us to fix these areas before release, rather than after user reports.
What the client retains
As a result, the team receives not only a working feature but also a clear data scheme, synchronization regulations, and documentation that allows support to be maintained without us. If needed, we provide post-launch support and refine scenarios as load grows.
What the client receives after implementation
Persistent AR implementation does not end with a demonstration: a scene that survives an app restart is a set of artifacts that your team can use to operate, extend, and restore it without us. Below is exactly what we hand over.
- Binding configurations. Files that describe which anchor points and markers objects are attached to, how re-recognition is handled when the camera shifts, and what happens when tracking is lost. Editable without rebuilding the app.
- Storage schemas. The structure of the local cache and server-side storage: which scene data resides on the device, which is synchronized, and how conflicts are resolved when two devices edit simultaneously.
- Access policies. Roles and permissions for creating, viewing, and modifying scenes, integration with your account system, and sharing rules between users and external guests.
- Documentation. A description of the scene format, object lifecycle, extension points, and platform limitations — with examples that onboard a new developer into the project without verbal explanations.
- Recovery procedures. Step-by-step scenarios for scene corruption, desynchronization between devices, or synchronization failure: how to roll back to the last intact version and what to check afterward.
- Migration and maintenance scripts. Updating the scene format between app versions, cleaning up outdated bindings, and transferring data when switching storage.
- Metrics and monitoring. A set of indicators for scene stability and the share of successful session recoveries, so degradation is visible before users complain.
We coordinate each item with your team during the handover stage: we walk through the configurations on a live project and run the recovery procedure on a test scene. Describe your task — we will come back with an estimate and a plan for the scope of these artifacts.
Case Study: Preserving AR Scenes in an Industrial Application
The client — a manufacturer of industrial equipment — came with a challenge: service engineers at sites mark maintenance points of units using AR scenes, but the markup only lived until the application was closed.
After a restart, the scene disappeared, and the engineer had to recalibrate using fiducial markers — this took up to 15 minutes per unit, and some scenes could not be restored at all.
We reworked scene storage: the anchoring no longer depended on the session or on the camera position at the moment of startup.
Each scene received a persistent identifier and an anchor to the physical reference points of the object, and the state is saved on the device and synchronized between engineers.
On re-entry, the application recognizes the point, pulls up the saved markup, and overlays it on the current view — without manual calibration.
What changed in numbers
| Metric | Before | After |
|---|---|---|
| Share of successful returns to a scene | ~40% | 96% |
| Recalibration time | up to 15 min | 20-30 sec |
| Resilience across restarts | scene was lost | preserved |
| Scenes restored after a failure | 0 | all active |
We also addressed resilience separately: if the application crashes or the device reboots, the scene is restored from the last consistent state rather than from scratch. Engineers no longer spend a shift on re-marking — at a site with 30 units, several hours of work are saved.
The project was led by our mobile development engineer together with the client's team; the stack and tools were selected for the task — ARKit and ARCore as the base platforms, with a proprietary scene storage layer on top.
How does persistent AR differ from session-based AR?
Session-based AR lives exactly as long as the camera is open: the user points the device, sees the object, closes the screen — and the entire scene disappears.
Persistent AR preserves the anchoring of a digital object to a physical place between app launches, so the user returns and sees the same content in the same place where they left it.
The difference starts with the anchor. In session mode, the anchor exists in RAM and dies with the session — there is nothing to anchor it to except the current frame.
In persistent AR, the anchor must be saved: its coordinates must be written in the world reference frame, and then on a new launch the position must be restored relative to the recognized environment map.
Hence the accuracy requirement — if the map is rebuilt with an offset, the object will "drift" by tens of centimeters, and the user will notice it immediately.
Next, the application architecture diverges. Session-based AR only needs a camera and a rendering layer: the state lives in memory, there is nothing to synchronize.
Persistent AR requires storage for anchors and maps, a mechanism for relocalization upon entering the zone, and conflict resolution rules when two users anchor objects to the same point.
A server-side component appears, and with it — questions of access, scene versioning, and rollback if a map update corrupted the anchors.
The user experience differs not by "effects" but by scenarios. Session-based AR is suitable for try-on, product demonstration, a one-time hint — there the value is in the moment.
Persistent AR unlocks what lives over time: markers on infrastructure objects, navigation through a mapped building, collective scenes where each subsequent visitor sees the traces of previous ones.
The choice between approaches is a choice between one-time interaction and accumulation of state, and it determines whether the app will need server-side synchronization at all.
Technical doubts and limitations
Persistent AR runs up against four engineering constraints: device support, the volume of stored data, anchor protection, and migration of already-created scenes. Let's break down each one — along with how it is addressed in practice.
Device compatibility
Saving a scene requires the device to be able to build and maintain an environment map. On models without the required set of sensors or without support for the required level of tracking, the scene either will not restore or will end up misaligned.
That is why we divide the device fleet in advance into those where persistent AR works fully and those where we enable a simplified mode — anchored to a marker instead of a map. The user does not see the difference in the scenario, but does not get a broken scene.
Data volume and anchor security
The environment map and anchors weigh little, but with hundreds of scenes per site, storage starts to grow. We keep only active scenes on the device, the rest — on the server, with on-demand loading; unused anchors are archived according to the retention rule.
An anchor is a coordinate in the physical world, and substituting it means showing the user someone else's object. That is why the anchor record is signed, and access to the scene is verified by role: a guest views, an editor changes, an owner deletes.
Scene migration
Scenes assembled on the old markup format are transferred by a script: anchors are recalculated into the current coordinate system, attachments are re-linked by identifiers.
If a scene referenced a deleted object, migration marks it as requiring manual review rather than crashing it on open.
What happens if the user updates the app and the scene does not open?
Older versions of the format are read back — we maintain read compatibility at least two branches back.
If a scene is assembled in a format that the current version does not understand, the app does not crash, but offers to update the scene or open it in view-only mode without editing.
Can an anchor be rolled back if the scene ends up misaligned?
Yes. For each scene, the previous anchor state is stored, and a rollback returns it to a working anchor. If the misalignment is caused by a change in the room itself, the scene is re-anchored from scratch — by marker or by a new environment map.
Let's discuss your AR scene persistence task
To come back with an assessment and an implementation plan rather than generalities, we need to understand your current implementation: where AR scenes are stored between sessions, how anchors are tied to physical space, and what happens when the app is re-entered. Describe the task — an engineer will analyze it in detail and propose a working solution.
- Current stack: augmented reality engine, platform (iOS/Android/cross-platform), version, and tracking mode.
- How the scene is currently saved: local storage, cloud, anchoring to coordinates or to visual markers.
- What already works and where it breaks: loss of position on restart, anchor drift, desync between devices.
- Constraints: offline mode, anchor accuracy requirements, number of concurrent users in a single scene.
- Target metrics: scene restoration time, allowable object displacement, share of successful repeat sessions.
- Access and environment: test builds, devices, access to the backend and storage for validating hypotheses.
Based on these inputs, we will come back with a work estimate and implementation plan: which layers need refinement, what we reuse from the current code, and what we rewrite.
An engineer's consultation at this stage is an analysis of your architecture and risks, not general recommendations.
Describe the task in free form — send us the current implementation, logs, or a description of the failure. We will come back with an estimate and a work plan.