How to Add Barcode and QR Scanning to a Mobile App
Contents
A phone can decode a QR code in a moment. The useful part comes next: does that value identify the right record, does this person have access to it, and what happens when the label cannot be read?
This guide uses equipment lookup as the running example. You can use the same decisions for stock, tickets, check-ins, or packages.
Scanning reads a value; the app still needs to find the right record and check access. Choose one label format, pause repeat detections, and keep manual entry beside the camera.
Start with the thing you need to identify
Say you have two identical drills. A retail barcode may identify the model; it will not tell you which drill is on the bench. A QR label you issue for each drill can identify the individual unit.
That choice determines the data you print, the lookup you build, and the error message you show when a scan fails.
| Label | Good fit | What the app should resolve |
|---|---|---|
| EAN-13 / UPC-A | Retail products that already carry a manufacturer code | Product catalog entry; quantity or individual unit needs another identifier |
| Code 128 | Your own linear labels for bins, assets, or orders | Your internal identifier, under the current account |
| QR | Your own labels when an opaque item ID or short token is useful | A single record; do not treat arbitrary QR text as a trusted URL |
For a first version, choose one format and one outcome. Here: “Scan our QR label and open the matching equipment record.” Add retail barcode support only if staff really scan retail packaging.
Define a label contract before building the camera
For labels you control, print an opaque ID in the QR code and a short, human-readable ID below it. Keep customer details, pricing, and secrets off the label. Anyone with a camera can decode it.
Write down four rules with the team that prints the labels:
- Format: QR for the equipment-label example.
- Value: an opaque ID with an agreed length and character set, such as one to 64 letters, digits, underscores, or hyphens.
- Ownership: the signed-in workspace decides which record the ID may resolve to.
- Fallback: staff can type the human-readable ID if the print is damaged.
A decoded string is only a lookup key. It is not proof that the person scanning it may view or change the record.
Build the scan-to-result journey
Give the scanner one clear job: read your own QR label and open the matching equipment record. Keep Enter ID manually beside the camera so a damaged label never blocks the task.
In an Expo app, the Expo Camera documentation covers the camera view, permission request, and barcode callback. The camera reads the value; your app still has to decide what it means.
- Open the camera when the person taps Scan. Request permission then. If they decline, explain how to enable it and keep manual entry available.
- Accept only the label format you print. In this example, accept QR codes whose content matches your equipment ID rule. Ignore retail barcodes and unrelated QR codes.
- Pause after a valid detection. The same label can be read in consecutive camera frames. Show “Finding equipment…” while the lookup runs and allow a new scan only when the person chooses it.
- Resolve the ID under the signed-in workspace. Ask the server for the matching equipment record. The server checks access before returning details.
- Show the result or a useful next step. Open the matching record, show “No item found,” or explain that the lookup needs a connection. Keep Scan again and manual entry within reach.
For actions that change inventory, opening a record is only the first step. Show the exact item and ask the person to confirm before a checkout or stock adjustment. Make the server action safe against retries.
Make each failure recoverable
A person standing at a shelf does not care which layer of the stack failed. They need to know what to do next.
| What happened | What the screen should say or do |
|---|---|
| Camera permission denied | Explain the need for camera access; offer permission retry and manual entry |
| Camera cannot decode the label | Keep the view open, suggest better light or distance, and offer manual entry |
| Code decoded but has the wrong format | Say the label is unsupported; do not send it to the lookup API |
| Valid ID has no match | Show the scanned ID and offer retry or manual lookup |
| Record belongs to another workspace | Deny the lookup on the server; do not reveal record details |
| Network drops during lookup | Say lookup could not finish and let the person retry; do not imply a save succeeded |
Do not automatically open a URL found in a QR code. Your labels have an ID contract. An unrelated QR code on a nearby box does not get to change the app's destination.
Decide what “offline” means
Camera decoding can work without a connection. Looking up a record on your server cannot, unless the app has a local copy it is permitted to use.
For a simple first version, say “Connection needed to look up this item” and retain the ID for retry. If the job must work in a warehouse with unreliable service, decide what authorized data can be cached and how long it remains valid.
A queued checkout is pending, not completed. Two people can scan the same item while offline; the server needs a conflict rule when those actions sync. The offline mobile app guide goes deeper on that workflow.
Test the labels your team will actually use
Print labels at their intended size. Put them on real surfaces. A pristine QR code on a monitor tells you little about a glossy case in a dim storeroom.
| Test | Pass condition |
|---|---|
| Small, creased, rotated, or reflective label | Scans reliably enough for the job, or manual ID remains usable |
| Another code appears in the camera | Unsupported content does not open a record or URL |
| Same label stays in frame | One lookup and one action, even across multiple detections |
| Unknown ID or another workspace's ID | No unauthorized record details appear |
| Permission denied, then changed in settings | Screen offers a fallback and recovers when access is granted |
| Slow or lost connection | Clear progress, honest error, and a retry path |
Run those checks on physical iPhone and Android devices if you support both. Test the whole action, not only whether the camera recognizes a pattern.
Build this flow with Huxly
Use Huxly to build the scanner screen and equipment lookup around your label rules. Describe the supported format, the signed-in workspace, and the result or recovery action after each scan.
Keep manual ID entry available and require confirmation for a checkout. Start building with Huxly, then test your printed labels, repeat detections, and access rules on real devices.
FAQ
Can a retail barcode identify a specific physical item?
Usually it identifies a product type. Give individual units their own IDs if you need to distinguish, for example, two copies of the same tool.
Should I use QR or a linear barcode?
Use the code your staff already handles. For self-issued item IDs, QR is convenient. For retail product lookup, support the actual printed UPC or EAN format and map it to your catalog.
Does scanning need an internet connection?
Decoding can happen on the device. Looking up a server record, checking permissions, or saving a change needs a connection unless you have built a deliberate offline flow.
What if the camera scans the same label twice?
Lock the scan handler as soon as it accepts a value and pause its callback while you process. Make any server-side change safe against retries too.
Can users type a code instead?
Yes. Print a short human-readable ID near your own code and offer manual entry on the scan screen. This is essential for damaged or reflective labels.
What belongs in the QR code?
For this workflow, an opaque ID. Resolve its details on the server under the signed-in user's permissions. Avoid printing private record information in a label anyone can photograph.
