Phone AR that is ready for client work in 2026

The safest mobile AR brief is smaller than the demo reel.

I wrote this because Jozi teams often meet the same problem: a client sees one polished AR clip and assumes every phone can reproduce it. A tighter feature promise protects the budget, schedule and launch day.

What's the problem?

“Ordinary phone” is a slippery phrase. It should mean a supported iPhone or ARCore Android handset, without assuming LiDAR, a depth sensor or perfect connectivity.

The reliable core is already useful. Current ARKit and ARCore workflows support phone movement tracking, surface detection, tap-based placement, anchors, prepared image targets and lighting estimates. Unity’s AR Foundation exposes these features across both platforms, although device support still varies. (developers.google.com)

The mistake is quoting every available feature as equally dependable.

Depth-based occlusion can place a real object in front of a digital one. It looks convincing, but it needs a device check and a fallback. Google’s guidance requires developers to test for Depth support when an AR session starts. (developers.google.com)

Tracking also dislikes dim rooms, glare, glass and plain surfaces. A white office wall may give the camera too few visual details to follow. (developers.google.com)

That sounds obvious until the launch is inside a dark Sandton venue. (Phones remain stubbornly physical.)

What's the solution?

Use a three-level capability ladder before you price the work.

Level one is the promise. Keep it to surface scanning, tap-to-place, move, rotate, reset and one clear image target. Choose a flat, high-contrast image without glossy reflections. Add basic light estimation so the object fits the room better. (developer.apple.com)

These features suit product previews, exhibition pieces, learning prompts and simple spatial instructions.

Level two is an enhancement. Put depth occlusion, location-based placement and shared experiences here. Build them only when the test-device list, venue and network are known. If they fail, the level-one experience must still work.

Level three needs discovery. This includes recognising arbitrary products, holding content at an exact outdoor point for weeks, or aligning several phones perfectly. Do not hide this work inside a normal AR quote.

Imagine a Braamfontein poster campaign. The dependable version recognises the printed poster and attaches animation to it. A second scene lets visitors place a related 3D object on the floor. The risky version promises that content will remain precisely attached to a nearby building from every pavement angle.

Start with the poster and floor. Ship the version people can actually open.

What's next?

1. Write your client promise in one sentence, using only level-one features.
2. Test it on one mid-range Android phone and one older supported iPhone, inside the real venue if possible.
3. Record three failure checks: low light, blank surfaces and lost tracking. Give each one a visible recovery instruction.

Share what you test in Jozi, or send us the feature your client keeps requesting.

The WE ARE VR team