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 a4.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
DiditSDKsem indicar um subspec/produto.
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.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.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:- Acesse File > Add Package Dependencies
- Informe a URL do repositório:
- Selecione a versão (ou Up to Next Major a partir da
4.9.1) e clique em Add Package - Quando for solicitado a escolher um produto, escolha exatamente um produto de biblioteca para a sua variante (veja a tabela acima)
Package.swift:
CocoaPods
ODiditSDK é 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 aoInfo.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:-
Adicione a capability de NFC no Xcode:
- Selecione seu target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
-
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.
- Adicione os entitlements (no seu arquivo
.entitlements):
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:Método 1: UniLink (o mais simples)
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.
- 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 comDiditSdk.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.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 enumVerificationResult 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, quandoshowCloseButton é 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+.
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
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 osession_token e o SDK executa o fluxo.