SDKs mòbils i web

Els SDKs natius per a iOS, Android, React Native i Flutter integren el flux dins de la teva app i són l'única via compatible amb NFC. Els SDKs web l'incrusten al teu frontend.

Escrit pel suport de Didit · Actualitzat el 19 d’agost del 2026

#Per què un SDK i no una redirecció

Una redirecció allotjada és la que implica menys feina i, per a la majoria de fluxos, funciona prou bé. Un SDK val la pena quan:

• Necessites NFC. El xip d'un passaport o un document d'identitat no es pot llegir des d'una pàgina de navegador. Un SDK natiu és l'única via. Vegeu verificació amb xip NFC.
• No vols que l'usuari surti de la teva app. Una redirecció d'anada i tornada és un punt real d'abandonament en mòbil.
• Vols el millor comportament de càmera. L'accés natiu a la càmera és més fiable que el d'un navegador, especialment en dispositius més antics.

#Què hi ha disponible

12

1. Tria la teva plataforma i la pàgina et dona el fragment de codi per a aquella pila.
2. Aquí trobaràs els SDKs natius i web, cadascun amb el seu propi inici ràpid.

Els requisits de versió i els mínims de plataforma canvien amb cada llançament, així que consulta la documentació actual de l'SDK en lloc d'una instantània d'aquesta pàgina d'ajuda - i si fas servir una versió concreta d'un framework (una versió específica d'Expo, per exemple), confirma la compatibilitat amb el teu contacte a Didit abans de comprometre-t'hi dins d'un sprint.

#Un WebView no és un SDK natiu

Encapsular el flux web allotjat dins d'un WebView sembla que et doni una experiència dins de l'app. El que et dona és l'aparença d'una:

• Sense NFC. El xip continua sense poder-se llegir.
• Els permisos de càmera són més complicats. L'accés a la càmera d'un WebView depèn de la configuració de l'app amfitriona, i configurar-ho malament produeix exactament els reports de "la càmera mai s'ha obert" que es tracten a com solucionar problemes de prova de vida i coincidència facial.
• La llengua és la de l'app, no la de l'usuari. Un WebView informa de la llengua de l'app amfitriona, així que passa language explícitament en crear la sessió. Vegeu com configurar la llengua de verificació.

Si ja et prens la molèstia de fer un flux dins de l'app, fes servir l'SDK natiu.

#Els resultats sempre venen dels webhooks

Això sol confondre la gent: l'SDK indica a la teva app que l'usuari ha acabat el flux. No és la font autoritativa de la decisió de verificació.

La decisió es genera al servidor un cop s'han executat les comprovacions, i t'arriba per webhook. No concedeixis mai accés basant-te només en la crida de finalització de l'SDK - un senyal del costat del client es pot falsificar trivialment, i les comprovacions poden ni tan sols haver acabat quan es dispara.

#Una única app de consumidor, o la teva pròpia?

No hi ha cap app de consumidor separada de Didit a la qual una sessió allotjada traspassi els usuaris per a un pas com el NFC. Si vols tenir-ho tot - NFC i sense NFC - dins d'una única experiència d'app, aquesta app és la teva, amb l'SDK incrustat a dins.

#Distribució i conflictes de dependències

La integració de l'SDK natiu ocasionalment xoca amb altres dependències d'una app amfitriona - una biblioteca transitiva compartida, o un subspec que fixa una versió que una altra cosa també fixa. Si et trobes un cas així, és un problema concret i reproduïble que val la pena reportar amb el teu manifest de dependències, en lloc de buscar-hi una solució alternativa fixant alguna cosa antiga: l'arranjament sol pertànyer a l'SDK.

#Provar en un dispositiu

El sandbox funciona igual a través d'un SDK que en qualsevol altre lloc - apunta l'app a la clau d'una aplicació de sandbox i totes les comprovacions queden simulades i no es facturen. Aquesta és la manera correcta d'assajar un flux mòbil, perquè els comportaments de l'SDK que més necessites provar (avisos de permisos, cicle de vida de la càmera, passar a segon pla a mig de la captura) són comportaments del dispositiu que pots exercitar repetidament sense cap cost. Vegeu com provar en sandbox.