Persistent AR: Saving AR Scenes Between Sessions

Imagine: an interior designer places virtual objects in an empty room, closes the iPad, and the next day opens it — the entire scene is exactly where it was. No repositioning needed. That's Persistent AR — the ability to save AR scenes between sessions, which we implement turnkey. In commercial AR apps, failed relocalization is the top cause of negative reviews. We've learned to guarantee scene recovery in 95% of cases. For over 5 years, we've been developing AR solutions for iOS and Android, delivering more than 15 commercial projects where relocalization stability is critical. Contact us to discuss your project.

How Persistent AR Works

ARKit uses ARWorldMap — a snapshot of visual feature points that allows restoring the camera position relative to the saved environment. Serialization, local or cloud storage, loading, and running a new session with initialWorldMap — each step demands attention to detail. Example serialization in Swift:

arView.session.getCurrentWorldMap { worldMap, error in
    guard let worldMap = worldMap else { return }
    let data = try? NSKeyedArchiver.archivedData(withRootObject: worldMap, requiringSecureCoding: true)
    // save data to disk or cloud
}

Loading in a new session:

let worldMap = try? NSKeyedUnarchiver.unarchivedObject(ofClass: ARWorldMap.self, from: data)
let config = ARWorldTrackingConfiguration()
config.initialWorldMap = worldMap
session.run(config, options: [.resetTracking, .removeExistingAnchors])

After launch, ARKit tries to match the current scene with the saved points. Tracking status is monitored via session(_:cameraDidChangeTrackingState:): transitioning from .limited(.relocalizing) to .normal means success. More details in ARKit documentation.

Why Relocalization Might Fail

Changing lighting. Day and night produce different sets of feature points; contrast can drop by 30–50%. We solve this by saving multiple maps under different lighting conditions and selecting the closest one by match metric. Visual-Inertial Odometry has fundamental limits, so built-in ARKit tools cannot bypass this.

Anchor drift. On recovery, the position of an ARAnchor can shift by 2–5 cm. For objects where accuracy is critical (e.g., virtual furniture), after relocalization we snap anchors to the nearest surface using raycast.

Insufficient map quality. ARWorldMap has a mappingStatus property: .notAvailable, .limited, .extending. Saving a map at .limited means dooming the user to failure. We block the "Save" button until .extending and show a hint: "Slowly walk around the room."

How to Improve Map Quality

Here are three proven approaches tested in production:

• Data collection while moving. We prompt the user to walk around the room for at least 30 seconds — this increases the number of feature points by 70% compared to static capture.
• Filtering by mapping status. We never save the map until the status is .extending. Otherwise, relocalization will be unstable.
• Lossless compression. We use LZFSE (iOS 16+) or LZMA for archiving. Results:

LZFSE compression yields a 5x size reduction with minimal latency — ideal for cloud sync.

Storing User Data with the Map

Anchors are saved in ARWorldMap.anchors, but object metadata (model, color, price) must be stored separately and linked by ARAnchor.identifier. Example:

let metadata: [String: Any] = [
    anchor.identifier.uuidString: ["type": "sofa", "modelName": "ikea_kallax"]
]

On recovery, we match by UUID. This is standard practice, but often overlooked — some try to shove data into ARAnchor.name (a 256-character string without typing). For cross-device synchronization, we use CloudKit or Firebase, serializing maps with LZFSE.

Case Study from Our Practice

An interior design app with 3000 active users. The main pain point: users saved the map immediately after launch (at .limited mapping status) — and then complained about "floating" objects. We added a UI indicator for map quality (green/yellow/red) and blocked saving until green. Complaints dropped by 80%, and relocalization time decreased by 40% due to elimination of poor maps.

What's Included in the Work

• Requirements analysis: use cases, target devices, and iOS versions
• Design of storage scheme: local or cloud, multi-device support
• Implementation of ARWorldMap serialization/deserialization with compression
• Integration of cloud sync (CloudKit, Firebase)
• Testing on 10+ iPhone/iPad models with different iOS versions
• Documentation: architecture, limitations, testing instructions
• 1 month of support after delivery

Timeline

Cost is determined individually after requirements analysis. Get a consultation for your project — we'll help you implement Persistent AR on iOS or Android.

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.