Cloud anchors for multiplayer AR implementation

Implementing Cloud Anchors for Multi-User AR

Two iPhones in one room. User A places AR object on table. User B sees same object on same table, same position — in real-time. No QR codes, no markers, no pre-calibration.

This is Cloud Anchors — technology where anchor created locally, uploaded to cloud, other devices download and localize relative to it.

Two Paths: ARCore and ARKit

Google ARCore Geospatial API and Cloud Anchors — cross-platform solution. Works on iOS via ARCore SDK for iOS and on Android natively. Anchors stored on Google servers, live 1 day to 365 days depending on settings.

Creating anchor:

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

Resolving anchor on other 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 via local network. Limitation: need one "host" saving map and distributing to participants.

For production apps with cross-platform — ARCore Cloud Anchors. For Apple-only and offline scenarios — MultipeerConnectivity.

Main Problems of Multi-User AR

Scene state synchronization. Cloud Anchor gives common coordinate system. But data about who placed what, where moved what, what deleted — this is your layer. Need realtime channel: Firebase Realtime Database, Supabase Realtime, or own WebSocket. Typical scheme: event objectPlaced(anchorId, modelId, transform) → broadcast all participants → each applies locally.

Drift between devices. Two iPhones localize relative to Cloud Anchor independently. Positioning error — 1–5 cm with good lighting. In poor lighting or low-textured surfaces — to 10–15 cm. For games acceptable. For industrial (equipment marking, assembly) — no.

Anchor resolution time. resolveCloudAnchor can take 2–10 seconds while device collects enough feature points to match cloud anchor. Show GARCloudAnchorState.taskInProgress during this, don't let user interact with scene.

API Limits. Google Cloud Anchors: 1000 free resolve operations per day, then paid. Active audience hits this limit fast — need to plan ahead.

Cross-Platform AR Multiplayer Architecture

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

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

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

Case: AR quest in shopping mall, 8 simultaneous participants. ARCore Cloud Anchors at points of interest (entrance, dept, checkout). Each anchor — task with virtual object. Sync via Firebase Realtime Database: event "player X found object Y" → object disappears for all. Delay between event and update for all participants — 150–300 ms via LTE.

What's Included

• ARCore SDK integration for iOS or MultipeerConnectivity setup for Apple-only
• Creating and resolving Cloud Anchors with error/timeout handling
• Implementing realtime scene state synchronization
• UI for states: waiting participants, resolving anchor, desynchronization
• Testing with real devices in various lighting conditions

Timeline

Cost calculated individually after discussing architecture and target audience.