How to Add Barcode and QR Scanning to a Mobile App

A working scanner does more than put a box around a code. It needs to recognize the right formats, resolve the value to something useful, and recover when the camera cannot read it.

This guide walks through the decisions you need to make before adding barcode or QR scanning to a mobile app. The running example is a stock lookup screen, but the same pattern works for check-ins, equipment tags, tickets, and package tracking.

First, define the job of the scanner

Write a one-sentence outcome: "Scan a product label and open its matching item." That gives you a clear success state and a clear failure state. A camera that reads digits but cannot find an item has completed only the first half of the job.

Decide whether you are reading retail barcodes, your own printed QR labels, or both. Retail codes often identify a product type, not a particular physical unit. A QR code that your team prints can carry a unique item identifier. If you need to distinguish two identical drills, a product barcode alone will not do it.

Map the flow before building the screen: permission request, camera preview, detected value, format check, lookup, result, then scan again. Decide whether users can type a code when the label is damaged.

Choose formats deliberately

A barcode scanner can return a format and a decoded string. Restrict supported formats to the labels your users actually handle. This reduces surprising matches and makes testing manageable. QR codes can encode a URL, plain text, or an internal identifier; your app should know which of these it expects.

For your own labels, use a stable identifier such as an item ID or short opaque token. Avoid putting private customer data directly in the QR image. Anyone with a camera can read it, even if your app protects the linked record.

A useful scan contract is: accepted format, maximum value length, character rules, and a resolver that turns the value into a record. Write it down so the mobile screen and backend agree.

Build the smallest end-to-end flow

Create a Scan button on the item lookup screen. Tapping it opens the camera. After the app decodes a supported code, pause detection, display a loading state, resolve the code, and show the matching item. Provide actions to scan another label or type a code.

If you build with Expo, its Camera documentation describes camera permissions and barcode scanning on CameraView. Start with its supported configuration for your SDK version. The camera API tells you what was detected; your application still owns format validation, lookup, and error handling.

If you use Huxly, describe the complete flow rather than asking only for "a scanner." Include accepted formats, result navigation, and the manual entry fallback in the build request.

Handle permission as a normal state

A user can deny camera access on the first request, revoke it in settings, or use a device without a working camera. Keep the scan button visible and explain why access is needed when the user taps it. If access is denied, provide a way to open settings and a manual code field.

Do not request camera permission on app launch when the user has not chosen to scan. Request it at the point of use. Check the screen after returning from settings: the permission may now be granted, and the camera view should recover without requiring a restart.

Prevent the same label from scanning repeatedly

The camera can recognize the same code across many frames. Without a guard, one label can trigger several requests, open multiple detail screens, or add the same inventory item more than once.

Set a processing state as soon as a scan is accepted. Ignore subsequent detections until resolution finishes or the user taps Scan again. For operations that change data, also make the server request safe against retries by using an operation ID or checking the target state. A local cooldown improves the experience; server-side idempotency protects the data.

Show the decoded value and result briefly when an action has real consequences, such as checking out equipment. Let the person confirm rather than silently changing ownership.

Validate before navigating or saving

Treat scanned text like any other external input. A QR code on a wall could contain a malicious URL, an unexpectedly long string, or an ID from another organization. Check the format and length first. If you expect a record ID, resolve that ID on the server using the signed-in user's permissions.

Do not turn arbitrary QR contents into automatic web navigation. If external URLs are a supported feature, show the destination and require a deliberate tap. A code that points to a valid item in another team's workspace should still return an access error.

Distinguish four messages: unreadable label, readable but unsupported format, supported code with no matching record, and matching record without access. That helps users fix the right problem.

Decide what works offline

Camera decoding can happen on-device, while record lookup usually needs a network connection. If staff scan in warehouses with patchy service, define an offline behavior. One option is to cache a limited list of authorized item IDs and their display names. Another is to queue scan events with timestamps and synchronize later.

For an inventory change, show "pending sync" until the server confirms it. Do not imply that a checkout has been saved if the network request has not reached your system. Plan for the same label to be scanned by two people while disconnected; the server will need a conflict rule.

For a deeper workflow example, see how to add offline mode to a mobile app.

Give people an escape hatch

Some labels are scratched, folded, or obscured by glare. Include manual entry or search alongside scanning. If many users fall back to typing, inspect the label design, printer quality, and supported formats before changing the camera code.

For your own QR labels, print a short human-readable ID under the code. A person can enter it when the camera fails, and support can identify the same record from a photo.

Test on actual labels and devices

A simulator cannot reproduce a reflective box, a cracked screen protector, or a dim storeroom. Build a test set with small labels, large labels, low light, glare, rotated codes, and a partially damaged code. Test both accepted and unsupported formats.

Run the same flow on at least one iPhone and one Android phone if both are targets. Check permission denial and recovery, fast repeated scans, a slow lookup, no network, and an authenticated user without permission to see the item. Count how often someone has to retry a normal label.

Measure the whole workflow

Track scan attempts, successful decodes, successful resolutions, no-match results, permission denials, and manual entries. Keep raw scanned values out of analytics if they could contain private information. Aggregate counts and error categories are often enough to identify friction.

A high decode rate with a low resolution rate points to label or data matching problems. A low decode rate points to camera conditions, code size, or the set of enabled formats. Those are different fixes.

Build the scanner with Huxly

Start with a precise request: "Add a Scan item screen. Accept our QR item IDs and the retail barcode format used on our packaging. After scanning, pause the camera, look up the item within the signed-in workspace, show the item detail, and offer Scan again. Provide manual entry, permission recovery, and a no-match state."

Build the lookup and access checks before polishing the camera overlay. Then test with printed labels and refine the states that failed. For a broader stock workflow, plan how scanned items connect to quantities, locations, and adjustment history before adding more code formats.

FAQ

Conclusion

A good scanner saves typing because the whole path from label to correct record works. Start with one label type and one useful result, then harden permissions, validation, retries, and offline behavior where your users need them.