--- title: Best Practices description: Guidelines for integrating, updating, testing, and safely rolling out Unico's SDKs, including staging (UAT) security rules. canonical: https://developer.unico.io/developers/sdks-and-tools/best-practices-for-sdk-implementation locale: en generated_by: markdown-export --- - [/](/) - [SDKs and Tools](/developers/sdks-and-tools/overview) - Best Practices **On this page# Best Practices This page consolidates the most important guidelines for integrating and maintaining Unico's SDKs. Following these practices reduces integration errors, prevents security incidents, and ensures a smooth production rollout. ### Getting started​ Start from a reference app Unico offers a reference app for each SDK in the [reference-apps](https://github.com/unico-labs/reference-apps) repository. Each app implements the full user journey. Always keep your SDKs updated SDKs evolve continuously to deliver greater security and new features. Applying updates promptly — especially critical ones — is essential. See [Update Policy](/developers/sdks-and-tools/update-policy) for timelines and obligations. Identify the latest version available Check the current version for each platform through the respective release notes: [Android release notes](/developers/sdks-and-tools/android/resources/release-notes) [iOS release notes](/developers/sdks-and-tools/ios/resources/release-notes) [Flutter release notes](/developers/sdks-and-tools/flutter/resources/release-notes) [Web — Journeys SDK release notes](/developers/sdks-and-tools/web/resources/release-notes) ### Update strategy​ Avoid updating the SDK and other components simultaneously Your application likely loads multiple libraries alongside the Unico SDK. Upgrading several dependencies at once makes it difficult to identify the root cause of failures. Update the SDK in isolation and validate it in a [staging environment](#perform-tests-in-unicos-staging-environment) before combining it with other changes. Getting help with an SDK update When opening a support ticket for update issues, include: SDK language and implementation type (native or hybrid) Framework used Current version and target version API Key Description of the changes and steps to reproduce Results, errors, logs, screenshots, or videos ### JWT security​ Do not manipulate the JWT object Do not open or modify the encrypted JWTThe JWT returned after a successful capture is **encrypted**. Do not open, parse, or serialize it. Its internal structure may change without notice. Use it exclusively when submitting images to Unico's APIs. For image previews, use the Base64 attribute provided alongside the JWT — never decode the JWT itself. Send the JWT within 10 minutes warningFor security reasons, the JWT must be sent to Unico's backend within **10 minutes** of capture. Packages submitted after this window are invalidated. Send the JWT only once warningThe JWT must be submitted **only once**. If an error occurs during submission, a new biometric capture must be performed — do not reuse the same JWT. ### Testing guidelines​ Do not use virtualization or emulators Running the SDK in virtual machines or emulators triggers security error codes (`73006`, `73600`, `73400`). Always test on **physical devices** to avoid misidentifying errors and unnecessary rework. Do not keep DevTools open during web captures The Web SDK detects open DevTools as a potential fraud signal and invalidates the submission. Close DevTools before running end-to-end capture tests. ### Perform tests in Unico's staging environment​ Before going to production, run thorough tests in Unico's staging environment with realistic scenarios. Use staging-specific API Keys and configurations — never use production credentials in tests. IDCloud's staging (UAT) environment applies the **same security criteria as production**. The guidelines below explain why, and how to test without interruptions. What changed in staging **Before — detected, but did not refuse** Conditions outside the pattern of real-world usage were identified, but did not block the capture. **Now — detects and refuses** The same conditions now result in a liveness rejection, with the same strictness as production. Why this restriction exists **Fidelity — similarity with production** What passes in staging must behave the same way in production — preventing an integration approved in testing from failing unexpectedly after go-live. What you can and cannot do By testing under conditions close to real-world usage, the security layers do not impact your development. Development tooling that is not standard in the market triggers security validations, and the transaction may be blocked. ScenarioStatusRun the complete integration flow — capture, submission, API response, and return✅ AllowedTest functional scenarios: UI/UX, performance, business errors✅ AllowedUse a device in the standard configuration of an end user✅ AllowedIntegrate with backend, APIs, and data processing✅ AllowedUse a device with root/jailbreak❌ Not allowedKeep debug mode / USB debugging active❌ Not allowedUse emulators or virtualization❌ Not allowedUse virtual cameras or capture automation tools❌ Not allowedUse tools that alter the connection❌ Not allowedHave corporate MDM or active monitoring on the device❌ Not allowedUse a sandbox in a container or virtual machine❌ Not allowed Any of these conditions may result in a liveness rejection. Does your QA cycle depend on one of these conditions?Talk to the [support team](https://business.unico.io/hc/) for guidance on configuring your environment. There is no exception, one-off waiver, or temporary flexibilization — Unico keeps staging equalized with production for as long as it deems necessary. ### Platform-specific guidelines​ Flutter: use Unico's Flutter plugin Do not attempt to bridge the native Android or iOS SDKs inside a Flutter application. Native bridges frequently produce unmapped errors. Always use Unico's dedicated Flutter plugin. Web: delete old resource files when updating versions When upgrading the Web SDK, delete the old resource files from your `public` folder before inserting the new ones. Files with identical names will not be overwritten automatically and can cause version conflicts. Mobile: clear cache before building new versions Build artifacts from previous SDK versions can cause dependency errors after an update. Before building a new version: **Flutter:** delete `pubspec.lock` and run `flutter pub get` **iOS:** run `pod cache clean --all` and `pod install` **Android:** run `./gradlew clean` Obfuscation settings Exclude Unico SDK code from your obfuscation configuration. Obfuscating the SDK commonly causes failures in release builds that do not appear in debug builds. Refer to the platform-specific documentation for the required keep rules. ### UX and performance​ Separate the preparation and camera opening flow into two steps Structure the SDK flow into two distinct stages: **Prepare** — initialize the SDK while the page is loading (before user interaction). **Open** — launch the camera only when the user explicitly triggers the action. Preparing the SDK in advance reduces perceived latency and improves the user experience significantly. ### Production rollout​ Create a safe checklist for production rollout Before deploying to production, verify: Production API Keys and environment configurations are correct Rollback plan is defined and tested Log collection protocol is in place Support ticket procedures are documented for handling failures All validations passed in the staging environment Last updated on Oct 23, 2026**