kamera-react-native

The React Native SDK for kamera — a thin, faithful wrapper that embeds the native kamera cores (kamera-android, kamera-ios). It replaces react-native-vision-camera used by the production Smile ID RN SDK today.

What this is

• An RN library (@smileid/kamera) targeting the New Architecture: a Fabric native component (KameraPreviewView) for preview and a TurboModule (NativeKamera) for the control plane — configuration, lifecycle, capture, zoom/torch/focus — with analysis results and session state as direct events.
• Pixels never cross the bridge. Frame analysis (ML Kit / Vision through the frozen Analyzer pattern) runs natively; JS receives events and capture file paths. No frame-processor worklets in v1 — raw pixel access in JS is explicitly out of scope until a product case demands it.
• A real still-capture pipeline for RN. The production RN SDK today captures by grabbing an analysis frame; kamera gives RN the same ZSL / MaxQuality / Ultra-HDR capture path as native Android and iOS.

Goals

1. Behavioral parity with the native SDKs: same KameraConfig fields, same defaults, same events, same capture result schema (../SPEC.md §3–4).
2. Low-end performance by construction: preview is a native view, analysis is native, JS thread stays idle apart from lightweight events.
3. Serve as the ML staging ground for RN: sample/ renders native analysis events live so ML experiments validate here before the production RN SDK.

Layout

src/               TS API — KameraPreviewView (Fabric), NativeKamera (TurboModule spec), types
sample/            Sample app — preview, analysis event overlay, capture

ML backend toggle

The Android glue defaults to the ML Kit adapter; switch with one flag (docs/design/20 D4): -PkameraMlBackend=huawei (or KAMERA_ML_BACKEND=huawei) puts com.usesmileid:kamera-huawei on the host classpath and injects the HMS repo — none adds no adapter. iOS pairs with Vision (KameraVision); HMS ML is Android-only, a documented platform divergence.

Local development

Wire the glue to locally built cores — Android via publishToMavenLocal, iOS via locally built xcframeworks. Walkthrough: ../docs/local-dev.md.

iOS: Kamera comes from kamera-spm, not a vendored copy

The published package vendors no xcframeworks. Kamera and KameraVision reach the kamera-rn pod target through the public kamera-spm Swift package — the same package the Smile ID iOS SDK (ios-spm) declares — so an app that carries both resolves exactly one Kamera.framework. Wire it in the app's Podfile (the Smile ID Expo config plugins do this for you):

require File.join(File.dirname(`node --print "require.resolve('@smileid/kamera/package.json')"`),
                  "ios", "kamera_spm_link")

post_install do |installer|
  kamera_spm_link!(installer)   # pins kamera-spm at this package's own version
end

Besides linking the products into the kamera-rn pod target, the helper registers kamera-spm on the app's own project (CocoaPods drops the package references it adds to Pods.xcodeproj after post_install, and Xcode resolves only packages some project still lists) and links Kamera and KameraVision into every application target, which is what makes Xcode embed the two dynamic frameworks. A pod of your own that does import Kamera needs the product linked into its target as well — pass it through targets::

kamera_spm_link!(installer, targets: KAMERA_SPM_TARGETS.merge('MyProviderPod' => %w[Kamera]))

Local development against an unreleased core still vendors: scripts/fetch_xcframeworks.sh local kamera-react-native/ios/Frameworks makes the podspec vendor that directory while it exists (../docs/local-dev.md).

Why this package still has a podspec

Stable RN autolinking is podspec-driven; SPM autolinking is an RFC/prototype (react-native-community/discussions-and-proposals #994). kamera-rn.podspec is the minimum CocoaPods surface — it ships inside the npm package (never published to the CocoaPods trunk, so the Dec 2026 trunk read-only date doesn't affect it) and vendors the same xcframeworks the SPM-only Flutter glue uses. Drop it when RN ships SPM autolinking in stable. Details: docs/design/18.

Requirements

React Native ≥ 0.76 (New Architecture) · minSdk 24 · iOS 15.0 (matches the production Smile ID RN SDK floors)

Status

Bootstrapping — TS API stubs and codegen specs in place. See ../SPEC.md §6.4 and milestones §9.