Cognex cmbSDK is dead: Migration guide for enterprise apps in 2026

On September 30, 2025, the Cognex Mobile Barcode SDK (cmbSDK) reached end of life. It no longer receives updates or security patches, and the developer network is winding down. For companies with apps built on it, this means finding a replacement solution before continued reliance on an unmaintained SDK begins to affect app performance, compatibility, or the ability to ship updates.

This guide gives you an overview of the cmbSDK’s capabilities that need replacement. This includes the built-in camera preview, modes for scanning single and multiple barcodes, and control over the device camera and flashlight. Afterward, you’ll have a better idea of what you should be looking for in an alternative barcode scanning solution.

Introduction: The state of the cmbSDK in 2026

The cmbSDK has been sunsetted and will no longer receive updates or bug fixes. For companies with apps that depend on it, this has a number of practical implications worth understanding.

Mobile operating systems evolve continuously. Apple and Google release major iOS and Android updates on a yearly basis, which regularly introduce changes to camera APIs, permission models, and system behavior that SDK vendors need to respond to. Without ongoing maintenance, the cmbSDK will not be updated to reflect these changes. Over time, this is likely to result in degraded scanning performance, unexpected behavior, or outright failures on newer OS versions. Alongside this, both the Apple App Store and Google Play Store periodically update their requirements around minimum SDK versions, privacy declarations, and API usage, which are enforced at the point of app submission. An app built on an unmaintained SDK may eventually fail to pass submission review, making it impossible to ship updates until the underlying dependency is replaced.

Since online support for the cmbSDK has ceased, there is no way to report bugs, request fixes, or get help with integration issues. Any problems will need to be resolved without vendor assistance.

For apps currently using the cmbSDK, the question is not whether to find a replacement, but when. The SDK may continue to function adequately in the short term, but the risks associated with continued reliance on it will grow over time as operating systems, devices, and app store requirements move forward.

The following section takes a closer look at what the cmbSDK provided, so that you can evaluate replacement solutions accordingly.

What to look for in a replacement SDK

Before evaluating alternatives, it helps to take stock of what the cmbSDK was actually doing for you. Some of these capabilities are common in many barcode scanning SDKs, others are more unique to the cmbSDK.

Please note that the following aspects primarily cover mobile barcode scanning using the device camera.

A unified scanning abstraction

The cmbSDK’s ReaderDevice object provided a single interface for managing the entire scanning lifecycle: initializing the scanner, configuring it, triggering reads, and releasing resources. This meant that your app’s scanning logic was organized around one coherent API rather than a collection of lower-level components.

When evaluating alternatives, consider how each one structures this abstraction. Some SDKs offer a similarly unified interface; others require you to wire together separate camera management, decoding, and configuration layers yourself. The more fragmented the architecture, the more integration and maintenance complexity your team will absorb into your own codebase.

Event-driven result delivery

The cmbSDK communicated with your app through a structured callback interface. Key events included:

• didReceiveReadResultArray, which delivered decoded results,
• availabilityChanged, which reflected whether the scanning source was accessible,
• connectionStateChanged, which tracked the open or closed state of the current session.

This event model meant your app could react cleanly to the full range of scanning outcomes without polling or manual state management. A replacement SDK should offer a comparably complete event model. When evaluating candidates, look beyond the successful scan callback and examine how each SDK surfaces errors, timeouts, and unexpected device state changes.

A built-in camera preview component

Rather than requiring you to build and manage a camera preview independently, the cmbSDK provided a ready-to-embed UI component that handled the live camera feed and presented it to the user. This component also supported a configurable scan area and a targeting overlay to guide the user.

These elements are often customer-facing and directly affect the scanning experience. When assessing alternatives, consider not just whether a built-in preview component exists, but how much control it offers over the overlay’s appearance and the scan area’s size and position. Also consider how the component integrates with your existing view hierarchy on both iOS and Android, as behavior can differ meaningfully between platforms.

Scanning screen customization

The cmbSDK gave developers control over the visual appearance of the scanning interface beyond the defaults. This included adjusting the shape, size, and position of the scan area, modifying the overlay’s color and style, and controlling elements like on-screen buttons and instructional text. For many apps, the scanning screen is a frequently used part of the user interface and its appearance needs to align with the rest of the product’s design language.

When evaluating alternatives, look at the full extent of UI customization they offer and whether they allow you to build a fully custom scanning screen from scratch if needed.

Broad symbology support

The cmbSDK supported a wide range of 1D and 2D barcode symbologies, including common formats like QR Code, Code 128, Code 39, EAN, UPC, and Data Matrix, as well as less common ones like PDF417, Aztec, and MaxiCode. It also allowed you to enable only the symbologies relevant to your use case, which helped keep decode times fast by reducing the number of formats the engine evaluated on each frame.

Before finalizing an evaluation, test each candidate against a representative sample of the barcodes your users actually encounter, including worn, poorly printed, small, or partially obscured codes.

Flexible scanning modes

The cmbSDK’s default scanning mode was oriented around reading one barcode at a time: a read was triggered, a single result was returned, and the session paused until the next trigger. But the SDK also supported continuous scanning, where the engine remained active after a successful read and moved on to the next barcode without requiring a new trigger. This is suited to workflows where a user needs to scan a series of items in quick succession.

In addition, it was possible to detect and decode multiple barcodes present in the camera frame at the same time and return all of them in a single result. This is a more demanding capability than sequential scanning and is not universally supported. It is particularly relevant in workflows involving shelf scanning, batch processing, or any scenario where multiple codes are likely to appear in the same frame.

The cmbSDK’s scanning behavior could be further configured in terms of scan timeout, illumination control, image output alongside decoded results, and scan area restrictions that limited decoding to a defined region of the frame. Any alternative solution should offer a comparable degree of control.

Camera selection and flashlight control

The cmbSDK allowed developers to specify which device camera to use for scanning (most commonly the rear camera, but with the option to switch to the front-facing camera where the use case required it). On modern devices, this can also extend to selecting between multiple rear cameras, such as a wide-angle or telephoto lens, which can have a significant impact on scanning performance.

Ensure your alternative offers both a programmatic way to set the default camera and a user-facing option to switch between cameras while the scanning screen is active.

The same goes for controlling the device’s flashlight, which helps scan barcodes in poor lighting conditions, but can also lead to glare. Therefore, the user must be able to toggle it from the scanning interface.

Platform lifecycle integration

The cmbSDK was designed to integrate with the native lifecycle of both iOS and Android apps. On iOS, it was typically connected in viewWillAppear and disconnected in viewDidDisappear. On Android, the equivalent hooks were onResume and onPause. This made it straightforward to acquire and release camera resources in step with the app’s foreground and background states.

Correct lifecycle integration matters both for resource management and for user experience. A scanner that holds the camera open in the background can conflict with other apps or drain battery unnecessarily. When evaluating alternatives, verify that the SDK integrates cleanly with platform lifecycle events on both operating systems. Android in particular can behave differently across manufacturers and OS versions when it comes to camera resource handling.

Support for cross-platform development frameworks

The cmbSDK provided native SDKs for both iOS and Android, but also offered support for cross-platform development frameworks, allowing teams working in environments like React Native or Flutter to integrate barcode scanning without having to write native code for each platform.

If your app is built on a cross-platform framework, consider this aspect carefully during evaluation. Native SDKs are not always accompanied by official cross-platform bindings, and community-maintained wrappers vary significantly in quality, completeness, and how quickly they are updated when the underlying native SDK changes. Confirm whether your alternative offers official support for your frameworks and what that covers relative to the native SDK’s feature set.

Conclusion

To summarize, these are things the cmbSDK provided that you need to take into account when migrating to an alternative solution:

Capability	What to look for
Unified scanning abstraction	Single coherent API for the full scanning lifecycle
Event-driven result delivery	Callbacks for results, state changes, errors, and timeouts
Built-in camera preview	Drop-in view component with overlay and scan area control
Scanning screen customization	Control over overlay, scan area, and full custom UI if needed
Broad symbology support	Support for all symbologies that might need to be decoded
Flexible scanning modes	Ability to cover both single- and multi-barcode scanning use cases
Camera selection and flashlight control	Programmatic configuration options and UI-based toggles
Cross-platform development support	Native and framework-based options for Android, iOS, and Web

The cmbSDK handled a significant amount of complexity on behalf of the apps built on it, from the low-level details of camera and lifecycle management to the user-facing elements of the scanning experience. No single alternative will necessarily match the cmbSDK on every point, and the right choice will depend on your app’s specific requirements, your team’s technical constraints, and the barcodes your users actually scan.

We developed the Scanbot Barcode Scanner SDK as a developer-friendly solution for a wide range of platforms that consistently delivers high-quality results, even in challenging circumstances. With its enterprise-grade support and flat-fee pricing, the Scanbot SDK is a viable cmbSDK alternative for companies in need of a powerful scanning solution on mobile devices.

To learn more, head over to the documentation or try the demo app on your device.

FAQ