Add UIViewRepresentable integration to the SparkScan SwiftUI guide

[ts1mafei]

What

Expands the iOS SparkScan Get Started With SwiftUI guide with a new section documenting the pure-SwiftUI integration path: wrapping SparkScanView directly with UIViewRepresentable and a coordinator, as an alternative to the existing withSparkScan view modifier.

Part of SDC-31151.

Structure

The new section is placed at the bottom of the page, below the existing UIViewControllerRepresentable-based content, and follows the page's existing style (step-by-step sections, small code chunks, API links):

• Create the UIViewRepresentable — the wrapper struct; lifecycle driven by an isActive flag instead of viewWillAppear/viewWillDisappear; hit-test forwarding for the floating UI
• Create the Coordinator — owns the long-lived SparkScan objects; forwards SparkScanListener and SparkScanFeedbackDelegate to SwiftUI closures (with the threading contracts called out)
• Update Settings While Scanning — diff-and-apply on the existing settings instance so other customizations are preserved; notes that any SparkScanSettings property can be forwarded the same way
• Use the Scanner in Your SwiftUI App — state-driven usage with a symbology toggle example

The intro notes the trade-off: withSparkScan is often the easier path (especially for more advanced configurations), while UIViewRepresentable can feel more natural in a pure SwiftUI codebase.

Notes

• The code mirrors a sample implementation that compiles against the current SDK (ListBuildingSampleSwiftUIRepresentable, in review for data-capture-sdk).
• Edited docs/ (next version) only; versioned docs untouched.
• npm run build passes; the section renders under the next version route.

🤖 Generated with Claude Code

[marcozoffoli-scandit]

Thanks for adding this — nice addition to the SwiftUI guide, and the threading callouts are a great touch. I left a few small, non-blocking suggestions inline, mostly around making the example as copy-paste-robust as possible for readers.

[marcozoffoli-scandit]

updateUIView runs on every SwiftUI state change — in the usage example below, that includes every scanned barcode being appended to scannedBarcodes. As written, prepareScanning() is therefore re-invoked once per scan while the scanner is active.

If a redundant prepareScanning() is a guaranteed no-op in the SDK this is harmless, but it might be safer not to rely on readers knowing that. One option is to have the coordinator remember the last applied value and only call prepareScanning()/stopScanning() on transitions, e.g.:

if isActive != context.coordinator.isScanningActive {
    context.coordinator.isScanningActive = isActive
    isActive ? context.coordinator.sparkScanView?.prepareScanning()
             : context.coordinator.sparkScanView?.stopScanning()
}

That would also make this consistent with the diff-before-apply pattern used in applySymbologiesIfNeeded below.

[ts1mafei]

🤖 Good catch — and your hedge was actually too generous: a redundant prepareScanning() is not a no-op. In the SDK it unconditionally resets the view state to Idle and re-applies camera settings (SDCSparkScanViewManager.mm, prepareScanning), so calling it per render can interrupt active scanning after every recognized barcode. Adopted your transition guard (via coordinator.isScanningActive) in fa03219 — it also keeps the example consistent with the diff-before-apply pattern in applySymbologiesIfNeeded. The change is verified in the compiling companion sample (ListBuildingSampleSwiftUIRepresentable in data-capture-sdk).

[marcozoffoli-scandit]

Small suggestion: when the scanner view is removed from the hierarchy (navigation pop, conditional view, etc.) while isActive is still true, stopScanning() is never called and cleanup relies on deallocation. Adding a dismantleUIView would model the full lifecycle for readers:

static func dismantleUIView(_ uiView: UIView, coordinator: SparkScanScannerCoordinator) {
    coordinator.sparkScanView?.stopScanning()
}

[ts1mafei]

🤖 Agreed — added dismantleUIView calling stopScanning() in fa03219, so the teardown path is modeled too.

[marcozoffoli-scandit]

Minor thread-safety note: this delegate method reads self.feedbackFor from a background queue, while update(onScan:feedbackFor:) reassigns the same property from the main thread on every render — so there's an unsynchronized read/write on the coordinator's stored closures themselves (slightly at odds with the comment above, which warns about state accessed inside the closure).

For a docs example this may well be an acceptable simplification, but it could be worth either protecting the closure properties with a small lock, or extending the comment to acknowledge the simplification so readers don't copy it into more complex setups unaware.

[ts1mafei]

🤖 Fair point — the read/write on the stored closures themselves is indeed unsynchronized. Went with your lighter option to keep the get-started example lean: the comment now explicitly acknowledges the simplification and tells readers to add locking around the stored closures if their app replaces them frequently (fa03219).