Indoor Navigation AR Mobile Application Development
GPS doesn't work inside buildings. A user at London Heathrow standing at exit C12 tries to find the arrival hall via a map app—the map shows a blue dot somewhere in the terminal area, 10–20 meter error. AR indoor navigation solves this fundamentally differently: the phone camera reads the environment and builds a route overlaid on real footage with 1–2 meter accuracy.
Three Indoor AR Navigation Architectures
VPS (Visual Positioning System)
Most accurate, most expensive to prepare. Space is pre-scanned (LiDAR, photogrammetry), point cloud or visual map built. Phone sends camera frame to server → server matches against visual map → returns position and orientation. Google Maps Indoor (major venues), Immersal SDK, Sturfee—working solutions. Immersal provides Unity plugin and REST API for localization; we integrate their SDK into native iOS/Android code via FFI.
Limitation: must rescan after furniture moves or renovations. Plus server inference costs.
Marker-based + Floor Map
Faster to deploy. QR codes or ArUco markers with known floor-plan coordinates placed throughout space. ARImageTrackingConfiguration (iOS) / AugmentedImageDatabase (ARCore) identifies nearest marker → calculates user position → routes via room graph.
Routing algorithm: graph with nodes (markers, turn points, doors, elevators) and edges (corridors). Dijkstra or A* for shortest path. AR arrow drawn as ARAnchor chain 1.5 m above floor along route points.
IMU + PDR (Pedestrian Dead Reckoning)
No markers, no server. CMMotionManager (iOS) or SensorManager (Android) reads accelerometer + gyroscope + barometer. PDR algorithm counts steps (via acceleration magnitude threshold), direction from gyroscope, floor from barometer. Drift accumulates—2–3% of distance traveled. Use as fallback or combined with marker correction.
Displaying AR Route
Common error: draw arrow on screen in 2D over camera. That's not AR—that's primitive HUD. Real AR route—3D objects anchored in world coordinates, following camera movement. Implementation:
// iOS: create ARAnchor chain along route
routePoints.forEach { point in
let anchor = ARAnchor(transform: point.transform)
sceneView.session.add(anchor: anchor)
}
// RealityKit: attach arrow ModelEntity to each anchor
Arrow smoothly rotates toward next point via simdLook(at:). On point passage—remove from session, add next batch. Distance to destination updates via ARCamera.transform → calculate Euclidean distance to destination anchor.
Floor transitions—separate logic: detect elevator/escalator entry via barometer (CMAltimeter) and floor-change in route graph.
Venue Integration
Floor plan formats: GeoJSON (open standard, supports indoor), IndoorGML, IMDF (Apple Indoor Maps). For shopping centers, often work with IMDF—Apple Maps natively supports this format. Tenant data (stores, hours, categories) pulled via venue CMS.
Workflow
Space survey (scanning or obtaining plans) → build navigation graph → choose positioning technology → develop AR module → integrate with venue CMS → test on-site → iterate on accuracy.
Timeline: pilot on single floor with marker navigation—6–10 weeks. Multi-floor system with VPS and venue CMS integration—4–8 months. Cost depends on venue size and chosen positioning method.