Saltar para o conteúdo principal
Um SDK para iOS leve e orientado pelo servidor, para verificação de identidade com configuração mínima. Versão mais recente: 4.13.2.

Repositório no GitHub

Veja o código-fonte, as versões e o registo de alterações completo no GitHub

SDK nativo: Esta é a abordagem recomendada para aplicações iOS. Os SDKs nativos oferecem a melhor experiência do utilizador, uma gestão da câmara otimizada e suporte NFC completo.


Requisitos

Compatibilidade com versões do iOS

O consentimento biométrico requer o SDK nativo 4.10.0 ou posterior. Para pessoas abrangidas pela lei do Illinois, do Texas ou do Colorado, a Didit pode pedir um consentimento biométrico explícito antes da primeira captura facial. O SDK para iOS 4.10.0 e versões posteriores apresentam esse passo. As versões anteriores não o conseguem apresentar: as sessões são executadas como antes, e a decisão indica que o consentimento não foi recolhido (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize a versão se verificar pessoas nesses estados.

Instalação

Desde 4.0.0, o SDK é distribuído em várias variantes instaláveis, para que a sua aplicação só pague o custo binário das funcionalidades que usa. Escolha exatamente uma variante: um subspec do CocoaPods e um produto de biblioteca do SwiftPM.
  • Core: o tamanho mais reduzido, com captura automática de documento e selfie através dos detetores leves da própria Didit. Sem OpenSSL.xcframework e sem runtime do CoreNFC.
  • AutoDetection: obsoleta desde a 4.11.0 e idêntica à Core; use a Core em vez desta.
  • NFC: a Core mais a leitura do chip de passaportes e eID por NFC.
  • All — todas as funcionalidades. É a predefinição quando instala o DiditSDK sem indicar um subspec ou produto.
O que cada variante acrescenta ao pacote da sua aplicação (Mach-O arm64, medido com a 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 modelos de deteção são transferidos em tempo de execução e ficam em cache, pelo que nunca contam para o tamanho de transferência da sua aplicação. Desde a 4.11.0, a captura automática funciona com os detetores leves da própria Didit em todas as variantes. O TensorFlow Lite deixou de fazer parte do SDK, e a framework ficou mais pequena porque as traduções são carregadas a partir do exterior do binário. Desde a 4.6.0, as frameworks distribuídas deixaram de incluir os descritores ABI do Swift (metadados de compilação que o Xcode copiava para todas as aplicações, mas nunca lia) e os vídeos tutoriais que a variante não consegue reproduzir. Ao atualizar a partir da 4.5.4 ou de versões anteriores, a sua aplicação fica cerca de 7-8 MB mais pequena só por esse motivo, sem alterações de código. A App Store comprime os binários para distribuição, pelo que o custo de transferência sem fios é inferior. 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 através do NFCPassportReader), necessário para a autenticação do chip NFC, e requerem iOS 15.0+. As versões até à 4.0.6 inclusive incluíam o OpenSSL 1.1.1s; as 4.0.7 e posteriores distribuem o OpenSSL 3.3.3 com o seu próprio manifesto de privacidade e assinatura de código. Instale sempre a 4.0.7 ou posterior. 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 ficheiro, mesmo bundle id com.github.krzyzanowskim.OpenSSL), as duas cópias entram em conflito no passo de embed, independentemente da versão. Mantenha apenas uma cópia; por exemplo, substitua o outro pacote, através da respetiva identidade SPM, para utilizar o OpenSSL.xcframework publicado pela Didit, de forma a que o binário incluído na aplicação seja o mesmo contra o qual este SDK foi compilado. As variantes Core e AutoDetection não fazem qualquer ligação ao OpenSSL.
import DiditSDK é igual no código da sua aplicação, independentemente da variante instalada.

Swift Package Manager (recomendado)

Adicione o pacote ao seu projeto através do Xcode:
  1. Aceda a File > Add Package Dependencies
  2. Introduza o URL do repositório:
  1. Selecione a versão (ou Up to Next Major a partir da 4.13.2) e clique em Add Package
  2. Quando lhe for pedido para escolher um produto, selecione exatamente um produto de biblioteca para a sua variante (consulte 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 si. O Package.swift declara platforms: [.iOS(.v13)] para o pacote inteiro, pelo que o Xcode permite adicionar o DiditSDK ou o DiditSDKNFC a um target iOS 13 ou 14 sem qualquer aviso. No entanto, ambos incluem o OpenSSL.xcframework e leem os chips através do NFCPassportReader, que requerem iOS 15.0+. Defina você próprio o deployment target do target como 15.0 ao usar o produto All ou NFC. O CocoaPods aplica isto automaticamente através do deployment_target do subspec.

CocoaPods

O DiditSDK é distribuído como um podspec binário alojado no repositório (não está no CocoaPods Trunk público), pelo que tem de referenciar o URL do podspec. Escolha exatamente um subspec:
As variantes Core e AutoDetection funcionam a partir do iOS 13; NFC e All requerem iOS 15 por causa do NFCPassportReader. Em seguida, execute:
Após o pod install, abra o .xcworkspace gerado (e não o .xcodeproj).
Erros de rsync no Xcode 15+: se vir erros de rsync Operation not permitted durante a compilação, defina Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) como Não no projeto, tanto para Debug como para Release.

Manual (XCFramework)

Cada versão publica um XCFramework por variante. Transfira os zips da sua variante a partir das GitHub Releases, arraste as pastas .xcframework para o Xcode e defina Embed & Sign.

Permissões

O SDK requer as seguintes permissões. Adicione-as ao ficheiro Info.plist da sua aplicação:

Exemplos de entradas do Info.plist

Configuração de NFC

Necessário apenas ao instalar a variante NFC ou All. Ignore esta secção se tiver instalado a variante Core ou AutoDetection. Para ativar a leitura NFC de passaportes e cartões de identificação com chip:
  1. Adicione a capacidade NFC no Xcode:
    • Selecione o seu alvo → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
  2. Adicione os identificadores ISO7816 ao Info.plist:
D392F000260100000001 permite ao SDK ler o Cartão My Number do Japão através do JPKI: sem ele, o iOS não comunica o cartão ao SDK. A leitura do Cartão My Number ainda não está ativada em produção, e o identificador não altera nada para os outros documentos, pelo que pode adicioná-lo desde já.
  1. Adicione os direitos (entitlements) (no seu ficheiro .entitlements):
Limitação do simulador (variantes NFC e All): Estas variantes fazem ligação ao CoreNFC e, desde o Xcode 12, o libnfshared.dylib está em falta nos simuladores. Consulte esta publicação do Stack Overflow para uma solução alternativa. Isto não se aplica às variantes Core ou AutoDetection. Teste as funcionalidades NFC apenas em dispositivos físicos.

Revisão na App Store (variantes NFC e All): Se instalar a variante NFC ou All, a Apple pode pedir um vídeo de demonstração durante a revisão, porque o código relacionado com NFC faz parte do binário do SDK, mesmo que o seu fluxo não use NFC. Peça o nosso vídeo de demonstração NFC para submeter à Apple através de support@didit.me. Isto não se aplica às variantes Core ou AutoDetection.


Início rápido

Integração com SwiftUI

Integração com UIKit


Métodos de integração

O SDK suporta dois métodos de integração: Não requer backend. O SDK cria a sessão diretamente com o ID do seu fluxo de verificação obtido na Didit Console. O método UniLink (startVerification(workflowId:)) suporta apenas vendorData; para quaisquer outros parâmetros de sessão, use o Método 2.
Para que o vendorData seja associado à sessão através do UniLink, ative a opção Dados do fornecedor na Didit Console.

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

O seu backend cria a sessão através da API de criação de sessão de verificação (POST /v3/session/), com suporte completo de parâmetros (contact_details, expected_details, metadata, callback, etc.), e depois transmite o session_token ao SDK.
Esta abordagem oferece-lhe controlo total sobre:
  • Associar sessões aos seus utilizadores (vendor_data)
  • Definir os dados de contacto e os dados esperados para validação cruzada
  • Definir metadados personalizados
  • Configurar os callbacks por sessão
Estes dados (dados de contacto, dados esperados, metadados, callback) são enviados para a 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 da câmara

As opções de câmara correspondem às opções de câmara do Web SDK. Cada objetiva é .front ou .back. Se o dispositivo não tiver a objetiva pedida, o SDK usa a primeira câmara que tiver. O seletor de câmara também fica oculto em dispositivos que têm apenas uma câmara. Defina uma opção de seletor como false para impedir o utilizador de mudar da objetiva predefinida desse passo.
Tema e cores: As cores, os fundos e as definições do ecrã de introdução são configurados nas suas definições de marca branca na Didit Console, e não na configuração do SDK. Isto 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 dispositivos móveis languageLocale e fontFamily existem porque o SDK para dispositivos móveis apresenta a interface completa de verificação de forma nativa (ao contrário do Web SDK, que delega no frontend alojado dentro de um iframe).

Suporte de idiomas

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

Parâmetros avançados da sessão

Para parâmetros avançados da sessão (contact_details, expected_details, metadata, callback), use o método Backend Session. O seu backend chama a API para criar sessões de verificação com todos os parâmetros e, depois, transmite o session_token ao SDK.

Tratamento dos resultados

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

Casos de resultado

Propriedades de SessionData

Tipos de erro

Ligação perdida

Se o dispositivo perder a ligação durante a verificação, o SDK apresenta um ecrã “Sem ligação à Internet” sobre o fluxo, em vez de deixar um passo a carregar. Continua a verificar em segundo plano e fecha o ecrã automaticamente assim que for possível voltar a contactar a Didit, e o utilizador continua a partir do passo em que estava. O ecrã oferece Tentar novamente e, quando showCloseButton é true (o valor predefinido), Sair da verificação. Ao sair, a verificação termina com .failed(error: .networkError, session:), para que a sua app saiba que o utilizador saiu por causa da ligação.

Exemplo completo de tratamento de resultados


Encerrar a verificação programaticamente

Disponível no DiditSDK 3.6.0+.
A aplicação hospedeira pode terminar uma verificação ativa de forma programática com DiditSdk.shared.dismiss(). Esta é a forma recomendada de encerrar a verificação quando a aplicação precisa de assumir o ecrã, por exemplo, quando passa para segundo plano.
dismiss() segue o pipeline de conclusão normal do SDK: fecha a interface apresentada, repõe o estado interno e invoca o handler .diditVerification com .cancelled(session:), que transporta o sessionId atual, se tiver sido criada uma sessão. Não tem efeito quando não há nenhuma verificação ativa.

Exemplo: encerrar quando a aplicação passa para segundo plano

Não defina DiditSdk.shared.isPresented = false para encerrar a verificação: a flag só desencadeia a apresentação na sua transição ascendente, e defini-la como false não tem efeito. Do mesmo modo, chamar dismiss(animated:) do UIKit no controlador de vista superior não é suportado: contorna o pipeline de conclusão do SDK, pelo que o seu handler .diditVerification nunca é acionado.

Observar o estado do SDK

Pode observar o estado do SDK para criar uma interface de carregamento personalizada:

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

Este padrão é a integração pronta para produção. O seu backend cria a sessão, a aplicação 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 através de webhook

O resultado do SDK é útil para o feedback na interface, mas o resultado definitivo chega por webhook. Consulte o Guia de webhooks para a verificação HMAC.

Exemplo completo em SwiftUI


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