usesmileid_kamera 1.0.6

Smile ID's purpose-built camera SDK for Flutter. A thin wrapper embedding the native kamera cores (kamera-android / kamera-ios). Pixels never cross the bridge.

Changelog

The single changelog for kamera. All four packages — Android (com.usesmileid:kamera + -mlkit / -huawei), iOS (Kamera.xcframework), Flutter (kamera), and React Native (@smileid/kamera) — are versioned and released in lockstep: every release publishes all four at the same version, no matter which platform the change touched. There are no per-package changelogs; record every user-facing change here under ## Unreleased.

The version is driven by the root VERSION file (bump with scripts/set-version.sh x.y.z); a CI gate keeps every package pinned to it.

Format: Keep a Changelog · Versioning: Semantic Versioning.

Unreleased

1.0.6

Fixed

• Android glue (Flutter and React Native, plugin and testing kit): a published package now pins com.usesmileid:kamera* at its own version (pubspec.yaml / package.json) instead of falling back to 0.1.0-SNAPSHOT outside the kamera repo. The plugins got away with it through Gradle conflict resolution against the SDK's own pin; the testing kits had nothing to resolve against and pulled a stale snapshot. The two testing kits also compile at SDK 36, the SDKs' consumer floor, instead of forcing 37 on the host — the reason the Flutter SDK's E2E lane stayed red after Android 12.1.0 lifted its own floor.
• React Native (iOS): kamera_spm_link! now also registers kamera-spm on the app's own project and links Kamera and KameraVision into every application target. CocoaPods drops the package references the helper attaches to Pods.xcodeproj after post_install, so with 1.0.5 Xcode only resolved kamera-spm when the app's other packages already depended on it and otherwise failed with "Missing package product 'Kamera'"; and a dynamic framework linked only into static pod targets is never embedded, so the app died in dyld at launch. Pods that import Kamera themselves can be passed through targets: so the product is linked into them too.
• Publishing: the pub.dev and npm lanes no longer try to copy vendored xcframeworks into the Flutter plugin or the two testing kits — the glue has depended on kamera-spm since 1.0.5, so the copy step failed the usesmileid_kamera 1.0.5 publish, and the testing kits were published with a stray Frameworks/ directory. Every lane now refuses to publish a package that vendors one.

1.0.5

Fixed

• iOS: the shipped xcframeworks now report the release they belong to. Every slice's CFBundleShortVersionString is stamped from the repo VERSION (its numeric core) and CFBundleVersion from the CI run number, and the build refuses to ship a slice that does not carry it; previously every release shipped the shim project's placeholder 0.1.0.

Changed

• The Flutter (usesmileid_kamera, usesmileid_kamera_testing) and React Native (@smileid/kamera, @smileid/kamera-testing) glue no longer vendor Kamera.xcframework and friends. Both consume the public kamera-spm Swift package at exactly this release — the same package the Smile ID iOS SDK (ios-spm) now declares — so an app that carries the SDK and a wrapper resolves ONE Kamera.framework instead of embedding two copies with one bundle id. Flutter: the manifests pin kamera-spm (stamped by scripts/set-version.sh, gated by the lockstep check) and the Kamera re-export product is gone — a host plugin that needs import Kamera depends on kamera-spm's Kamera product directly. React Native: the podspecs vendor only a local ios/Frameworks/ dir (dev loop, CI), and the app's Podfile links kamera-spm's products into the kamera-rn target with the shipped ios/kamera_spm_link.rb (kamera_spm_link!(installer)); the Smile ID Expo config plugins inject that call. The publish lanes fail if a Frameworks dir is present, and the RN CI proves the packed tarball vendors nothing. scripts/local_kamera_spm_mirror.sh gives the Flutter glue a local kamera-spm mirror for building against an unreleased core.

1.0.4

Fixed

• React Native (Android): the preview no longer renders black. React Native never re-lays out children a native view adds after mount, so PreviewView's lazily added TextureView stayed 0×0 and CameraX timed out waiting for the preview surface (no preview, no analysis frames); the view manager now hosts the preview in a view that re-runs measure/layout itself.
• Publishing: publish-all no longer reports the Flutter and React Native wrapper jobs as failed while their dispatched runs are publishing normally. scripts/dispatch-and-wait.sh passed jq --arg flags through gh run list --jq, which accepts a single expression, so the lookup errored silently on every poll and gave up after five minutes. gh now only fetches the JSON, a standalone jq --arg binds the values, and a gh error is reported instead of being read as "no run yet". On the 1.0.3 release the npm run it had dispatched succeeded behind the red job.

1.0.3

Changed

• Publishing: publish-all now dispatches the Flutter and React Native lanes as their own runs on the release tag instead of calling them, so npm sees the workflow filename it trusts and pub.dev sees the version tag it requires; both lanes gate on and publish from the tag's parent commit. The iOS and Android lanes skip a tag, release or Maven version that already exists, so a publish-all re-run after a wrapper failure completes the release. The kamera-spm snapshot branch now follows every release even though the sync PRs are squash-merged.

Fixed

• iOS: analysis frames and stills no longer keep the pre-lock orientation when a capture screen rotates the interface programmatically while the phone is held still — the way every Smile ID document flow applies its landscape lock. DisplayRotationTracker only refreshed on device-rotation notifications, which a programmatic lock never posts, so a session started in the same frame as the lock served its portrait seed until the phone physically moved: the v12 Flutter DocV preview showed the auto-captured document a quarter-turn off (and mis-cropped), while the live preview looked right. The tracker now revalidates its cached axis on read (one coalesced main-queue re-read per 250 ms) and KameraPreviewView refreshes it from its layout pass. Android is unaffected — its DisplayListener fires for a locked-orientation change.
• Android (com.usesmileid:kamera*): the AARs declare minCompileSdk 36 instead of inheriting the build's compileSdk 37 through AGP 9's default, and the Flutter and React Native wrapper modules compile against SDK 36, so an app on its framework's default compileSdk builds without raising it or installing platform 37. CI fails a release whose AARs stop declaring the floor.

1.0.2

Fixed

• React Native (@smileid/kamera) on iOS: the module compiles again. 1.0.1's frame-collector fix inserted a helper between @objc(release:rejecter:) and the release method it names, so the attribute landed on a zero-argument function and every iOS build that compiled the pod failed with "'@objc' method name provides names for 2 arguments, but method has 0". No behaviour change beyond building; 1.0.1 is unusable on iOS and should not be pinned.

1.0.1

The first stable release. It also carries everything published as 1.0.0-beta1 on 2026-08-25, which was never rolled out of this section.

Added

• iOS: kamera is now consumable through Swift Package Manager, from the public smileidentity/kamera-spm distribution repo — .package(url: "https://github.com/smileidentity/kamera-spm", exact: "<version>"), with Kamera, KameraVision and KameraTesting as separate products. Previously the xcframeworks were only attached to this repo's releases, so every consumer hand-vendored the zips. Both the manifest and its releases are produced by kamera-ios/Scripts/publish_spm.sh, mirroring how the v12 iOS SDK publishes to ios-spm: production versions land on main, pre-releases on snapshot. The GitHub releases on this repo are unchanged, so existing consumers keep working.

Changed

• The SPM distribution (smileidentity/kamera-spm) declares swift-tools-version: 6.0, so its stated floor is Swift 6.0+ (Xcode 16+), matching the v12 iOS SDK's ios-spm package that every consumer of it also resolves. iOS 15.0+ is unchanged.

• Platform floors follow the v12 SDKs: Kotlin 2.4.10 on Android, Flutter 3.41+ for usesmileid_kamera, and React 19.2+ / React Native 0.83+ for @smileid/kamera. (#77)

• Publishing is now one workflow per platform — publish-android.yaml, publish-ios.yaml, publish-flutter.yaml, publish-expo.yaml — the way each Smile ID SDK repo owns its own publish.yaml. release.yml and snapshot.yml are gone; republishing one platform no longer reruns the other three. Android and iOS each take a channel input (release or snapshot); Flutter and Expo are release-only, as they already were.

  Order matters and nothing enforces it: run publish-ios first (it cuts the GitHub Release), then publish-android, then the wrappers — they vendor the xcframeworks from that release by version and wait on Maven Central. The old single workflow cut the tag last, only once every platform had published, so this trades that atomicity for independence.

• Flutter (kamera) and React Native (@smileid/kamera) wrapper snapshots are no longer published to pub.dev / npm from snapshot.yml; the v12 Flutter/RN SDKs consume the wrappers directly from a branch of this repo (kamera-flutter/, kamera-react-native/). Android (-SNAPSHOT on Maven Central) and iOS (prerelease xcframework Release) snapshots are unchanged. Registry publishing is blocked — Flutter's 0.1.0-SNAPSHOT.N is semver-below the published stable kamera 0.1.0, and the CI npm token lacks publish rights for @smileid/kamera.

• Published packages now hide their implementation (design 27): the Android AAR ships with com.usesmileid.kamera.internal.* obfuscated by R8 (public API kept); the iOS xcframework is built with local symbols stripped and no dSYM bundled; and the React Native package publishes a minified dist/ bundle instead of raw source (the codegen spec files stay readable, as RN codegen requires). dSYMs are never shipped in any package.

Fixed

• Flutter (usesmileid_kamera) and React Native (@smileid/kamera) on iOS: leaving a capture screen no longer starves every later flow of frames. The wrappers attached the frame collector behind a one-shot guard, and release() — which a host calls on leaving a capture screen — finished the stream without clearing that guard, so nothing re-attached on the next start() and every analyzer tick got no frame for the rest of the process: the first flow worked, and every later one — a second verification, or a passport's back side after its front — never received a frame. Android was unaffected. (#79)

• Android: KameraSession.release() is now terminal — a start() issued after it is a no-op. Release already shut the analysis executor down, so a restarted session could never serve frames, but it did re-register the thermal status listener. That listener is a binder stub the system holds as a JNI global root, and the matching unregister only runs inside release(), so a start arriving after release left one nothing would ever remove — pinning the session and, through its lifecycleOwner, the host that constructed it. Hosts that tear the camera down while a start is still in flight saw a leaked activity per capture screen.

• React Native (@smileid/kamera) on Android: the preview no longer renders black. The view manager attached the session to a preview view only at createViewInstance, but React mounts the view while rendering the tree — normally before JS calls start() — so on the common ordering there was no session to attach and nothing to attach it later. The same gap broke the second flow on a screen that survives a release()/start() cycle: the view stayed bound to the released session. Every mounted preview view is now tracked (weakly, so a dropped view cannot leak its activity) and attached whenever a session becomes current, so mount-before-start, start-before-mount, and repeated sessions all end with a live preview.

• React Native (@smileid/kamera): the generated TurboModule spec now lands in the package KameraModule imports. codegenConfig.android.javaPackageName was only honoured by the Gradle plugin, not by the CLI behind npm run codegen:android — which has no such flag — so the two codegen paths emitted NativeKameraSpec into different packages and a consumer build failed with Unresolved reference 'NativeKameraSpec'. Dropping the override puts both on React Native's default com.facebook.fbreact.specs, which is what the committed tree and the import already used.

• React Native (@smileid/kamera): a consuming app on the new architecture can now configure CMake. The Android glue declares codegenConfig, so autolinking always emits add_subdirectory(<lib>/android/build/generated/source/codegen/jni) and links react_codegen_KameraSpec — but nothing generated that directory, because the glue applied only com.android.library. Every native Android build failed at configure with "not an existing directory", then "Cannot specify link libraries for target react_codegen_KameraSpec which is not built by this project". The glue now applies com.facebook.react when it is on the classpath, so the spec is generated against the consumer's own React Native version. The node-free standalone glue build is unaffected — the plugin is absent there and the committed codegen still serves it.

• Flutter (kamera_testing): an app using the replay kit alongside kamera can now resolve its Swift packages. Both packages declared a binary target named Kamera, and SPM requires target names to be unique across the whole package graph, so resolution failed outright with "multiple packages ('kamera', 'kamera_testing') declare targets with a conflicting name: 'Kamera'". The test kit no longer declares one: its glue needs no Kamera symbol (KameraReplay and FixtureRegistry are KameraTesting's own API), and KameraTesting's link-time dependency resolves against the copy kamera vends. fetch_xcframeworks.sh for the test kit now needs only KameraTesting.

• The published Flutter (kamera) and React Native (@smileid/kamera) wrappers now resolve their native -SNAPSHOT dependency from the Maven Central snapshots repo. In -SNAPSHOT mode the Android glue injected only mavenLocal() into the host build, so an external consumer of the published wrapper tried to resolve com.usesmileid:kamera:<x.y.z-SNAPSHOT> from an empty ~/.m2 and the build failed; the snapshots repo (where snapshot.yml publishes the artifacts) is now injected alongside mavenLocal.

0.1.0

• Initial pre-release of the kamera camera SDK, published in lockstep across Android, iOS, Flutter, and React Native.