Cloud Anchors for Multi-User AR: Real-Time Cross-Platform Sync

Two iPhones in the same room. User A places an AR object on the table. User B sees the same object on the same table, in the same position — in real time. No QR codes, no markers, no prior calibration. We implement such synchronization using Cloud Anchors — a technology where the anchor is created locally, uploaded to the cloud, and other devices download and localize relative to it. Our team has 5+ years of AR development experience and has successfully deployed such solutions in 15+ projects, including quests, training, and industrial tasks.

Which Technology to Use: ARCore or ARKit?

The choice depends on your target audience and use case.

ARCore Cloud Anchors — a cross-platform solution. Works on iOS via the ARCore SDK for iOS and on Android natively. Anchors are stored on Google servers, with a TTL from 1 day to 365 days depending on settings.

Anchor creation:

// iOS, ARCore SDK
let anchor = garSession.createAnchor(at: transform)
garSession.hostCloudAnchor(anchor, ttlDays: 30) { cloudAnchorId, error in
    // cloudAnchorId — string, pass to other participants via your backend
}

Anchor resolution on another device:

garSession.resolveCloudAnchor(cloudAnchorId) { anchor, error in
    // anchor.transform — position in world space of this device
}

Apple Shared AR via ARKit + MultipeerConnectivity — works only between Apple devices, no external server. Devices exchange ARWorldMap directly over local network. Limitation: requires one "host" that saves the map and distributes it to participants.

For production cross-platform apps — ARCore Cloud Anchors. For Apple-only and offline scenarios — MultipeerConnectivity. ARCore Cloud Anchors can speed up session deployment by 3x compared to ARKit MultipeerConnectivity thanks to cloud infrastructure. More details in the Google ARCore documentation.

What Problems Arise in Multi-User AR?

Scene state synchronization. Cloud Anchor provides a common coordinate system. But data about who placed what, where they moved, what was deleted — that's your layer. A real-time channel is needed: Firebase Realtime Database, Supabase Realtime, or a custom WebSocket. Typical scheme: event objectPlaced(anchorId, modelId, transform) → broadcast to all participants → each applies locally. Latency over LTE: 150–300 ms, acceptable for most games.

Drift between devices. Two iPhones localize relative to the Cloud Anchor independently. Positioning error is 1–5 cm in good lighting. Under poor lighting or low-texture surfaces — up to 10–15 cm. Acceptable for gaming; not for industrial tasks (equipment marking, assembly).

Anchor resolution time. resolveCloudAnchor can take 2–10 seconds while the device collects enough feature points to match the cloud anchor. During this time, you must show the state GARCloudAnchorState.taskInProgress and prevent user interaction. We improve UX with loading animations and pre-localization.

API limits. Google Cloud Anchors: 1,000 free resolve operations per day, then paid. With an active audience, this limit is hit quickly — plan ahead. Our engineers help design an architecture that minimizes resolutions and reduces cloud costs. For example, with 8 simultaneous participants and 5 anchors per session, the 1,000-resolve budget allows about 25 sessions per day. Proper TTL configuration reduces repeated resolve operations by up to 30%.

Cross-Platform AR Multiplayer Architecture

Device A (iOS/Android)
  → creates Cloud Anchor → gets cloudAnchorId
  → sends cloudAnchorId to backend (REST/WebSocket)

Backend (Firebase / custom server)
  → stores cloudAnchorId + session metadata
  → broadcasts events to participants

Device B (iOS/Android)
  → receives cloudAnchorId
  → resolveCloudAnchor → builds common coordinate system
  → receives events → applies changes locally

Case study: AR quest in a shopping mall, 8 simultaneous participants. ARCore Cloud Anchors at points of interest (entrance, department, checkout). Each anchor is a task with a virtual object. Synchronization via Firebase Realtime Database: event "player X found object Y" → object disappears for all. Latency between event and update across all participants is 150–300 ms over LTE. We guarantee stable operation under any lighting conditions.

What's Included

1. Integration of ARCore SDK for iOS or configuration of MultipeerConnectivity for Apple-only.
2. Creation and resolution of Cloud Anchors with error handling and timeouts.
3. Implementation of real-time scene state synchronization.
4. UI for statuses: waiting for participants, resolving anchor, desync.
5. Testing with real devices under varying lighting conditions.
6. Performance optimization for target devices.
7. Assistance in choosing optimal TTL and anchor resolution strategy to minimize costs.

Timelines

Pricing is calculated individually after discussing architecture requirements and target audience.

To discuss your project, contact us — get a consultation on architecture and timeline estimate. Order development, and we'll propose the optimal solution for your needs.

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.