Expo Camera Web Gotchas: A Cross-Platform Scanner Field Guide (Simply Explained)

The Demo Looked Perfect. Then a Real Person Tried It.

I built a feature for a phone app that lets you point your camera at a nutrition label and have AI read the numbers off it. No typing. Just point and go.

On my own phone, it worked beautifully. I showed it off. Felt good about myself. Moved on.

Then it had to run on regular web browsers, on phones that weren't mine, in the hands of strangers. That's when everything quietly fell apart.

Here's the hard truth I keep relearning: camera and AI features demo perfectly, then break on real devices. The tools you build with promise they'll "work everywhere." They mostly mean they'll work on your machine.

What follows is four real problems that cost me hours each. None were in the manual. All of them shared one nasty trait: they failed silently. No error message. No crash. Just nothing.

The Scanner That Did Absolutely Nothing

The first problem was the barcode scanner. On a normal phone app, it worked every time. Point at a barcode, get the number, done.

So I assumed it would work in a web browser too. That's the whole promise of "build it once, run it everywhere."

In the browser, nothing happened. No barcode read. No error telling me why. Just silence.

That is the worst kind of failure. A crash at least tells you something broke. Silence makes you stand there pointing your phone at a barcode, wondering if the lighting is bad or your hand is shaking.

The cause was simple once I found it. The tool I used had no real version of barcode scanning for web browsers. It didn't complain. It just skipped the whole thing.

I fixed it by bolting on a separate scanner that works in browsers. But I also added something boring and important: a box where people can just type the barcode number by hand.

Why? Because browser camera permissions are a mess. Different browsers ask differently, and plenty of people accidentally block their camera without realizing it. The manual option is the difference between a feature that works for everyone and one that works for the lucky few.

The lesson: "works on a phone app" and "works" are two completely different claims. The tools encourage you to confuse them.

The Photo That Looked Fine and Wasn't

Once the camera was capturing pictures, I had to send those photos to an AI that reads images.

On a phone app, the photo arrives in exactly the format the AI expects. Drop it in, done.

In a browser, the photo comes wrapped in a little label at the front. Same picture underneath, but with extra text glued to the beginning that the AI chokes on.

Imagine mailing a letter, but the envelope and the letter are stuffed into one bigger envelope, and the post office tries to read the whole thing as the address. That extra wrapper has to come off first.

The fix was tiny: strip off that front label before sending the image. One small change.

Here's what makes this one sneaky. The code looked correct. Both versions handed back something that looked like a photo. Nothing about it screamed "broken." A second pair of eyes would approve it without blinking.

The only way to catch it was to actually run it on a real browser and watch the AI return nothing. You cannot spot this one by reading. You have to use it.

The AI That Thought Itself Into Silence

I was using a newer, smarter kind of AI that "thinks" before it answers. Like a person working through a problem out loud before giving you the final number.

I gave it a generous limit on how much it could write back. A nutrition label has maybe a dozen numbers on it. The limit I set was way more than enough room to list them all.

The AI returned a completely blank answer. No error. Just empty.

I checked everything. The photo was getting through. The request looked right. Every single piece looked healthy.

Here's what was actually happening. That thinking step? It eats into the same budget as the answer. The AI spent its entire allowance "thinking" about the image and ran out of room before it could write a single word back to me.

Picture giving someone a one-minute time limit to both think through a hard problem and say the answer. They spend the whole minute thinking and the buzzer goes off before they open their mouth.

The fix was to give it a much bigger budget so there was room for both the thinking and the answer. Responses came back instantly after that.

The bigger lesson: these AI tools change behavior between versions. Settings that worked perfectly a year ago quietly break today, and nobody sends you a warning.

The Database That Was Missing Half My Products

After reading a barcode, you look the product up in a big public food database to get the nutrition facts.

Half my products weren't showing up. I started building elaborate backup plans for all these "missing" items.

Turns out the database has two front doors. One is the real, complete version. The other is a practice version that is intentionally missing most products.

I'd copied my setup from a tutorial that pointed at the practice version.

I wasn't missing data. I was knocking on the wrong door. Switched to the real one and every "missing" product was right there.

The fix took thirty seconds. Finding it took an hour of blaming the wrong thing.

Why This Matters For Your Business

Each of these problems is just a few annoying hours on its own. Stack them all into one feature, though, and you get something far worse: a feature that quietly fails for half your customers while your reports say everything is fine.

Picture it. Your dashboard shows people using your scanner. What it doesn't show is that web users never get a result, the ones who do send broken photos, the AI returns blanks, and the lookups hit an empty database. Every layer fails silently. Your numbers look healthy while real people give up and leave.

I find these problems because I build the thing on real phones and actually use it. There's no substitute for pointing a stranger's phone at a label and watching it fail in front of you.

This gap, between a demo that dazzles and a feature that survives real customers, is exactly where most AI projects die. The AI part usually works. It's the real-world details that kill it.

If you've got an AI or camera feature that demos great and you're nervous about how it holds up with actual customers, that nervousness is correct. Bringing in someone who has already hit these walls costs a lot less than discovering them after launch with customers watching.

Want to explore what AI could do for your business?

Book a free 30-minute strategy call. No pitch deck, no sales team, just a real conversation about your operations and where AI fits.

Book a Discovery Call