# iOS SDK

The iOS SDK initialization much depends on the mode your dashboard operates on. Use the documention below only if your dashbord is still in Flows/Levels mode, otherwise please refer to the main documentation.

# Backend routines

In order to embed our MobileSDK you have to complete a couple of preparation steps on your backend and use the results to pass into the MobileSDK initialization:

# Step 1: Applicant Flow

Set up your applicant flow or pick a predefined one (e.g. msdk-basic-kyc) in the dashboard

# Step 2: Access Token

Generate an access token that is associated with the externalUserId - a user id in your system. This is needed for constraining the access token to only one applicant.

curl -X POST \
  'https://test-api.sumsub.com/resources/accessTokens?userId=SomeUserIdInYourSystem&ttlInSecs=600' \
    -H 'Accept: application/json'

# Step 3: All done!

Now you can initialize the Mobile SDK.

# Initialization

# Regular Flow

First of all, import the framework:

import IdensicMobileSDK

Then declare the initialization parameters:

let baseUrl = "https://test-api.sumsub.com" // or "https://api.sumsub.com" for production
let flowName = "msdk-basic-kyc" // the name of the applicant flow (must be set up via the dashboard)
let accessToken = "..." // use the `accessToken` for the applicant to be verified got from your backend
let locale = Locale.current.identifier // locale in the form of "en" or "en_US"
let supportEmail = "[email protected]" // optional support email

While baseUrl, flowName and accessToken are mandatory, locale and supportEmail are optional

If you do not provide locale, the current one will be used automatically
Setting supportEmail is just a convenient way to configure the Support screen; it's ok to set it to nil and configure Support Items later on.

Next you instantiate SNSMobileSDK and check if setup succeeded:

let sdk = SNSMobileSDK(
    baseUrl: baseUrl,
    flowName: flowName,
    accessToken: accessToken,
    locale: locale,
    supportEmail: supportEmail
)

guard sdk.isReady else {
    print("Initialization failed: " + sdk.verboseStatus)
    return
}

Here you create an instance of the SDK and ensure that the setup was successful with sdk.isReady, if it happens to fail, you will be able to pinpoint the reason by printing sdk.verboseStatus.

The next important step is to set the tokenExpirationHandler. The matter is that typically the access token is valid for a rather short period of time and when it's expired you must provide another one (see Token Expiration for details).

sdk.tokenExpirationHandler { (onComplete) in
    get_token_from_your_backend { (newToken) in
        onComplete(newToken)
    }
}

Most likely, you will then tune up the sdk a bit further by assigning Handlers and Callbacks, and possibly by applying some Customization, but that's just an optional feature.

We know that the requirement to provide the accessToken as one of the initialization parameters forces you to ask your backend and due to the async nature of this process you'll have to build some UI around. For your convenience, it's possible to postpone the provision of the token until the sdk has been presented. To do so, you will need to pass an empty string as the accessToken at the initialization stage. This way the tokenExpirationHandler will be called immediately after the sdk is appeared up at the time when an activity indicator is displayed.

# Action Flow

In order to run the SDK in applicant action mode, you need to create an applicant flow of Applicant actions type in the dashboard and specify its name as the flowName initialization parameter. Also, it'll be required to make an Access Token not only with the userId parameter, but with the externalActionId one as well.

Aside from the notes above, you manage the sdk the same way that you do with regular flows, the only difference is in how you get the action's result (please see the main documentation for further details).