How GPS-based AR actually works, and why it drifts

The problem with GPS alone

Phone GPS is excellent for navigation and not good enough for AR. Positioning can be off by several metres, and considerably more between tall buildings where signals bounce. Direction is worse: the compass is easily disturbed by metal, magnets and electronics, and a few degrees of heading error becomes a large position error for anything more than a short distance away.

For a map that is fine. For AR it means content that sits in the wrong place, faces the wrong way, and slides around as the estimate updates.

Newer phones help. Apple lists precision dual-frequency GPS in both the iPhone 18 Pro and iPhone Duo, which improves accuracy, particularly in cities. It narrows the problem. It does not remove it.

The fix: visual positioning

The systems that work well do not rely on GPS alone. They use the camera to recognise where the phone is. This is called a visual positioning system, or VPS.

The idea: compare what the camera sees against a previously built model of the real world, find the match, and work out the phone's precise position and direction from it. GPS gets you to roughly the right place; the camera pins it down.

Google: ARCore Geospatial API

Google's Geospatial API combines device sensors and GPS with a localisation model built from Street View imagery. Google says developers can anchor content by latitude, longitude and altitude in more than 87 countries, without visiting the location or scanning it first. Coverage is best outdoors in places Street View has captured, and you can check whether VPS is available at the user's current location before relying on it.

Apple: ARKit location anchors

Apple's approach uses ARGeoTrackingConfiguration and location anchors, placing content at a coordinate and refining position using Apple's own mapping data. The important practical point is that it is only available in supported areas, which Apple has expanded over time. Your app should call Apple's availability check for the user's location and have a fallback when geotracking is not supported there.

How to design location AR that does not disappoint

• Design for tolerance. Place content where being a few metres off still looks right: an open square rather than a precise doorway.
• Check availability first and switch to a fallback — a simpler map-based or tap-to-place experience — where visual positioning is not supported.
• Ask users to look around. Visual positioning needs to see buildings and features, not the pavement.
• Prefer outdoor, well-mapped locations for anything that needs precision.
• Always test on site. A route that works perfectly in a simulator can fail on the actual street.

We use exactly these principles in the GPS learning trails we build for schools: generous placement, clear on-site prompts, and a graceful fallback when positioning is not good enough.

Common questions

Why does location-based AR drift?

Phone GPS can be off by several metres, more in dense cities, and compass heading is easily disturbed. Small errors become visibly misplaced content. Visual positioning systems correct this using the camera.

What is a visual positioning system in AR?

A system that matches what the phone's camera sees against a model of the real world to determine precise position and orientation, instead of relying on GPS alone.

How does the ARCore Geospatial API work?

It combines sensors and GPS with a localisation model built from Street View imagery. Google says content can be anchored by latitude, longitude and altitude in over 87 countries, and you can check VPS availability at a location.

Do ARKit location anchors work everywhere?

No. They are available only in supported areas. Use Apple's availability check for the user's location and provide a fallback experience where it is not supported.

Keep reading

GPS learning trails for schools →AR on iPhone Duo without LiDAR →What an AR app costs →Discuss AR in APGS Community →