AR Indoor Navigation: Mobile App Development Service

GPS indoors provides 10–20 meter accuracy—insufficient for finding gate C12 in an airport or a specific store on the third floor of a mall. AR indoor navigation solves this: the phone's camera and sensors determine position with 1–2 meter accuracy and overlay the route onto the live view. For example, visitors see virtual arrows pointing toward the desired boutique directly on their screen. We have been developing such solutions for over 10 years: 40+ projects for malls, airports, and offices. With a hybrid architecture combining VPS for high-traffic zones, markers for precise anchors, and PDR as fallback, we consistently achieve 1–2 meter positioning accuracy even in challenging conditions: mirrored floors, brightness changes, or large crowds. Our experience guarantees that your indoor navigation app will meet the highest standards. Trusted by 40+ venues, we provide a 12-month warranty on software stability.

Choosing the Positioning Method

Selecting the right technology is key. In our practice, three approaches are most common: VPS (Visual Positioning System), marker-based navigation (QR/ArUco), and PDR (Pedestrian Dead Reckoning). The comparison below helps determine the best fit for a specific venue.

Marker-based navigation is 3x faster to deploy than VPS. For cost efficiency, hybrid systems cut operational costs by 30–40% compared to pure VPS.

AR SDK Comparison for Indoor Navigation

We help determine the optimal method during a venue audit. Contact us for a preliminary assessment.

Why Combined Methods Deliver the Best Results

No single method is perfect. VPS is accurate but expensive to prepare and requires server infrastructure. Marker navigation is cheaper, but markers need updates after every layout change. PDR is fully autonomous but accumulates error over time. A combination—for instance, markers for initial calibration and PDR for between-marker transitions—gives stable 1–2 m accuracy without constant scanning. Research shows hybrid systems cut operational costs by 30–40% compared to pure VPS. For a 50,000 m² mall, a pure VPS system would require monthly server inference costs of about $3,000, whereas a marker + PDR hybrid reduces that to $500, maintaining accuracy within 2 meters. Payback period: 6–8 months. Our development costs start from $10,000 for a basic marker system. VPS indoor projects requiring scanning typically range from $25,000 to $50,000.

Three Architectures for Indoor AR Navigation

VPS (Visual Positioning System)

The most accurate, but the most expensive to prepare. The venue is pre-scanned (LiDAR, photogrammetry) to build a point cloud or visual map. The phone sends a camera frame to the server → server matches against the visual map → returns position and orientation. Google Maps Indoor (for large venues), Immersal SDK, Sturfee are working solutions. Immersal provides a Unity plugin and REST API for localization; we integrate their SDK into native iOS/Android code via FFI. Limitation: the map must be rescanned after furniture rearrangement or renovation. Plus server inference costs.

Marker-based + Floor Map

Faster to deploy. QR codes or ArUco markers with known coordinates on the floor plan are placed throughout the venue. ARImageTrackingConfiguration (iOS) / AugmentedImageDatabase (ARCore) detects the nearest marker → computes user position → calculates a route using the venue graph. Routing algorithm: graph with nodes (markers, waypoints, doors, elevators) and edges (corridors). Dijkstra or A* for shortest path. AR arrows are rendered as an ARAnchor chain at 1.5 m above the floor along route points.

IMU + PDR (Pedestrian Dead Reckoning)

No markers, no server. CMMotionManager (iOS) or SensorManager (Android) reads accelerometer + gyroscope + barometer. The PDR algorithm counts steps (step detection via threshold analysis of acceleration magnitude), determines heading from gyroscope, and detects floor changes with barometer. Drift accumulates at 2–3% of traveled distance. We use this as fallback or in combination with marker correction. PDR tracking is critical for maintaining navigation in areas with poor lighting or featureless walls.

Displaying the AR Route

A common mistake: drawing a 2D arrow on top of the camera feed. That is not AR—it's a primitive HUD. True AR route consists of 3D objects anchored in world coordinates that follow camera movement. Implementation:

// iOS: create an ARAnchor chain along the route
routePoints.forEach { point in
    let anchor = ARAnchor(transform: point.transform)
    sceneView.session.add(anchor: anchor)
}
// RealityKit: attach ModelEntity arrow to each anchor

The arrow smoothly rotates toward the next waypoint using simdLook(at:). When the user passes a waypoint, it is removed from the session and the next group is added. Distance to destination is updated via ARCamera.transform → Euclidean distance to destination anchor.

Floor transitions require separate logic: detect elevator/escalator entry via barometer (CMAltimeter) and floor change in the route graph.

What Our AR Navigation Development Includes

Our standard deliverables:

• Venue audit: obtaining floor plans (DWG, IMDF, GeoJSON) or scanning for VPS.
• Navigation architecture: positioning method selection, route graph design.
• AR module development: integration of ARKit/ARCore, routing and display implementation.
• CMS venue integration: linking tenant data, updates via API.
• On-site testing: accuracy verification on all floors, iterations.
• Support and updates: post-launch maintenance, adjustments after layout changes.
• Full documentation: API reference, user manuals, and integration guides.
• Access to source code and asset files.
• Training for venue staff on system operation and content updates.

Request a preliminary project estimate—we will analyze your venue and propose the optimal solution.

Integration with Venue

Floor plan formats: GeoJSON (open standard, supports indoor), IndoorGML, IMDF (Apple Indoor Maps). For malls, we often work with IMDF—Apple Maps natively supports this format. Tenant data (stores, hours, categories) is pulled from the venue's CMS. We can also develop a custom API for content management.

Work Stages

1. Venue survey (scanning or obtaining plans)
2. Navigation graph construction
3. Positioning technology selection
4. AR module development
5. CMS venue integration
6. On-site testing
7. Accuracy iterations
8. Deployment and training

Timelines: pilot on one floor with marker navigation—6–10 weeks. Multi-floor system with VPS and venue CMS integration—4–8 months. Cost is calculated individually based on venue size and chosen method. Contact us for a consultation—we will prepare a commercial proposal within one business day.

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.