Pular para o conteúdo principal
Um SDK para iOS leve e controlado pelo servidor para verificação de identidade, que exige o mínimo de configuração. Versão mais recente: 4.9.1.

Repositório no GitHub

Veja o código-fonte, as versões e o changelog completo no GitHub

SDK nativo: esta é a abordagem recomendada para apps iOS. Os SDKs nativos oferecem a melhor experiência do usuário, uso otimizado da câmera e suporte completo a NFC.


Requisitos

Compatibilidade com versões do iOS

O consentimento biométrico exige o SDK nativo 4.10.0 ou posterior. Para pessoas às quais se aplicam as leis de Illinois, Texas ou Colorado, a Didit pode solicitar consentimento biométrico explícito antes da primeira captura facial. O SDK para iOS 4.10.0 e posteriores exibe essa etapa. Versões anteriores não conseguem exibir a etapa: suas sessões funcionam como antes, e a decisão informa que o consentimento não foi coletado (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize se você verifica pessoas nesses estados.

Instalação

Desde a 4.0.0, o SDK é distribuído em quatro variantes instaláveis, para que sua aplicação só arque com o custo de binário dos recursos que usa. Escolha exatamente uma variante: um subspec do CocoaPods e um produto de biblioteca do SwiftPM:
  • Core: menor tamanho, apenas captura manual. Sem OpenSSL.xcframework, sem runtime do CoreNFC, sem runtime de ML.
  • AutoDetection: captura automática de documento e rosto baseada em ML, mas sem leitura de chip NFC.
  • NFC: leitura do chip NFC de passaporte/eID sem o runtime de ML da captura automática.
  • All: todos os recursos. É o padrão quando você instala o DiditSDK sem indicar um subspec/produto.
Quanto cada variante acrescenta ao bundle da sua aplicação (Mach-O arm64, medido na 4.9.0): Core ~11,1 MB, NFC ~11,7 MB mais ~4 MB de OpenSSL, AutoDetection ~16,0 MB, All ~16,6 MB mais OpenSSL. Os próprios modelos de detecção são baixados em tempo de execução e armazenados em cache, então nunca contam no tamanho de download da sua aplicação. Desde a 4.7.1, as variantes AutoDetection e All executam a inferência da captura automática em um runtime de ML mais enxuto, no lugar do runtime MediaPipe usado até a 4.6.0. Trata-se de uma transição, não de uma variante opcional: ela se aplica incondicionalmente a quem estiver na 4.7.1 ou posterior, portanto não existe uma variante separada com o “motor anterior” para instalar no lugar. Medido nos artefatos de release: -3,4 MB (-28%) no payload de download comprimido da App Store e -8,5 MB (-35%) no binário arm64 distribuído dentro da sua aplicação (o próprio framework descomprimido da fatia de dispositivo fica cerca de 12 MB menor). Antes do release, verifica-se que o comportamento de detecção é idêntico, quadro a quadro, ao do motor anterior em uma matriz de dispositivos físicos, e a inferência de documentos é mensuravelmente mais rápida.
Revertendo a mudança de runtime: como isso é uma transição e não uma variante, revertê-la significa fixar sua dependência na 4.6.0 (SwiftPM: selecione a versão 4.6.0 em vez de “Up to Next Major”; CocoaPods: aponte o podspec_url para a tag 4.6.0), e não alternar uma flag. A Didit acompanha o desempenho em campo desse runtime durante um ciclo de releases após o lançamento; se surgir uma regressão, a resposta será um aviso para fixar a versão anterior e um patch release no runtime atual, nunca uma troca de variante, já que ela não existe.
Desde a 4.6.0, os frameworks distribuídos não trazem mais descritores de ABI do Swift (metadados de build que o Xcode copiava para toda aplicação, mas nunca lia) nem vídeos tutoriais que a variante não consegue reproduzir. Só atualizar a partir da 4.5.4 ou anterior já reduz sua aplicação em cerca de 7-8 MB, sem nenhuma alteração de código. A App Store comprime os binários para a entrega, então o custo de download pela rede é menor. Consulte o relatório de tamanho da aplicação no App Store Connect para ver a diferença exata por dispositivo.
As variantes NFC e All incluem o OpenSSL.xcframework (OpenSSL 3.3.3, distribuído como OpenSSL-Universal 3.3.3001 via NFCPassportReader), necessário para a autenticação do chip NFC e que exige iOS 15.0+. Os releases até a 4.0.6, inclusive, incluíam o OpenSSL 1.1.1s; a 4.0.7 e posteriores trazem o OpenSSL 3.3.3 com seu próprio privacy manifest e assinatura de código. Instale sempre a 4.0.7 ou posterior. Observe que atualizar alinha as versões do OpenSSL, mas não elimina conflitos de embed: se outra dependência da sua aplicação também incorporar um OpenSSL.framework (mesmo nome de arquivo, mesmo bundle id com.github.krzyzanowskim.OpenSSL), as duas cópias entram em conflito na etapa de embed, independentemente da versão. Mantenha exatamente uma cópia: por exemplo, substitua o outro pacote usando a identidade do SPM para usar o OpenSSL.xcframework publicado pela Didit, de modo que o binário no bundle seja aquele com o qual este SDK foi compilado. As variantes Core e AutoDetection não vinculam nenhum OpenSSL.
O import DiditSDK no código da sua aplicação é o mesmo, seja qual for a variante instalada.

Swift Package Manager (recomendado)

Adicione o pacote ao seu projeto pelo Xcode:
  1. Acesse File > Add Package Dependencies
  2. Informe a URL do repositório:
  1. Selecione a versão (ou Up to Next Major a partir da 4.9.1) e clique em Add Package
  2. Quando for solicitado a escolher um produto, escolha exatamente um produto de biblioteca para a sua variante (veja a tabela acima)
Ou no seu Package.swift:
Em seguida, adicione exatamente um destes produtos ao seu target:
O Swift Package Manager não impõe o mínimo de iOS 15 por você. O Package.swift declara platforms: [.iOS(.v13)] para o pacote inteiro, então o Xcode permite adicionar DiditSDK ou DiditSDKNFC a um target de iOS 13 ou 14 sem reclamar, mas ambos incluem o OpenSSL.xcframework e leem chips por meio do NFCPassportReader, que exigem iOS 15.0+. Defina você mesmo o deployment target do seu target como 15.0 ao usar o produto All ou NFC. O CocoaPods impõe isso automaticamente por meio do deployment_target do subspec.

CocoaPods

O DiditSDK é distribuído como um podspec binário hospedado no repositório (ele não está no CocoaPods Trunk público), então você deve referenciar a URL do podspec. Escolha exatamente um subspec:
Core e AutoDetection funcionam a partir do iOS 13; NFC e All exigem iOS 15 por causa do NFCPassportReader. Depois, execute:
Após o pod install, abra o .xcworkspace gerado (não o .xcodeproj).
Erros de rsync no Xcode 15+: se aparecerem erros de rsync Operation not permitted durante o build, defina Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) como No no projeto, tanto para Debug quanto para Release.

Manual (XCFramework)

Cada versão publica um XCFramework por variante. Baixe os arquivos zip da sua variante na página GitHub Releases, depois arraste as pastas .xcframework para o Xcode e defina Embed & Sign.

Permissões

O SDK exige as permissões a seguir. Adicione-as ao Info.plist do seu app:

Exemplo de entradas no Info.plist

Configuração de NFC

Necessária apenas ao instalar a variante NFC ou All. Pule esta seção se você instalou a variante Core ou AutoDetection. Para habilitar a leitura NFC de passaportes e documentos de identidade com chip:
  1. Adicione a capability de NFC no Xcode:
    • Selecione seu target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
  2. Adicione os identificadores ISO7816 ao Info.plist:
D392F000260100000001 permite que o SDK leia o My Number Card do Japão por meio do JPKI: sem ele, o iOS não informa o SDK sobre o cartão. A leitura do My Number Card ainda não está habilitada em produção, e o identificador não altera nada para outros documentos, então você já pode adicioná-lo.
  1. Adicione os entitlements (no seu arquivo .entitlements):
Limitação do simulador (variantes NFC e All): essas variantes vinculam o CoreNFC e, desde o Xcode 12, o libnfshared.dylib não existe nos simuladores. Consulte esta discussão no Stack Overflow para uma solução alternativa. Isso não se aplica à variante Core nem à AutoDetection. Teste os recursos de NFC apenas em dispositivos físicos.

Revisão da App Store (variantes NFC e All): se você instalar a variante NFC ou All, a Apple pode solicitar um vídeo de demonstração durante a revisão, porque há código relacionado a NFC no binário do SDK — mesmo que seu fluxo de verificação (workflow) não use NFC. Solicite nosso vídeo de demonstração de NFC para enviar à Apple pelo support@didit.me. Isso não se aplica à variante Core nem à AutoDetection.


Início rápido

Integração com SwiftUI

Integração com UIKit


Métodos de integração

O SDK oferece dois métodos de integração: Não exige backend. O SDK cria a sessão diretamente usando o ID do fluxo obtido no Didit Console. O método UniLink (startVerification(workflowId:)) aceita apenas vendorData; para qualquer outro parâmetro de sessão, use o Método 2.
Para que o vendorData seja anexado à sessão via UniLink, habilite a opção Vendor Data no Didit Console.

Método 2: Sessão criada no backend (recomendado para produção)

Seu backend cria a sessão pela API de criação de sessão de verificação (POST /v3/session/) com suporte completo a parâmetros (contact_details, expected_details, metadata, callback etc.) e depois repassa o session_token ao SDK.
Essa abordagem dá a você controle total sobre:
  • A associação das sessões aos seus usuários (vendor_data)
  • A definição de dados de contato e dados esperados para validação cruzada
  • A definição de metadados personalizados
  • A configuração de callbacks por sessão Esses dados (dados de contato, dados esperados, metadados, callback) são enviados à API de criação de sessão de verificação.

Configuração

Personalize o comportamento do SDK com DiditSdk.Configuration:

Opções de configuração

Opções de câmera

As opções de câmera correspondem às opções de câmera do Web SDK. Cada lente é .front ou .back. Se o dispositivo não tiver a lente solicitada, o SDK usa a primeira câmera disponível. O seletor de câmera também fica oculto em dispositivos que têm apenas uma câmera. Defina uma opção de seletor como false para restringir o usuário à lente padrão daquela etapa.
Temas e cores: cores, fundos e configurações da tela de introdução são definidos nas suas configurações de marca própria no Didit Console, e não na configuração do SDK. Isso garante uma identidade visual consistente em todas as plataformas.
As opções showLanguageSelector, showCloseButton, showExitConfirmation e closeOnComplete correspondem ao DiditSdkConfiguration do Web SDK. As opções específicas para mobile languageLocale e fontFamily existem porque o SDK mobile renderiza toda a interface de verificação de forma nativa (diferentemente do Web SDK, que delega ao frontend hospedado dentro de um iframe).

Suporte a idiomas

O SDK oferece suporte a 54 idiomas. Se nenhum idioma for especificado, o SDK usa a idioma do dispositivo, com o inglês como alternativa.
Ver todos os idiomas suportados →

Parâmetros avançados de sessão

Para parâmetros avançados de sessão (contact_details, expected_details, metadata, callback), use o método Backend Session. Seu backend chama a API de criação de sessão de verificação com todos os parâmetros e, em seguida, passa o session_token ao SDK.

Tratamento de resultados

O enum VerificationResult fornece o resultado da verificação:

Casos de resultado

Propriedades de SessionData

Tipos de erro

Perda de conexão

Se o dispositivo perder a conexão durante a verificação, o SDK exibe uma tela de “Sem conexão com a internet”, em vez de deixar uma etapa carregando. Ele continua verificando em segundo plano e fecha a tela sozinho assim que a Didit volta a ficar acessível, e o usuário continua a partir da etapa em que estava. A tela oferece Tentar novamente e, quando showCloseButton é true (o padrão), Sair da verificação. Sair encerra a verificação com .failed(error: .networkError, session:), para que seu app saiba que o usuário saiu devido à perda de conexão.

Exemplo completo de tratamento de resultados


Encerrar a verificação programaticamente

Disponível no DiditSDK 3.6.0+.
O app host pode encerrar programaticamente uma verificação ativa com DiditSdk.shared.dismiss(). Essa é a forma recomendada de encerrar a verificação quando o host precisa assumir a tela, por exemplo, quando o app vai para segundo plano.
dismiss() passa pelo pipeline de conclusão normal do SDK: ele fecha a UI apresentada, redefine o estado interno e chama o handler .diditVerification com .cancelled(session:), com o sessionId atual se uma sessão tiver sido criada. Quando não há nenhuma verificação ativa, a chamada não tem efeito.

Exemplo: encerrar quando o app vai para segundo plano

Não defina DiditSdk.shared.isPresented = false para encerrar a verificação: o flag só dispara a apresentação na transição de falso para verdadeiro, e defini-lo como false não tem efeito. Da mesma forma, chamar o dismiss(animated:) do UIKit no view controller mais acima na hierarquia não é suportado: isso ignora o pipeline de conclusão do SDK, e o seu handler .diditVerification nunca é disparado.

Observando o estado do SDK

Você pode observar o estado do SDK para criar uma UI de carregamento personalizada:

Exemplo de ponta a ponta (sessão no backend → SDK iOS → resultado)

Esse padrão é a integração pronta para produção. O seu backend cria a sessão, o seu app iOS recebe o session_token e o SDK executa o fluxo.

1. Backend: criar a sessão

2. iOS: trocar o token e iniciar o SDK

3. Backend: receber a decisão final via webhook

O resultado do SDK é prático para dar retorno na UI, mas o resultado oficial chega via webhook. Consulte o guia de webhooks para a verificação HMAC.

Exemplo completo em SwiftUI


Última modificação em 1 de novembro de 2026