iOS - Getting Started¶

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

This guide directs a developer integrating the SDK through all necessary steps: 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 depend on the Core Module; therefore, the Core Module must be added and configured before any other module is used. Additionally, each module can be integrated independently, allowing you to include only the capabilities your flow requires.

Each module page begins with module-specific topics; the shared behavior described in the Core Module section is applicable 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 install necessary dependencies using CocoaPods.

• CocoaPods — after configuring access to the private repo with an RSA key, reference the module from a private 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-install build settings (distribution build, code signing, valid architectures, deployment target) described in the Core Module section, and — for the simulator build — remove the linker flags listed there.

Overview of the Verification Flow¶

The SDK implements a two-step (fragmented) verification model compliant with regulations. The first phase is a Self-Service flow where the user independently completes the document, chip, and liveness steps. When required, the flow continues with a Video Call with a verification representative. If the representative is not immediately available, an appointment can be scheduled 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, validate 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 the OCR step.

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

• VideoCall — connect to a representative if necessary; 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 executed in sequence — token creation, session initialization, and settings retrieval — and if an active session exists, it is reused:

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

2. Session initialization — 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 token, session, and settings are managed by the SDK.

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

How to Use This Guide¶

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