Augmented reality on your customer's phone, not yours: what to do when your audience has a basic device

Augmented reality works beautifully on the phone of the person who develops it. The problem is that the end customer almost never has that phone.

This is one of the most costly lessons for anyone delivering AR to a broad audience: the experience gets approved on a recent device, in a room with good light, and reaches someone with an entry-level phone, bought four years ago, in a kitchen at night. The technology is the same. The result is not.

This post covers what we learned providing this kind of support — and what can be done at the project stage so the problem simply doesn't exist.

Why it doesn't open: there are four different reasons

"I can't see it" usually hides distinct causes, and each one has its own solution.

1. The device isn't compatible — and that doesn't depend on it being new

On Android, native AR depends on ARCore, and Google only enables certified devices: the model goes through checks of camera, motion sensors, architecture, and processor performance. It's not enough to run Android 7.0 or higher and have the Play Store — if the manufacturer didn't do the calibration with Google, that model doesn't make the list, even if it's recent. That's why two similar phones, from the same year, behave differently.

On iPhone, the bar is simpler: ARKit requires an A9 processor or higher — that is, from the iPhone 6s onward — with iOS 11 or newer. Advanced features, like the LiDAR sensor, exist only in the Pro models.

2. The system component is missing

Even on a compatible device, Android needs Google Play Services for AR installed and updated. On phones with little free space — a common situation on entry-level devices — this component often doesn't get installed or silently falls out of date.

3. The link was opened inside another app

This is the top cause of support tickets, and it has nothing to do with the quality of the phone. When someone taps the link inside WhatsApp, Instagram, or Facebook, the page opens in those apps' internal browser — and that browser doesn't trigger native AR. The experience needs to be opened in Chrome, on Android, or Safari, on iPhone.

4. The physical environment isn't cooperating

AR that "places the object on the floor" needs to recognize a surface, and for that it depends on visual texture and light. A smooth, glossy floor, a plain white wall, a glass table, or low light leave tracking without reference points — hence the message that the floor wasn't identified. It's not a defect in the app: it's the limit of detecting a plane through the camera.

The project mistake that causes all of this

The mistake isn't technical, it's a decision: choosing the type of AR by looking at the team's phone, not the audience's. When the product goes out to a broad audience — a book, a package, material distributed at a school —, a good portion of readers will have entry-level devices, full memory, and unstable connections. Designing for the top of the list is a guarantee of support tickets.

The technical way out: change the type of AR, not the audience

There are two quite different ways to do AR, and they have very different requirements:

• Surface AR (plane detection). The device needs to map the environment in real time. It's the most impressive and the most demanding — sensor, processing, and a favorable environment.
• Target-image AR. The content appears when the camera recognizes a specific image: the book cover, the page, the label, a printed card. Since the reference point is the image itself, there's no need to detect the floor or map the room — which makes it noticeably more tolerant of basic devices and poor environments.

For printed material, the target image is usually the right choice not because it's cheaper, but because it's more robust: the page is already the marker, framing is natural, and the user understands on their own what to do — point the camera at the picture.

And when it is already image-target and still does not open?

Switching to image targets removes the most fragile part — mapping the room — but it does not make the experience bulletproof. Recognition still depends on the camera seeing the artwork sharply enough, and that is where the basic handset shows up again. What usually gets in the way, by frequency:

• Focus. Many entry-level cameras have weak or fixed focus. A slightly blurred image does not match the target — and the person swears they are pointing correctly, because to their eye they are.
• Glare from the paper. A glossy or laminated page bounces light straight back into the lens and washes out the artwork. It is the most common reason something works in the shop and fails at the customer's home: the lamp changed.
• Low light. In the dark the camera raises gain, the image picks up noise and the pattern is lost.
• Distance and angle. Too close crops the target, too far leaves too few pixels, too tilted distorts the pattern. The working range is narrower on a poor camera.
• Page curvature — in a book, this is the structural problem. Image-target recognition assumes the artwork sits on a flat surface. Near the spine the page curves, and that curve warps the pattern continuously: the distances between reference points shift and the match against the original target fails. The thicker the book and the stiffer the spine, the worse it gets — a perfect-bound book barely opens to 180 degrees, and the curve swallows precisely the inner half of the page.
• The target itself lacks detail. Flat colours, large empty areas, repeated patterns or symmetry give few reference points. Two similar pages can even be mistaken for each other.
• Performance. A slow device processes fewer frames per second: recognition drags and the person gives up first.

What to do in the project: place the target in the outer third of the page, away from the spine, and never let it span both pages — the central fold splits the pattern across two different planes; where there is a choice, prefer binding that opens flat (sewn or spiral); pick the most textured, highest-contrast illustrations as targets (and test each one before printing, with the book open in your hand, not as a loose sheet on a table); avoid glossy finishes on pages meant to be scanned; print the distance and lighting instruction on the page itself; and — the detail that cuts support requests the most — show on screen what the app is seeing, with a frame indicating the right framing, instead of leaving the camera open with no clue at all.

And the plan B that almost no one delivers

There will always be someone whose device doesn't support AR at all. For that person, the project needs a second door:

1. A rotatable 3D model without a camera. The same piece, on screen, that the person drags with their finger. It runs on almost everything and delivers 80% of the value.
2. A short video of the experience. Recorded once, it shows what they would have seen.
3. A message that teaches, not blames. "Your device isn't compatible" closes the door. "Tap here to see in 3D" keeps the person engaged.

Checklist before launching to a broad audience

• Test on the most basic device your audience actually uses — buying a used entry-level one is cheaper than losing a customer.
• Test in low light and on a smooth surface, not just on the office's wooden table.
• Test opening the link from inside WhatsApp, because that's how it will circulate.
• Include instructions in the printed material: which browser to open and what to point at.
• Have the second door ready before launch, not after the first complaint email.

What to reply to someone who writes saying it doesn't work

A short script solves most cases, in this order: ask for the device model; ask whether the link was opened inside some app and ask them to open it in Chrome or Safari; suggest testing with more light and pointing at a textured surface; and, if none of that works, send the video or the 3D model. The person doesn't want to understand ARCore. They want to see the picture move.

If you're planning a project like this, it's worth reading first how much it costs to build an augmented reality app — including to find out when you don't need one at all. And if you want that decision made with the real audience in mind, that's what we do in augmented reality and in app development.