Symbology and Regex Filtering — Complete BarcodeFilterSettings Guide

TL;DR

The Scandit SDK filtering pipeline spans five layers. Layers 1–2 (SymbologySettings.isEnabled, activeSymbolCounts) are pre-filters that block recognition attempts entirely — lowest CPU and battery cost. Layer 3 handles 1D+2D composite codes. Layer 4 (BarcodeFilterSettings: excludedSymbologies, excludedCodesRegex, excludedSymbolCounts) post-filters after decode, masking results from both callback and overlay without restarting the session. Layer 5 is app-callback business logic. Pre-filters minimize processing cost; post-filters enable runtime switching. Korean deployments combine Layer 1 allowlisting with Layer 4 regex for waybill, pharma GS1 DataMatrix, and EAN-13 880-prefix patterns.

---

Scandit's Five Filtering Layers — Decision Tree

The Scandit SDK's recognition pipeline offers five distinct interception points where unwanted results can be removed. Understanding these layers as a stack — rather than as independent settings — makes it straightforward to decide where a given filtering requirement belongs and how much it will cost in processing resources.

Layer 1: Symbology Enable/Disable — Lightest Pre-Filter

The first and most computationally inexpensive layer is symbology activation via SymbologySettings.isEnabled. Every symbology that is not explicitly enabled is excluded from the SDK's frame-by-frame recognition pass entirely. No decoding attempt is made; no result is generated; no processing cost is incurred for that symbology on any frame.

The SDK ships with a defined set of default symbology activation states — notably, QR Code and EAN-13 are disabled by default and must be explicitly enabled. Some legacy symbologies may be enabled by default. Data Connect's standard recommendation for all new integrations is to adopt a whitelist approach from the outset: enumerate exactly which symbologies the operational environment contains, enable only those, and explicitly disable everything else. Leaving unknown symbologies in their default active state is a frequent source of false reads in mixed-label environments.

In iOS Swift, enabling a symbology looks like settings.set(symbology: .ean13UPCA, enabled: true). In Android Kotlin it is settings.enableSymbology(Symbology.EAN13_UPCA, true). Web TypeScript and React Native follow the same conceptual pattern — see the code sample tabs at the top of this page for each platform's exact form. The Scandit Docs — Configure Barcode Symbologies (iOS) provides the full list of symbology identifiers and their default states.

Layer 2: Active Symbol Counts — Length-Based Pre-Filter

SymbologySettings.activeSymbolCounts adds a second pre-filter inside the symbology's own recognition stage. For variable-length symbologies — Code 39, Code 128, Code 93, and similar — this property constrains which data lengths the SDK will accept. A Code 39 string that does not match the configured length set is discarded before it reaches the result callback.

EAN-13 is always exactly 13 digits, so Active Symbol Counts has no meaningful effect on it. But for Code 128, which can encode anything from a few characters to over 100, restricting accepted lengths to the range your environment actually uses eliminates a significant class of false reads before they consume application-layer processing resources.

In iOS Swift, the pattern is:

let symSettings = settings.settings(for: .code39)
symSettings.activeSymbolCounts = Set([8])

In Android Kotlin:

val symSettings = settings.getSymbologySettings(Symbology.CODE39)
symSettings.activeSymbolCounts = setOf(8)

Setting the allowed range too wide increases the probability of capturing partial or incidentally correct reads from adjacent label text. In environments where code lengths are predictable — domestic parcel carrier waybills are exactly 12 digits, MFDS pharma GTIN fields are 14 digits — constraining Active Symbol Counts to the exact expected length is one of the most effective noise-reduction measures available.

Layer 3: Composite Types — 1D+2D Pharma Code Handling

GS1 composite codes combine a 1D linear symbology (EAN-13, Code 128, or GS1 DataBar) with an attached 2D component (CC-A or CC-B) stacked vertically on the same label. A composite code carries the GTIN in the 1D component and supplementary AI data — expiry date, batch number, serial number — in the 2D component, allowing both components to be decoded as a single logical scan result.

Pharmaceutical labels in Korea frequently carry GS1-128 composite codes that combine the linear carrier with a CC-A or CC-B 2D component. Enabling EAN-13 or Code 128 alone does not activate composite decoding — you must explicitly set the enabledCompositeTypes property on BarcodeCaptureSettings to include CompositeType.a, CompositeType.b, or CompositeType.c as appropriate for the label format in use.

Enabling composite type recognition adds processing overhead on every qualifying frame. Only activate it in environments where composite codes are genuinely present. For a parcel carrier waybill-only scanning station, composite types should remain disabled; for a pharmaceutical dispensing point processing MFDS-serialized unit packages, CC-A and CC-B should be active alongside DataMatrix.

Layer 4: BarcodeFilterSettings — Post-Filter with Visual Masking and Callback Exclusion

BarcodeFilterSettings operates after the SDK has completed full decoding. The recognition pipeline has already identified and decoded candidate barcodes; BarcodeFilterSettings evaluates each result against its configured rules and decides whether to pass the result to the application or exclude it.

The class exposes three exclusion mechanisms:

excludedSymbologies removes all results of specified symbology types from the callback. Unlike Layer 1 (which prevents recognition entirely), this exclusion still allows the decode to occur — useful when you need the SDK to recognize a symbology to update the visual overlay but not pass results to business logic.

excludedCodesRegex matches the decoded data string against a regular expression pattern. Any result whose data matches the pattern is excluded from both the callback and the visual overlay. This is the primary tool for domain-specific pattern filtering: Korean EAN-13 codes with the 880 prefix, pharma GS1 AI strings, logistics waybill formats. iOS Swift uses escaped regex strings; Android Kotlin uses the same string format but must escape the Kotlin string-template $ character; the Web TypeScript SDK accepts a native JavaScript RegExp object; React Native uses string format with the same escaping rules as Swift. Refer to each platform's code sample above for the exact syntax.

excludedSymbolCounts removes results of a specific decoded length from the callback. This is a post-filter counterpart to Layer 2's Active Symbol Counts — less efficient (decoding still occurs) but available for cases where the filtering condition must be set at runtime without reconfiguring the core BarcodeCaptureSettings.

Once configured, BarcodeFilterSettings is assigned to the BarcodeCaptureSettings instance via settings.filterSettings = filter. The configuration applies immediately to subsequent frames.

Layer 5: App Callback Regex — Business Logic Validation

The fifth layer is not an SDK API at all — it is application code executing inside the BarcodeCaptureListener.didScan() callback (or the platform-equivalent event handler). After the SDK delivers newlyRecognizedBarcodes from the BarcodeCaptureSession, your application iterates the results and applies any business logic validation that could not be expressed through the SDK's built-in filter mechanisms.

Common examples include: verifying that an employee badge barcode matches the company's internal ID format (^[A-Z]{2}\d{6}$), confirming that a scanned GS1 DataMatrix payload contains all four required Application Identifier fields before forwarding it to the MFDS serialization API, or checking a waybill checksum against the logistics provider's algorithm. These validations depend on application context, database state, or business rules that do not belong in the SDK configuration layer.

Layer 5 is the final gate after all SDK filtering costs have been paid. If your callback regularly discards a high proportion of the results it receives, that is a signal to push more of the exclusion logic into Layer 4 or Layer 2 — where the same result would be eliminated before consuming callback processing resources.

---

Pre-Filter vs Post-Filter — When to Use Which

The battery and CPU tradeoff between pre-filtering and post-filtering is concrete and measurable, but it is not the only consideration. Session flexibility matters equally in many operational contexts.

Pre-filters (Layers 1 and 2) interrupt the recognition pipeline before decoding completes. Disabling a symbology means the SDK's AI Engine never attempts to locate or decode that symbology's patterns in any camera frame. The cost savings compound across every frame: a scanning session processing 30 frames per second for 8 hours eliminates recognition attempts for that symbology on 864,000 frames. On mid-range Android hardware — where battery life and thermal throttling under sustained camera load are real operational factors — the difference between enabling 2 symbologies versus 12 is measurable in session duration and device temperature.

Pre-filtering is the correct approach when:

• The set of symbologies present in the scanning environment is known and stable
• The session's symbology requirements do not change while the camera is running
• Battery and CPU optimization is a primary constraint (mobile handheld devices, all-day scanning shifts)

Post-filtering (Layer 4: BarcodeFilterSettings) operates after the SDK has spent the recognition cost. Its advantage is runtime flexibility: you can replace or modify a BarcodeFilterSettings object on the active BarcodeCaptureSettings without stopping the camera session, closing the capture mode, or re-initializing the SDK context. This is essential for multi-mode scanning workflows where an operator switches between task types while the camera remains active.

Post-filtering is the correct approach when:

• Filtering conditions change based on operator input, selected workflow, or real-time application state
• You need to suppress specific code patterns conditionally rather than categorically
• Visual masking (showing the user that a code was detected but excluded) is part of the UX requirement

The practical design principle is: pre-filter to the minimum viable active symbology set, then post-filter for anything that requires runtime adjustment. The two layers are not mutually exclusive — the code samples in this guide apply both simultaneously, enabling only EAN-13 at Layer 1 and then using BarcodeFilterSettings at Layer 4 to exclude the 880-prefix KR domestic subset.

One threading note: when modifying BarcodeFilterSettings at runtime, changes must be applied on the main thread (iOS: main dispatch queue; Android: main thread). Background-thread modifications to BarcodeCaptureSettings produce undefined behavior. In practice, the symptom is a filter change that appears to take effect with a one-to-several-second delay that correlates with frame processing cycles — a common field report that almost always traces back to threading.

---

BarcodeFilterSettings Deep Dive — Visual Masking vs Callback Exclusion

Scandit's SDK documentation covers BarcodeFilterSettings primarily in its API reference section and gives relatively brief treatment to one of the class's most practically significant behaviors: the dual effect of exclusion on both the application callback and the visual overlay. This section addresses that gap directly.

When BarcodeFilterSettings marks a decoded result for exclusion, two independent effects occur within the SDK's processing pipeline before control returns to your application.

Effect 1 — Callback exclusion. The barcode is removed from the newlyRecognizedBarcodes array in the BarcodeCaptureSession. From your application's perspective, the code does not exist. No business logic, no database lookup, no counter increment — the excluded code produces zero application-layer effects. This is the behavior most developers expect.

Effect 2 — Overlay visual masking. The BarcodeCaptureOverlay renders a visual indicator over the excluded barcode's screen position. By default, this is a distinct color — different from the green/blue highlight used for accepted results — signaling to the user that a barcode was detected but not processed. The SDK computes the screen bounding box of the excluded symbol and renders the mask within it, using the same spatial tracking it uses for normal result highlights.

The significance of this dual behavior becomes apparent in mixed-label scanning environments. Consider a pharmaceutical receiving station where the operator is expected to scan GS1 DataMatrix unit codes, but the carton also carries a Code 128 logistics label. With a configuration that enables both symbologies at Layer 1 (necessary for other stations in the workflow) and excludes Code 128 via BarcodeFilterSettings.excludedSymbologies, the operator sees the Code 128 label highlighted in the exclusion color and the DataMatrix code highlighted in the accepted color. No verbal instruction is needed — the visual differentiation communicates which code to focus on.

The masking color and style are configurable via BarcodeCaptureOverlay. The specific API for customizing the excluded-result brush varies by platform — refer to the BarcodeFilterSettings API (iOS) and platform equivalents for the exact property names. If the UX requirement is for excluded codes to be invisible rather than highlighted differently, set the exclusion brush color to fully transparent.

One design implication: if you are building a workflow where excluded codes should produce a user-facing alert ("wrong barcode type — please scan the DataMatrix label"), you cannot rely on the callback to trigger that alert, because excluded codes do not appear in the callback. The mechanism for that alert is the overlay's visual cue, potentially supplemented by a separate BarcodeTrackingListener if you need to respond programmatically to detected-but-excluded results.

---

Regex Filtering — Korea Domain Patterns

The following patterns appear repeatedly in Korean market integrations. Each can be applied at Layer 4 (BarcodeFilterSettings.excludedCodesRegex to exclude matching codes) or at Layer 5 (app callback validation to accept only matching codes). The appropriate layer depends on whether the filtering is categorical (exclude permanently, use Layer 4) or conditional (validate in context, use Layer 5).

KR EAN-13 880 Prefix

GS1 Korea's assigned country code prefix is 880. Every EAN-13 barcode on a product manufactured in Korea begins with 880. The full 13-digit structure is: 880 (GS1 Korea prefix, 3 digits) followed by a GS1 member company code, an item reference number, and a single check digit — all totaling exactly 13 characters.

The regex pattern:

^880\d{10}$

In a distribution system that processes only domestically produced goods, a Layer 5 validation against this pattern confirms that the scanned product belongs to the expected product range. Conversely, in a system that should exclude domestic products and focus on imports, apply the negated match logic in the callback.

iOS uses Swift's \\d escape inside string literals, so the pattern becomes "^880\\d{10}$" in Swift code. React Native uses single-quoted strings with the same escaping convention: '^880\\d{10}$'. The Web TypeScript SDK accepts a native JavaScript RegExp, so the pattern is written as /^880\d{10}$/ without additional escaping.

Domestic Parcel Carrier Waybill — 12-Digit Code 128

A major Korean domestic parcel carrier encodes shipment tracking numbers as 12-digit numeric strings carried in Code 128 (or GS1-128) symbology. The pattern is:

^\d{12}$

For an inbound receiving station where only waybill scans are relevant, the correct configuration is Layer 1 (enable Code 128 only) combined with Layer 5 validation against ^\d{12}$. If the station must also handle product EAN-13 scans in the same session, Layer 4 can differentiate: BarcodeFilterSettings.excludedSymbolCounts excludes non-12-digit Code 128 results, keeping only waybill-length strings in the callback.

For carriers or systems that require carrier-specific prefix discrimination, the pattern can be tightened. A waybill beginning with a known carrier prefix digit can be validated with a more specific pattern — for example, ^6\d{11}$ if the operational data confirms that prefix. Always validate the actual waybill number range with the logistics provider before deploying a tightened pattern.

Employee Badge Format

Manufacturing facilities and warehouse environments that authenticate workers by scanning badge barcodes or QR codes frequently use a company-specific ID format. A representative pattern combining a two-letter departmental prefix with a six-digit employee number:

^[A-Z]{2}\d{6}$

For a deployment like Data Connect's reference configuration, this produces identifiers in the format DC123456. The exact format varies by organization — some use purely numeric IDs, others add a year prefix or site code. This validation belongs in Layer 5, where the format check can be paired with a database lookup to confirm the employee record exists before granting access or recording the event.

MFDS Pharma GS1 AI(01) GTIN

Under the Ministry of Food and Drug Safety's pharmaceutical serialization regulation, GS1 DataMatrix symbols on Korean drug packaging encode a payload that begins with Application Identifier (01) carrying a 14-digit GTIN, followed by additional AI fields for expiry date (AI 17), batch number (AI 10), and serial number (AI 21).

A basic regex to detect the AI(01) GTIN prefix:

^\(01\)\d{14}

The parentheses in (01) are literal characters in the decoded data string, not regex grouping operators — they must be escaped as \( and \). The pattern anchors on the string start and matches the 18-character AI(01)+GTIN prefix without requiring a full-string match, because the GS1 string continues with additional AI fields of variable length.

This pattern is a format pre-check, not a compliance validator. Full GS1 Application Identifier parsing — including FNC1 separator handling for variable-length AI fields — requires a GS1 parser library. Using this regex at Layer 5 to quickly discard strings that clearly do not follow the MFDS DataMatrix format is reasonable; relying on it as the sole integrity check before writing to the MFDS serialization database is not.

For MFDS serialization system integrations, Data Connect provides a test DataMatrix set covering the required AI combinations as part of the engagement onboarding package.

---

AI Duplicate Filter (SDK 8) vs BarcodeFilterSettings.excludedCodesRegex

Both the AI duplicate filter introduced in SDK 8 and BarcodeFilterSettings.excludedCodesRegex produce the effect of "ignoring" certain barcode results, but they address entirely different classes of problem and should not be treated as substitutes for each other.

The AI duplicate filter targets the temporal redundancy inherent in camera-based scanning. When a user holds a device's camera over a barcode, the SDK processes multiple frames per second and would, without suppression, fire a new callback on every frame where the barcode is successfully decoded. In a 30-fps session, a user who holds steady for one second would generate 30 callbacks for a single scan event. The AI duplicate filter collapses this into a single callback by tracking which codes have recently been reported and suppressing repeats within a dynamically computed suppression window. The window duration is inferred from observed user behavior — the SDK accounts for deliberate rescanning (where the user intentionally scans the same code again after moving away and returning) versus incidental hold time.

For the technical specification of the SDK 8 AI duplicate filter, see Scandit Docs — AI-Powered Barcode Scanning.

BarcodeFilterSettings.excludedCodesRegex is stateless with respect to time. A barcode whose data matches the configured pattern is excluded on every recognition attempt, across every frame, for the entire session. There is no suppression window, no reinstatement after a timeout, and no inference about user intent. The pattern is a permanent categorical rule: codes of this format do not belong in this application's result stream, ever.

Criterion	AI duplicate filter	excludedCodesRegex
Problem addressed	Same code decoded on multiple frames	Wrong-format code decoded on any frame
Time dimension	Yes — suppresses within a dynamic window	None — permanent categorical exclusion
Appropriate use	Continuous scan workflows, all scanning modes	Domain-specific pattern exclusion
Minimum SDK version	SDK 8+	SDK 6+
Runtime changeable	Configured at session level	Yes, via filterSettings replacement

In a typical production configuration, both mechanisms are active simultaneously. The AI duplicate filter handles the repetition problem inherent in camera-based scanning, while excludedCodesRegex handles the domain-specificity problem of environments that contain multiple barcode types but only need to process a defined subset. The two do not conflict — a code can be excluded by pattern rule before the duplicate filter even evaluates it.

---

OCR Fallback Regex (v7.4+) — When Barcodes Fail, Text Wins

Introduced in Scandit SDK v7.4, the OCR fallback feature (SymbologySettings.ocrFallbackRegex) provides a recovery path for barcode symbols that cannot be decoded due to physical damage, inadequate print quality, label surface contamination, or insufficient camera resolution. When OCR fallback is active for a symbology and a frame contains a region that appears to carry a barcode of that type but cannot be decoded, the SDK attempts to read the text within that region using its optical character recognition engine and validates the extracted text against the configured regex pattern. If the pattern matches, the text is returned as a scan result flagged as an OCR fallback result.

The practical significance is highest in two Korean operational contexts.

Pharmaceutical unit tracking under MFDS serialization. GS1 DataMatrix symbols on drug packaging can degrade through the cold chain — condensation, adhesive failure at low temperatures, abrasion during transit. A DataMatrix symbol that is 60% damaged may not decode via the standard symbology path, but its numeric serial number content may still be legible as text by the OCR engine. With ocrFallbackRegex configured to match the MFDS serial number format, the SDK recovers a usable result where the standard path would produce a no-read. This reduces manual re-entry events at dispensing points.

Legacy Android hardware in warehouse environments. Older mid-range Android devices deployed in warehouse scanning roles often have cameras with limited close-range resolution — adequate for large logistics labels but marginal for the smaller DataMatrix symbols on individual pharmaceutical packaging. OCR fallback extends the effective decode range of these devices without a hardware replacement cycle, which in large fleet deployments is a significant cost consideration.

ocrFallbackRegex is configured per symbology, on the SymbologySettings object for that symbology. This means OCR fallback can be activated exclusively for DataMatrix — where print quality degradation is operationally significant — while remaining disabled for EAN-13 and Code 128, where OCR fallback adds overhead without a corresponding benefit.

Performance tradeoff: OCR processing is computationally more expensive than standard symbology decoding. Enabling OCR fallback globally across all active symbologies in a high-frame-rate scanning session will reduce throughput. Data Connect's implementation guidance is to activate OCR fallback only for the specific symbologies where label degradation is a documented field problem, to log OCR fallback result events separately from standard decode events, and to run an A/B measurement against a control configuration before committing the feature to production. If OCR fallback results account for fewer than 1% of total scan events, the performance cost may not be justified.

---

Korean Market Cases

Domestic Parcel Carrier Waybill-Only Tuning

A domestic logistics warehouse deploying a receiving station app with Scandit SDK on shared Android handhelds had a specific requirement: only parcel carrier waybill codes (12-digit Code 128) should trigger receiving records. The physical environment placed multiple barcode types within camera range simultaneously — EAN-13 product codes on carton contents, QR codes on supplier labels, and internal logistics codes on rack shelving.

The Data Connect configuration for this deployment used Layer 1 exclusively: Code 128 enabled, all other symbologies disabled. No BarcodeFilterSettings was configured. Layer 5 applied the ^\d{12}$ validation in the callback, logging any Code 128 result that did not match the expected length as an anomaly for monitoring rather than discarding it silently. The result was a configuration with the minimum possible recognition overhead — only Code 128 frames were processed — and zero false triggers from the surrounding label environment.

The principle this case illustrates is that BarcodeFilterSettings is not always necessary. When the symbology itself provides sufficient discrimination, Layer 1 alone is sufficient. BarcodeFilterSettings adds value when the filtering condition is more specific than "this symbology" — for example, when multiple Code 128 variants from different systems coexist in the environment and must be differentiated by payload structure.

MFDS Pharma Line — GS1 DataMatrix Serialization

A pharmaceutical contract manufacturer deploying a Scandit SDK integration at its quality control inspection station had both DataMatrix and EAN-13 present on every unit package — DataMatrix carrying the MFDS serialization payload, EAN-13 carrying the retail GTIN for end-of-line labeling. The QC application needed to record only the DataMatrix serialization data; the EAN-13 was irrelevant at that stage.

Layer 1 was configured with DataMatrix enabled and EAN-13 disabled for this station, which handled the basic discrimination. Layer 3 (composite types) was activated for CC-A because some SKUs used GS1-128 composite codes on secondary packaging. Layer 4 applied BarcodeFilterSettings.excludedCodesRegex with the pattern ^\(01\)\d{14} as an acceptance pre-check logic (inverted: codes that do not match the MFDS AI pattern were excluded), preventing non-MFDS DataMatrix symbols — for example, logistics DataMatrix from the carton — from reaching the serialization callback.

Layer 5 performed full GS1 Application Identifier parsing and queried the MFDS verification endpoint before accepting the scan as valid. The five-layer stack operated together: Layer 1 reduced the recognition load, Layer 3 handled composite codes, Layer 4 provided a first-pass format filter, and Layer 5 enforced compliance-grade validation. Filtering design at this level of specificity is not an optimization exercise — for MFDS-regulated workflows, an incorrect scan result that passes to the serialization database can constitute a regulatory reporting error.

For engagements requiring MFDS serialization integration, Data Connect provides a structured proof-of-concept environment with test DataMatrix symbols covering all required AI combinations.

---

Frequently Asked Questions

The following expanded answers correspond to the five FAQ items summarized in this page's structured data. The FAQ covers the questions Data Connect engineers hear most frequently during Scandit SDK integration projects in Korea.

On choosing pre-filter vs post-filter: The decision turns on session flexibility. If the symbology configuration is static for the life of the camera session, Layer 1 pre-filtering delivers the best performance profile. If the operator needs to switch scanning modes without restarting the session — a common requirement in receiving and returns workflows — Layer 4 BarcodeFilterSettings provides runtime flexibility at the cost of continued recognition overhead for all active symbologies. The practical answer for most deployments is to apply both: Layer 1 reduces the active set to what the environment contains, and Layer 4 handles the residual dynamic conditions.

On Active Symbol Counts vs BarcodeFilterSettings: These operate at different points in the pipeline and address different dimensions of filtering. Active Symbol Counts rejects results inside the symbology's recognition stage based on decoded length — computationally earlier and less expensive. BarcodeFilterSettings evaluates fully decoded results against regex patterns, symbology types, and symbol counts — more expressive but positioned after the recognition cost has been paid. Applying both in the same configuration is standard for environments where both length-based and pattern-based discrimination are needed.

On Korean waybill regex: A domestic parcel carrier waybill barcode and a Korean domestic EAN-13 product code occupy different symbologies — Code 128 and EAN-13 respectively — so the symbology check at Layer 1 handles the primary discrimination. When both symbologies must remain active in the same session, the regex ^\d{12}$ applied at Layer 5 (for Code 128 results) and ^880\d{10}$ applied at Layer 5 (for EAN-13 results) provide domain-level validation. Checking the barcode.symbology property in the callback before applying the corresponding regex avoids pattern cross-contamination between symbology types.

On BarcodeFilterSettings dual effect: The visual masking and callback exclusion happen atomically within the SDK's result processing pipeline. Both effects apply to every excluded code on every frame — there is no mode where only one applies. For UI customization, the exclusion brush color is configured through BarcodeCaptureOverlay and can be set to fully transparent if excluded codes should not be visually indicated. For programmatic response to excluded codes (for example, triggering an audio alert), the mechanism is the overlay visual cue rather than the callback, since excluded codes do not appear in newlyRecognizedBarcodes.

On AI duplicate filter vs excludedCodesRegex: These two features complement each other and should both be active in most continuous-scan workflows. The AI duplicate filter handles the temporal problem — preventing the same barcode from generating dozens of callbacks during a single hold event. excludedCodesRegex handles the categorical problem — permanently excluding codes whose data format does not belong in the application's result stream. Deploying both simultaneously is the standard configuration for production Scandit SDK integrations at Data Connect.

---

Last Updated

Last updated: 2026-05-01

The content on this page is current for Scandit SDK 8.x. API signatures and configuration patterns may change with SDK version updates; Data Connect reviews this content quarterly. For full API reference, see the BarcodeFilterSettings API (iOS), SymbologySettings API (iOS), and AI-Powered Barcode Scanning.

For Scandit SDK integration support, a proof-of-concept environment, or MFDS pharma serialization guidance specific to the Korean market, contact Data Connect.

// iOS Swift — Layer 1 + Layer 4: EAN-13 only, exclude 880-prefix KR domestic codes
let settings = BarcodeCaptureSettings()
// Layer 1: Enable EAN-13 only (all others disabled by default unless explicitly enabled)
settings.set(symbology: .ean13UPCA, enabled: true)
// Layer 4: BarcodeFilterSettings — exclude codes matching KR GS1 880 prefix
let filter = BarcodeFilterSettings()
filter.excludedCodesRegex = "^880\\d{10}$"
settings.filterSettings = filter

// Android Kotlin — Layer 1 + Layer 4: EAN-13 only, exclude 880-prefix KR domestic codes
val settings = BarcodeCaptureSettings()
// Layer 1: Enable EAN-13 only
settings.enableSymbology(Symbology.EAN13_UPCA, true)
// Layer 4: BarcodeFilterSettings — exclude codes matching KR GS1 880 prefix
val filter = BarcodeFilterSettings()
filter.excludedCodesRegex = "^880\\d{10}\$"
settings.filterSettings = filter

// Web TypeScript — Layer 1 + Layer 4: EAN-13 only, exclude 880-prefix KR domestic codes
const settings = await SDCBarcode.BarcodeCaptureSettings.fromJSON({});
// Layer 1: Enable EAN-13 only
settings.enableSymbology(SDCBarcode.Symbology.EAN13UPCA, true);
// Layer 4: BarcodeFilterSettings — exclude codes matching KR GS1 880 prefix
const filter = new SDCBarcode.BarcodeFilterSettings();
filter.excludedCodesRegex = /^880\d{10}$/;
settings.filterSettings = filter;

// React Native — Layer 1 + Layer 4: EAN-13 only, exclude 880-prefix KR domestic codes
const settings = new BarcodeCaptureSettings();
// Layer 1: Enable EAN-13 only
settings.enableSymbology(Symbology.EAN13UPCA, true);
// Layer 4: BarcodeFilterSettings — exclude codes matching KR GS1 880 prefix
const filter = new BarcodeFilterSettings();
filter.excludedCodesRegex = '^880\\d{10}$';
settings.filterSettings = filter;