VPS Implementation for Precise AR on iOS and Android

Why an AR app loses location anchoring without VPS for AR

Camera tracking keeps the scene stable as long as the frame has enough reference points—contrasting corners, texture, and brightness gradients.

Outdoors with a weak signal, in rooms with solid-colored walls and repeating patterns (tiles, shelving, rows of seats), there are too few of them, and visual-inertial odometry begins to accumulate error.

The virtual layer first shifts by centimeters, then by tens of centimeters, and a scenario where a marker stood on a specific object falls apart for the user.

A separate cause is changing lighting. Direct sunlight from a window, a light turned on, or auto exposure correction changes the image so much that the system stops recognizing the built scene and recomputes it from scratch.

At that moment, the virtual layer jumps relative to the object, and indoor AR sometimes drifts along with the user after a couple of steps.

VPS for AR changes the principle: the frame is matched not against the previous frame but against a pre-built map of the location. The app receives absolute coordinates and orientation in this system, so content returns to the point regardless of session duration and lighting. AR positioning accuracy becomes a property of the map, not a stroke of luck with the current frame.

Content anchoring to the location persists after app restart, leaving the zone, and returning—there is no need to point the phone at the marker again. Below, we break down how this works on the map and client sides.

What precise positioning delivers: measurable effect

Previously, the scenario started from a marker or sensor readings: within two or three minutes, the content “drifted” by tens of centimeters, and to even see the object, a visitor had to stand at a marked point.

Visual anchoring based on a pre-captured point cloud (Visual Positioning Service) changes the mechanics: the phone identifies the location from a camera frame, not from a marker.

Content anchoring time drops from 8–12 seconds to 1–3—the scenario starts almost immediately after the phone is raised.

The share of successful launches with the marker-based scheme stayed around 70–80%: weak lighting, reflections from display cases, magnetic interference, and accumulated drift caused failures.

After switching to visual positioning, about 95% of sessions launch reliably, and the failure class “content anchored in the wrong place and drifted away” stops being widespread—it is covered by relocalization rather than an app restart.

Residual failures remain where there is not a single distinguishable detail: a blank solid-colored wall, a fully occluded frame.

AR session stability is more important than a one-time launch.

The phone was put in a pocket, the visitor passed through a turnstile, or briefly covered the camera with a hand—the session is not interrupted: the system finds a previously visited zone in the cloud and returns content to its place in 1–2 seconds. Previously, such a pause meant losing progress and starting from the very beginning.

The effect of visual positioning is measurable and included in acceptance: share of successful sessions, 95th percentile of anchoring time, share of launches without manual adjustment, and depth of divergence when returning to an already visited zone.

We build regression testing on these same metrics—updating the indoor map should not shift any of the numbers.

Positioning methods in AR: comparison of approaches

The positioning method determines exactly where in space the digital layer will appear and how stably it will stay there.

A wrong choice shows up not in a demo but at the site: the scenario works while conditions are ideal and falls apart when lighting, layout, or the user's route changes.

Below are four approaches that teams realistically choose between when implementing VPS for AR, and the limitations of each.

In practice, the choice rarely comes down to a single table row: we calculate the area, surface composition, route length, and accuracy requirements for each section.

Often the optimal solution is a combination—visual maps indoors and hybrid anchoring outdoors, with explicit rules for coordinate conversion at zone boundaries. This calculation is done before development starts and directly affects the app architecture.

Implementing VPS for AR: work stages from audit to handover

Implementing VPS for AR is not about connecting a library but about tuning positioning for a specific site. The app determines position by matching a camera frame with a reference point map, so the work order is strict: site survey first, then the map, then code.

1. Site survey. We walk through the zones where the app will operate and record lighting, solid-colored, and glass surfaces—these are where localization is lost most often. The result is a reference point placement plan.
2. Anchoring scheme. We choose the site coordinate system and anchor: what the content is placed relative to. Without this stage, positioning settings produce “drifting” anchoring on every launch.
3. Building the reference point map. We capture reference frames from different angles and under different lighting, rejecting blurry and visually identical ones. The map is versioned, so updating the site does not break the working scenario.
4. App integration. We connect the map, set VPS priority and fallback rules to inertial tracking, and restrict zones where content must not be shown.
5. Route testing. We walk user routes, measuring capture time, drift, and the share of frames without localization. Fixes go into the map, not the app code.
6. Handover. We deliver the anchoring scheme, map update policy, and rebuild procedure for rearrangements—the team changes the site without us.

What you keep: maps, configurations, and policies

An AR project ends not with a scenario demo but with handover: everything needed to work independently with anchoring and updates stays in your version control system and internal knowledge base. Below is the set of artifacts we hand over at the end of the stage and then keep up to date.

• Indoor maps—point clouds and the anchoring maps built from them, organized by zone, with a data sheet for each capture: capture point, lighting, date, and owner.
• App configuration—setting profiles for each device model and scenario: tracking confidence thresholds, camera mode, and behavior when anchoring is lost.
• Camera data access policies—what exactly is recorded and transmitted, where it is stored, how long it lives, and who has the right to export it.
• Map update policy—which event triggers zone rebuilding (layout change, display change, seasonal display), who initiates it, and how the version is validated before publication.
• AR project documentation—scene structure, exchange contracts with the backend, build instructions, and deployment diagram.
• Role separation scheme—which employees can publish a map, change configuration, and export telemetry.
• Change log and rollback procedure—how to return to the previous map or profile if anchoring failures increase after publication.

We hand this over as regular text configurations and diagrams, not as an export from a closed editor: your engineers can edit them directly.

Case study: anchoring accuracy in an exhibition hall before and after

The Expo Park exhibition space has three themed zones, a continuous route, and an augmented reality scenario that visitors launch themselves, without a guide. The app was supposed to place digital objects at specific points in the hall: a stand, a model, an interactive panel. On paper, the route worked; in practice, guests got lost as early as the second zone.

What measurements showed before the work

Anchoring relied only on the device's own sensor readings, while the hall had high ceilings, glass display cases, and minimal distinctive detail. Error accumulated along the route: an object drifted 1.5–2 meters from its point, and noticeably farther near display cases.

Out of ten scenario launches, three or four ended with the visitor not finding the object and closing the app. An employee with a tablet was almost always nearby, restarting the scene manually—essentially a human workaround instead of technology.

What changed after implementation

We anchored sessions to the hall's visual map: the app recognizes stable supports in the space and determines position relative to them, not relative to the starting point.

The map was collected by walking the route, separately for each zone, and loaded onto the device in advance—recognition works without a constant network connection. First-launch anchoring occurs in 92% of sessions, and object deviation from the target point is 15–20 cm.

The share of repeat scenario launches fell from one in three to one in twelve, manual staff adjustments dropped to zero, and stand support is no longer required.

We separately included map updates: when stands are rearranged, it is enough to walk the route again; the app code does not change. This is what makes maintenance predictable—the space lives its own life, while the app remains accurate.

How does visual positioning differ from GPS tags?

Satellite navigation calculates position by the arrival time of signals from satellites.

It works as long as there is a direct line of sight to the sky: in a shopping mall, warehouse, or underground parking, the signal reflects off walls and ceilings, and the coordinate drifts by tens of meters.

The tag jumps between floors and neighboring buildings—such anchoring cannot support either navigation through halls or a prompt above a specific stand.

Visual positioning—the Visual Positioning Service—calculates position differently: the camera frame is matched against a pre-built map of the space, and the coordinate is taken relative to it.

Accuracy is tens of centimeters; anchoring does not depend on the sky and works in basements and underground levels where satellites are not visible at all.

Satellite navigation is sufficient when the task operates at street scale: a route to a point, courier arrival, city navigation with error in tens of meters. Inside a building, a different granularity is needed—aisle, shelf, specific exhibit, unit of equipment.

That is why anchoring methods are combined: satellite navigation brings the user to the entrance, then the app switches to the visual map and does not lose position when moving between floors.

The choice is determined by required accuracy, area and complexity of the site, and how often the environment changes—this determines the amount of work for capturing the space.

Technical concerns: accuracy, stability, privacy

Almost every VPS for AR project starts with the same questions: will recognition hold up in low light, what happens in a hall without a network, where do camera frames go, and will the site need to be re-captured when the device fleet changes. Below are short answers for each point.

Does the app work without a network connection?

The map and scene model are stored on the device itself, and localization runs locally. Only aggregated events go to the network when connectivity appears—a session without a connection is not lost but sent later.

What happens to camera images?

Frames are processed on the device and are not stored: coordinates and a recognition confidence score are sent to the server. This resolves visitor privacy concerns and simplifies project approval with legal teams.

How is the device fleet covered?

For different cameras and performance levels, we create separate calibration profiles, and on weaker models we keep a fallback scenario using a visual marker. The list of supported devices is fixed before development starts.

Will the site need to be re-captured?

No: the map is updated by a repeat walkthrough with the same app. If the layout has changed, we re-capture only the affected zone, not the entire site.

Let's discuss your task: what to prepare for an estimate

To come back with an AR project estimate rather than follow-up emails, we need a minimum of facts about the site and scenarios.

A finished technical specification is not required—what the site team already has is enough: diagrams, photos, walkthrough recordings, and work from previous contractors.

• Site plan: floor plans, zone boundaries, heights, route length—these are used to calculate reference point density and capture scope.
• Materials and lighting in each zone: glass, gloss, open display cases, daylight, and accent lighting—this determines what positioning latches onto and where markers are needed.
• Visitor scenarios: where they take out the phone, what they should see, where to go, which points are mandatory and which are enough to indicate.
• Device fleet: iOS and Android shares, main models, OS versions, camera and sensor limitations.
• Source data: whether there are photo and video walkthroughs, drawings, annotated diagrams, previously built prototypes—they can be reused.
• Constraints: site operating hours, privacy when filming people, frame storage rules, network availability at the site.

Describe the task in whatever way is convenient: by email, by voice, or with a link to a folder of materials.

We will review the source data for the site, ask clarifying questions in one batch, and come back with an estimate, work scheme, and positioning implementation plan—with stages, checkpoints, and a clear result at each.