Barcode Scanning and Search: From Recognition to Product Display

Barcode Scanning and Search: From Recognition to Product Display

Imagine: a user opens the camera, points it at a barcode — the app must recognize the code, find the product in the database, and display the result in milliseconds. At first glance, the task is simple, but in practice, the capture → recognition → query → display pipeline can become a bottleneck. Without proper architecture, the time from scanning to displaying the result exceeds 2 seconds, leading to user abandonment. We have implemented this functionality for over 30 projects. Experience shows: if the architecture is not thought out in advance, the project risks getting bogged down in rework. Let's break down how to do it right and without surprises.

Platform capabilities for recognition

iOS: AVFoundation with AVMetadataObjectTypeEAN13Code, UPC-A, QRCode, and a dozen other types. Or VisionKit — VNDetectBarcodesRequest with VNBarcodeObservation, convenient for processing static images from the gallery. DataScannerViewController (as of iOS 16) is the simplest path: one class, built-in UI, support for all types out of the box. Apple documentation: AVFoundation.

Android: ML Kit Barcode Scanning (com.google.mlkit:barcode-scanning) — works offline, supports 1D and 2D codes. Or ZXing — a proven library, but on weak devices ML Kit is 2–3 times faster than ZXing, especially for Data Matrix recognition.

The choice depends on the minimum OS version and offline requirements. On Android, ML Kit requires Google Play Services; on devices without GMS (Huawei), an autonomous bundled model is needed. We select the stack for each specific project — this guarantees stability on any device.

Why search is harder than scanning

Scanning itself is a few lines of code. The complexity lies in the search architecture.

Deduplication of results. The camera recognizes the same barcode dozens of times per second. Without debounce, the request goes to the server 50 times before the user moves the camera away from the shelf. Solution: throttle on the last recognized code with a delay of 800–1000 ms.

Offline search. If the product catalog is available locally, searching via SQLite or Room (Android) / CoreData (iOS) with an indexed barcode field takes 1–5 ms. Without an index on a table of 100,000 products — 300–500 ms even on a flagship device.

Unknown code. The user sees a message if the barcode is not found in the database. Fallback to Open Food Facts API or GS1 lookup, or just a message — this is a product decision, but it must be incorporated into the architecture in advance, otherwise you will have to redo the flow.

Example: search with debounce on iOS

private var lastScannedCode: String? private var searchTimer: Timer? func handleScannedCode(_ code: String) { guard code != lastScannedCode else { return } lastScannedCode = code searchTimer?.invalidate() searchTimer = Timer.scheduledTimer(withTimeInterval: 0.8, repeats: false) { [weak self] _ in self?.performSearch(barcode: code) } } 

How we handle different barcode types

Depending on the scenario, we connect the necessary parsers. Below is a table of common formats we work with.

If the technical specification does not specify specific types, we clarify in advance. Including support for all types without necessity is not worth it: it slows down recognition and complicates the code. It is optimal to limit to the three most requested ones.

How to implement offline search without delays

For offline mode, we use indexed databases: CoreData on iOS and Room on Android. The barcode field is indexed, which gives search speed of 1–5 ms for 100,000 records. Additionally, we cache query results in memory (NSCache / LruCache) so that repeated search for the same code does not access disk. If the product is not found locally, we move to the fallback.

Development process: from analysis to deployment

1. Requirements analysis (1–2 days) — clarify code formats, need for offline database, fallback strategy, target audience.
2. Design (1–2 days) — select libraries, design search architecture (debounce, cache, indexes), define API contracts.
3. Implementation (3–5 days) — write scanning code, integrate with local database and backend, implement fallback.
4. Testing (1–2 days) — test on a library of 200+ test barcodes, including rare formats and damaged codes.
5. Deployment (1 day) — publish to App Store / Google Play with configured App Review and tests.

For iOS, the minimum supported version is iOS 13 (VisionKit is available). If iOS 12 support is required, we use only AVFoundation. For Android — minSdk 21 (ML Kit is available from API 19, but we recommend 21+). ProGuard/R8 rules (to keep barcode classes) are provided in the distribution.

Comparison of recognition libraries

Why trust us with development?

We have been doing mobile development for many years. During this time, we have implemented over 30 barcode scanning and search integrations for retail, warehouses, and logistics. We use proven libraries and frameworks, automate pipeline testing. We deliver each project with documentation on available APIs and maintenance recommendations. Savings on development from scratch can reach 40% when using ready-made components.

What is included in the result

• Configured recognition for selected formats.
• Search architecture with debounce and caching.
• Integration with backend or local database.
• Fallback handling for unknown codes.
• Source code with comments, build and deployment instructions, help with publication in App Store / Google Play.

The development timeline for a basic version is 1–3 days for one search type, up to 5–7 days for a comprehensive solution with an offline catalog. The cost is calculated individually after clarifying the code types and search architecture.

Get a consultation on your project — we will assess the complexity and offer a suitable solution. Contact us to discuss your task.