iOS - Getting Started¶

The EnQualify iOS SDK is an on-premises authentication tool that allows your application to perform regulatory-compliant KYC (Know Your Customer) and biometric verification flows directly on the device. It reads identity documents, verifies contactless chips, confirms the live presence of the document holder, and — when necessary — connects the customer to a live verification representative; all results are transmitted to your verification platform via an end-to-end encrypted channel.

This guide will walk a developer through all the necessary steps to integrate the SDK: overall architecture, prerequisites and minimum requirements, available installation methods, and end-to-end verification flow. Each module is then documented in its own section.

Architecture and Modules¶

The SDK has a modular architecture built on a single core: Core Module. All functional modules are linked to the Core Module; therefore, the Core Module must be added and configured before any other module can be used. Additionally, each module can be integrated independently; thus, you can include only the capabilities that your flow requires.

Each module page starts with topics specific to that module; the shared behavior described in the Core Module section applies to all modules and is not repeated.

Prerequisites and Minimum Requirements¶

Before integrating the SDK, ensure that your build environment and target project meet the following requirements.

Installation Options¶

The SDK can be added to your project in three ways. All three are documented in detail under the "Adding the SDK to the Project" heading in the Core Module section.

• Direct XCFramework embedding — add the core .xcframework files to your project (Embed and Sign) and load the required dependencies with CocoaPods.

• CocoaPods — after configuring private repo access with an RSA key, reference the module from a custom pod source in your Podfile.

• Swift Package Manager (SPM) — after configuring the necessary SSH key and host settings, add the private GitHub repository over SSH.

After installation, apply the post-installation build settings (distribution build, code signing, valid architectures, deployment target) described in the Core Module section and remove the linker flags listed there for the simulator build.

Overview of the Verification Flow¶

The SDK implements a regulatory-compliant two-step (fragmented) verification model. The first step is a Self-Service flow where the user completes the document, chip, and liveness steps independently. When required, the flow continues with a verification representative via Video Call. If a representative is not immediately available, an appointment can be created to schedule the conversation for a later date.

A typical end-to-end flow combines the modules in the following order:

• OCR — scan the front and back of the document, detect the document type, verify the hologram and other visual security elements, and read the MRZ.

• NFC — read the contactless chip using the document number, expiration date, and date of birth obtained during OCR.

• Face — perform liveness detection and compare the live face to the biometric photo from the document or chip.

• VideoCall — connect to a representative if needed; the representative may request a repeat of the OCR, NFC, or Face steps during the call.

Initialization Lifecycle¶

Each functional module follows the same initialization lifecycle. The API of each module is a singleton; thus, operations run on the same instance throughout the application session. When initialize is called, three steps are automatically performed sequentially — token creation, session initiation, and settings retrieval — and if there is an already active session, that is reused:

1. Token creation — if it fails, tokenCreateFailed is triggered.

2. Session initiation — if it fails, sessionAddFailed is triggered.

3. Settings retrieval — if it fails, settingsGetFailed is triggered.

When all three steps are successful, initializeCompleted is triggered with the name of the initialized module, and the module becomes ready to start operations. From that point on, the SDK manages the token, session, and settings.

Communication with the verification platform is secured at two layers: an SSL certificate (with optional pinning) protects against man-in-the-middle attacks; a Message Signature mechanism operating on a session basis signs each request with an RSA key that is regenerated for each session and is never stored within the SDK. Both layers are explained in the Core Module section.

How to Use This Guide¶

Start with the Core Module section to set up the foundation, certificates, and configurations. Then read the section of each module that your flow requires. Each module section contains an introduction, data models, a step-by-step implementation guide (“How Is the … Module Implemented?”) and a user guide reference including its functions and delegates. The UI Customization section explains how the SDK screens, colors, fonts, texts, and voice guidance can be configured from Backoffice without code changes.