# SDKs mobile e web

Source: https://help.didit.me/pt-BR/integration/mobile-sdks
Updated: 2026-10-12

Há SDKs nativos para iOS, Android, React Native e Flutter, e SDKs web. Use um nativo para NFC ou melhor câmera; os resultados continuam chegando por webhook.

Existem SDKs nativos para **iOS, Android, React Native e Flutter**; os SDKs web
incorporam o fluxo no seu frontend. Use um SDK nativo quando precisar de **NFC** ou
do melhor comportamento de câmera - uma WebView não oferece nenhum dos dois. Os
resultados continuam chegando por webhook, não pelo SDK.

## Por que um SDK em vez de um redirecionamento

[Video: O guia completo de integração - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

Um redirecionamento hospedado é o caminho com menos trabalho e funciona bem para a maioria dos fluxos. Um SDK vale a pena quando:

- **Você precisa de NFC.** O chip de um passaporte ou documento de identidade não pode ser lido a partir de uma página de navegador. Um SDK nativo é o único caminho. Veja [verificação de chip NFC](https://help.didit.me/pt-BR/documents-coverage/nfc-chip-verification).
- **Você não quer que o usuário saia do seu app.** Um redirecionamento para fora e de volta é um ponto real de abandono no mobile.
- **Você quer o melhor comportamento de câmera.** O acesso nativo à câmera é mais confiável do que o de um navegador, principalmente em dispositivos mais antigos.

## O que está disponível

[Video: Escolha o SDK do Didit certo - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| Plataforma | Observações |
|---|---|
| **iOS** | Distribuído como um XCFramework |
| **Android** | Distribuído via Maven |
| **React Native** | Encapsula os módulos nativos; suporta a New Architecture |
| **Flutter** | Encapsula os módulos nativos |
| **JavaScript / web** | Incorpora o fluxo hospedado no seu frontend web |
| **Iframe in-context** | Renderiza o fluxo dentro da sua página em vez de redirecionar |

![A página Integrar no console da Didit com os links de SDK e documentação](https://help.didit.me/screenshots/integrate-light.webp)

*Todo SDK começa a partir da mesma página que a API.*

iOS oferece Swift Package Manager e CocoaPods; adicione permissões de câmera e NFC ao `Info.plist` quando necessário. Android usa Maven. React Native suporta Expo por uma compilação de desenvolvimento com módulos nativos, não pelo Expo Go.

Os requisitos de versão e os mínimos de plataforma mudam a cada lançamento, então verifique a [documentação atual do SDK](https://docs.didit.me/integration/native-sdks/overview) em vez de confiar em um retrato desta página - e se você está usando uma versão específica de framework (uma versão particular do Expo SDK, por exemplo), confirme a compatibilidade com o seu contato na Didit antes de se comprometer com isso em uma sprint.

## Uma WebView não é um SDK nativo

Envolver o fluxo web hospedado em uma WebView parece dar a você uma experiência dentro do app. Na verdade, dá apenas a aparência de uma:

- **Sem NFC.** O chip continua não podendo ser lido.
- **Permissões de câmera são mais difíceis.** O acesso à câmera de uma WebView depende da configuração do app hospedeiro, e errar nisso produz exatamente os relatos de "a câmera nunca abriu" cobertos em [corrigindo problemas de liveness e reconhecimento facial](https://help.didit.me/pt-BR/liveness-biometrics/liveness-and-face-match-issues).
- **O idioma é o do app, não o do usuário.** Uma WebView informa o idioma do app hospedeiro, então passe `language` explicitamente ao criar a sessão. Veja [definindo o idioma da verificação](https://help.didit.me/pt-BR/workflows/verification-languages).

Se você vai ter o trabalho de fazer um fluxo dentro do app, use o SDK nativo.

## Os resultados ainda vêm de webhooks

Isso costuma pegar as pessoas de surpresa: o SDK informa ao seu app que o usuário concluiu o fluxo. Ele **não** é a fonte definitiva da decisão de verificação.

A decisão é produzida no lado do servidor depois que as verificações são executadas, e chega até você por [webhook](https://help.didit.me/pt-BR/integration/webhooks-basics). Nunca conceda acesso com base apenas no callback de conclusão do SDK - um sinal do lado do cliente é trivialmente falsificável, e as verificações podem nem ter terminado quando ele dispara.

> **Warning:** Tratar "o SDK disse que terminou" como "o usuário está verificado" é o erro mais
> grave possível em uma integração mobile. Confirme no seu servidor, a partir do
> webhook ou do endpoint de decisão, antes de liberar qualquer coisa.

## Um app do consumidor, ou o seu próprio?

Não existe um app separado da Didit para o consumidor final para o qual uma sessão hospedada transfira os usuários em uma etapa como o NFC. Se você quer tudo - NFC e não NFC - dentro de uma única experiência de app, esse app é o **seu**, com o SDK incorporado nele.

## Distribuição e conflitos de dependência

A integração do SDK nativo ocasionalmente entra em conflito com outras dependências em um app hospedeiro - uma biblioteca transitiva compartilhada, ou um subspec que fixa uma versão que outra coisa também fixa. Se isso acontecer, é um problema concreto e reproduzível que vale a pena reportar junto com o seu manifesto de dependências, em vez de contornar fixando algo antigo: a correção geralmente pertence ao SDK.

## Testando em um dispositivo

Mude para **Sandbox** no seletor abaixo do nome da aplicação, crie uma chave de API de teste e use-a. As verificações são simuladas, sem cobrança, e você escolhe o resultado.

[testes no sandbox](https://help.didit.me/pt-BR/getting-started/sandbox-and-testing)