KMM iOS-liveness-sdk-plugin

Overview

We recommend integrating the standard native SDK directly, following the integration documentation provided for iOS platform.

Why should we integrate the standard native SDK instead of the SDK wrapped by the KMM multi platform library? There are several reasons:

  1. The code rules and architecture of KMM require that native UI-related parts should be handled separately in each native platform of the code, while the Liveness SDK is strongly related to the native UI part.

    • On the Android side, the Liveness SDK page depends on native Activity.
    • On the iOS side, the Liveness SDK page depends on native ViewController.
    • On the KMM multi platform library side the appropriate Activity and ViewController cannot be obtained. Moreover, if the iOS app is implemented using pure SwiftUI, additional code must be added on the Swift side to display the SDK page. This makes wrap the SDK into a KMM multi platform library even less meaningful.
  2. After the Liveness SDK is finished, the app usually processes the response on the UI according to the result of the Liveness SDK (success or failure). Therefore, this part of the code also needs to be implemented separately in each native platform (because it is related to the UI).

  3. In fact, the Liveness SDK itself has almost no additional logic that can be separated and included in the KMM shared moudle.

  4. KMM's support for CocoaPods is not very good, and even has some bugs. In order to allow KMM to integrate the iOS SDK by configure build.gradle.kts, some workarounds have to be made. These workarounds make it complicated to integrate the iOS SDK, whereas integrating the native iOS SDK directly is much easier.

In summary, the Liveness SDK is not suitable for or cannot be fully wrapped into the multi-platform library required by KMM, and direct integration of native SDK is more appropriate.

Nevertheless, we still try to wrap the native SDK to allow the APIs of the native SDK to be called on the kotlin side, and provide a demo project for reference only. The native SDK on the Android side does not need to do additional processing, since it is language matching, KMM can call the APIs of the SDK directly, but the iOS side needs to do extra processing, and then the KMM side can call the iOS native SDK API in the kotlin way.

Please note that the following configurations apply only to the iOS side.

  1. Add the pod dependencies configuration to build.gradle.kts in the shared folder:

  2. Add the following configuration to the Podfile of the iOS native project(iosApp/Podfile) to solve the strange issue that the pod module cannot be found:

    We test found that if you only add the pod configuration in build.gradle.kts, the pod modules AAINetwork, AAILivenessUI, AAILivenessSDK cannot be found correctly during compilation, but if you configure it again in the Podfile, this issue will be resolved.

  3. Add the swift codes to initialize and display the SDK page in your iOS project:

  4. Add relevant kotlin codes(LivenessSDK and LivenessSDKManager), refer to the demo project for details.

iOS error code list

CodeExplanation
PREPARE_TIMEOUTTimeout during the preparation stage
ACTION_TIMEOUTTimeout during the motion stage
MUTI_FACEMultiple faces detected during the motion stage
FACE_MISSINGFace is missing during the motion stage
MUCH_ACTIONMultiple motions detected during the motion stage
USER_GIVE_UPThe user clicked the top left back button during the detection process
NO_RESPONSENetwork request failed
UNDEFINEDOther undefined errors
...(Other server side error codes)/

How to upgrade the plugin?

  1. Download the latest demo project and replace the old podDependencies folder of your project with podDependencies folder from the demo project.
  2. Delete your Podfile.lock of your iOS project.
  3. Go to your iOS project root path then run pod install.