Exciting News: Release of barKoder SDK 1.7.1!

We’re excited to announce the release of barKoder SDK 1.7.1, along with updated versions of the Barcode Scanner by barKoder App now available on the Google Play Store and Apple App Store.

This release delivers meaningful improvements in performance, efficiency, and regional data parsing continuing our mission to provide developer-first, enterprise-grade barcode scanning across mobile and web platforms.

What's New in barKoder SDK 1.7.1

• New AR Mode: matchFilter
• Added roiCenterMark option
• Mac Catalyst support
• Added Bar Coded Boarding Pass (BCBP) parser
• GS1 Parser overhaul
• QR decoder improvements
• PDF417 bugfixes
• Code 93 zero termination fix
• Improved overall performance and stability
• Code 128 start codes added to result

What's New in Barcode Scanner by barKoder App:

Android barKoder App:

• Implemented barKoder SDK 1.7.1
• Search & Find showcase
• Added Bar Coded Boarding Pass (BCBP) parser
• GS1 Parser overhaul
• QR decoder improvements
• PDF417 bugfixes
• Code 93 zero termination fix
• General stability improvements
• Code 128 start codes added to result

iOS barKoder App:

• Implemented barKoder SDK 1.7.1
• Search & Find showcase
• Mac Catalyst support
• Added Bar Coded Boarding Pass (BCBP) parser
• GS1 Parser overhaul
• QR decoder improvements
• PDF417 bugfixes
• Code 93 zero termination fix
• General stability improvements
• Code 128 start codes added to result

What's New in barKoder for WASM v1.7.0

Improvements

• Improved camera frame capture by replacingsetIntervalwithrequestVideoFrameCallback.
• Ensures only new camera frames are sent for scanning.
• Prevents the same frame from being processed multiple times.
• Reflects the camera’s actual hardware frame rate.
• Automatically sends fewer frames when the camera lowers its FPS in conditions such as poor lighting.
• ThedpsLimitsetting is still supported and continues to limit decoding operations per second.
• Added multithreading support using Web Workers.
• Uses two threads by default.
• Web Workers are created dynamically as blobs during theinitializemethod call.
• The number of threads can be controlled through themaxThreadssetting.

New Configuration Settings

• AddeduseMainThreadOnly.
• Enables the legacy single-threaded scanning mode.
• Can reduce CPU, battery, and memory usage.
• Recommended when multithreaded performance is not required.
• AddedmaxThreads.
• Configures the desired maximum number of scanning threads.
• Supported range:1to4.
• If the requested value is not supported by the device, the closest available value will be used.
• AddedwasmPath.
• Allows a custom path or filename to be provided for the.wasmbinary.
• AddedobtainVersionedBinary.
• Appends the SDK version to the.wasmURL to prevent browser caching issues during update.
• Example:barkoder.wasmbecomesbarkoder.wasm?v=1.7.0.
• WhenwasmPathis provided, versioning is applied only if the path ends with.wasm.
• Paths that already contain query parameters, such asbarkoder.wasm?v=123, remain unchanged.

API Changes

• Updated theinitializemethod.
• Theoptionsobject can contain:wasmPath obtainVersionedBinary
• These settings are applied only once during initialization.
• The.wasmbinary and other required resources are now fetched only afterinitializeis called.

New Features

• Added BCBP parser support.

Bug Fixes

• Fixed an issue where barcode locations were not drawn on the camera preview after switching from AR mode back to regular, non-AR mode.

Native Library

• Updated the native library to version1.7.4.0.

Improved Camera Frame Handling

The scanner now uses requestVideoFrameCallback instead of setInterval with a frame interval calculated from dpsLimit.

This ensures that only new frames coming from the camera are submitted for scanning, avoiding unnecessary processing of the same frame multiple times.

Another benefit is that scanning now better reflects the camera's actual hardware frame rate. For example, a camera may be configured for 30 FPS, but under challenging conditions such as poor lighting, a lower-quality camera may actually produce fewer frames. With the new approach, the scanner automatically follows that real frame rate rather than repeatedly processing the same frame.

The dpsLimit setting is still supported and continues to limit the maximum scanning rate.

Multi-Threading Support

The new version also introduces multi-threading for demanding operations such as scanning camera frames and images.

Multi-threading does not necessarily mean that scanning performance will simply double. Instead, the workload is distributed across multiple threads, so the improvement depends on the device's CPU architecture and performance.

High-end devices that already achieve around 30 DPS using a single thread may see little improvement in raw scanning throughput. However, they can still benefit from better overall responsiveness, because the main thread is freed to handle UI operations.

Devices with weaker single-thread performance can see a much larger improvement, especially when they have multiple CPU cores with similar performance. In some cases, performance can scale almost linearly with additional threads.

Because many mobile CPUs combine one or two high-performance cores with slower efficiency cores, using more than two threads often provides limited additional benefit. For most devices, two threads are expected to be the optimal balance.

Configuration

Multi-threading is enabled by default with 2 threads and can be configured using maxThreads.

The supported range is 1–4 threads, although the actual number used may be adjusted automatically depending on the device's hardware and software capabilities.

No server-side configuration or browser flags are required.

The threads are implemented using Web Workers, which are dynamically created during the initialize process.

The initialize method now accepts an optional options object containing:

• useMainThreadOnly
• maxThreads
• wasmPath
• obtainVersionedBinary

These options should be configured during initialization.

Legacy Single-Threaded Mode

useMainThreadOnly can be enabled when an application needs to continue using the previous single-threaded approach.

Multi-threading generally provides better responsiveness and performance, but it also increases CPU, memory, and battery usage, particularly during prolonged scanning sessions.

Therefore, applications where the existing single-threaded performance is already sufficient may choose this option to reduce resource consumption.

WebAssembly Binary Handling

wasmPath allows developers to specify a custom location or filename for the WebAssembly binary.

obtainVersionedBinary can be used to ensure that the latest .wasm binary is fetched instead of an older browser-cached version.

For example:

barkoder.wasm → barkoder.wasm?v=1.7.0

This is especially useful when deploying a new SDK version and wanting to prevent browser caching from serving an older binary.

If a custom wasmPath is provided, versioning is still applied when the path ends in .wasm. Paths that already contain query parameters, such as barkoder.wasm?v=123, remain unchanged.