SDKs móveis e web

Os SDKs nativos para iOS, Android, React Native e Flutter colocam o fluxo dentro da tua aplicação e são o único caminho que suporta NFC. Os SDKs web incorporam-no no teu frontend.

Escrito pelo suporte da Didit · Atualizado a 19 de agosto de 2026

#Porquê um SDK em vez de um redirecionamento

Um redirecionamento alojado é o que dá menos trabalho e é genuinamente adequado para a maioria dos fluxos. Um SDK vale a pena quando:

• Precisas de NFC. O chip de um passaporte ou cartão de identificação não pode ser lido a partir de uma página de navegador. Um SDK nativo é o único caminho. Consulta verificação de chip NFC.
• Não queres que o utilizador saia da tua aplicação. Um redirecionamento para fora e de volta é um verdadeiro ponto de abandono no telemóvel.
• Queres o melhor comportamento de câmara. O acesso nativo à câmara é mais fiável do que o de um navegador, especialmente em dispositivos mais antigos.

#O que está disponível

12

1. Escolhe a tua plataforma e a página dá-te o excerto de código dessa stack.
2. Os SDKs nativos e web, cada um com o seu próprio guia rápido, estão ligados aqui.

Os requisitos de versão e os mínimos de plataforma mudam com os lançamentos, por isso consulta a documentação atual do SDK em vez de uma captura de uma página de ajuda - e se estiveres numa versão de framework específica (um determinado SDK do Expo, por exemplo), confirma a compatibilidade com o teu contacto na Didit antes de te comprometeres com ela num sprint.

#Uma WebView não é um SDK nativo

Envolver o fluxo web alojado numa WebView parece dar-te uma experiência dentro da aplicação. Dá-te a aparência de uma:

• Sem NFC. O chip continua a não poder ser lido.
• As permissões de câmara são mais difíceis. O acesso à câmara de uma WebView depende da configuração da aplicação anfitriã, e configurá-lo mal produz exatamente os relatos de "a câmara nunca abriu" cobertos em corrigir problemas de prova de vida e correspondência facial.
• O idioma é o da aplicação, não o do utilizador. Uma WebView reporta o idioma da aplicação anfitriã, por isso passa language explicitamente ao criar a sessão. Consulta definir o idioma da verificação.

Se vais ao trabalho de criar um fluxo dentro da aplicação, usa o SDK nativo.

#Os resultados continuam a vir dos webhooks

Isto apanha muita gente desprevenida: o SDK diz à tua aplicação que o utilizador terminou o fluxo. Não é a fonte autoritativa da decisão de verificação.

A decisão é produzida no lado do servidor depois de as comprovações correrem, e chega até ti por webhook. Nunca concedas acesso apenas com base no callback de conclusão do SDK - um sinal do lado do cliente é trivialmente falsificável, e as comprovações podem nem sequer ter terminado quando ele dispara.

#Uma aplicação de consumidor única, ou a tua própria?

Não existe uma aplicação Didit de consumidor separada para a qual uma sessão alojada encaminhe os utilizadores para um passo como o NFC. Se quiseres tudo - NFC e não-NFC - dentro de uma única experiência de aplicação, essa aplicação é a tua, com o SDK incorporado nela.

#Distribuição e conflitos de dependências

A integração de um SDK nativo colide ocasionalmente com outras dependências numa aplicação anfitriã - uma biblioteca transitiva partilhada, ou uma subspec que fixa uma versão que outra coisa também fixa. Se encontrares um caso destes, é um problema concreto e reproduzível que vale a pena reportar com o teu manifesto de dependências, em vez de contornar fixando algo antigo: a correção normalmente pertence ao SDK.

#Testar num dispositivo

O sandbox funciona da mesma forma através de um SDK que em qualquer outro sítio - aponta a aplicação para a chave de uma aplicação sandbox e todas as comprovações são simuladas e não faturadas. É a forma certa de ensaiar um fluxo móvel, porque os comportamentos do SDK que mais precisas de testar (pedidos de permissão, ciclo de vida da câmara, colocar a aplicação em segundo plano a meio da captura) são comportamentos do dispositivo que não te custam nada exercitar repetidamente. Consulta testar em sandbox.