¿Cómo evalúas un SDK de terceros antes de adoptarlo en tu app?
Un marco práctico de diligencia debida para decidir si un SDK de terceros vale el tamaño, la exposición de privacidad y el riesgo de proveedor que trae consigo.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo evalúas un SDK de terceros antes de adoptarlo en tu app?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Por qué esta pregunta trata de riesgo, no de funcionalidades
Cuando un entrevistador pregunta cómo evalúas un SDK de terceros, rara vez le interesa una checklist recitada de memoria. Quiere saber si tratas cada SDK como una pieza de tu propia cadena de suministro — código que no escribiste tú, que corre con los datos de tus usuarios, dentro de un binario que publicas bajo tu propia marca y del que eres responsable. Una respuesta senior trata "¿hace lo que necesitamos?" como necesario pero muy lejos de suficiente, y dedica la mayor parte del peso a las partes de la decisión que son caras de deshacer más adelante: exposición de privacidad, coste de rendimiento y qué tan difícil sería arrancar esa pieza si resulta ser un error.
#El encaje funcional es el mínimo, no la meta
Empiezo confirmando que el SDK de verdad resuelve el problema con el nivel de calidad que necesitamos — completitud de funciones, documentación, si la forma de su API encaja con cómo está estructurada nuestra app — pero intento pasar esa parte rápido, porque es justo lo que cualquier stakeholder que empuja el SDK ya se convenció de antemano. Las preguntas interesantes están un nivel más abajo: ¿funciona correctamente en las versiones de sistema operativo y los rangos de dispositivo que de verdad soportamos?, ¿maneja los estados offline y background de la forma que nuestra app necesita?, ¿su modelo de threading convive bien con el nuestro, o bloquea el hilo principal durante la inicialización de una forma que aparecerá como un ANR en un dispositivo de gama media aunque sea invisible en el flagship de la demo?
#La revisión técnica que se salta bajo presión de fecha límite
Antes de dar el visto bueno, quiero números concretos sobre el impacto en el tamaño del binario — un SDK "ligero" que añade varios megabytes y un puñado de dependencias transitivas que chocan con otras que ya usamos no es ligero — y quiero saber si hace su propio tráfico de red en segundo plano, porque un SDK que llama a casa por su cuenta según su propio calendario es un coste de batería y de datos que pagan nuestros usuarios se use o no la funcionalidad. También reviso su soporte mínimo de sistema operativo frente al nuestro, si tiene mantenimiento activo (releases recientes, capacidad de respuesta a issues abiertos, si el proveedor tiene un roadmap público), y si adoptarlo nos encierra en una versión concreta de alguna otra dependencia que no queremos congelar.
#Privacidad y seguridad no son una casilla al final
Esta es la parte que se ha vuelto mucho más determinante en los últimos años, y es donde he visto explotar en producción decisiones de SDK que por lo demás parecían sólidas. Quiero saber exactamente qué datos recolecta el SDK, si transmite algo fuera del dispositivo, y si esa recolección de datos tiene que declararse en el App Privacy manifest de iOS o en la sección Play Data Safety de Android — porque un desajuste entre lo que declaramos y lo que el SDK realmente hace es un riesgo real de rechazo en la tienda de apps, no algo teórico. Para cualquier cosa que toque PII, pagos o datos de salud, quiero ver la postura de cumplimiento del proveedor — SOC 2, términos de tratamiento de datos de GDPR — por escrito, no afirmada en una llamada de ventas.
#Envuélvelo, no te cases con él
La práctica de mayor apalancamiento que aplico en cualquier adopción de SDK es poner una interfaz propia, delgada, entre nuestro código y la API del proveedor — una fachada que expone solo el puñado de métodos que realmente llamamos. Cuesta una tarde de trabajo y significa que si el proveedor duplica el precio, es adquirido y descontinuado, o simplemente resulta ser la elección equivocada dentro de dieciocho meses, estamos cambiando una implementación detrás de una interfaz en lugar de cazar referencias al SDK del proveedor esparcidas en cuarenta archivos. Trato cualquier SDK que no se pueda envolver así de forma limpia — porque insiste en heredar de nuestra clase Application, o quiere quedarse con toda la capa de networking — como un compromiso mucho mayor, y valoro la decisión en consecuencia.
#Despliégalo como una funcionalidad, no como una actualización de dependencia
Incluso después de que el SDK supere todas las revisiones anteriores, entra detrás de un flag, se publica primero en builds internas y luego en una cohorte pequeña de producción, con dashboards vigilando la tasa de crashes, la tasa de ANR y el tamaño de la app antes de ampliar el despliegue. Ese despliegue escalonado es lo que convierte "hicimos la diligencia debida" en "atrapamos el problema antes de que llegara a todo el mundo", y al menos una vez me salvó de un SDK cuya llamada de inicialización estaba bien de forma aislada pero disparaba una condición de carrera contra otro SDK que ya vivía en la app.
🧠 Check your understanding
0/3 · 0/3 answered1. Un SDK de atribución pedido por marketing afirma añadir "menos de 1MB" a la app. ¿Qué es lo más importante que verificar antes de aprobarlo?
2. ¿Por qué envolver un SDK de terceros detrás de tu propia interfaz se considera la práctica de mayor apalancamiento al adoptarlo?
3. El comportamiento de un SDK no coincide con lo declarado en el App Privacy manifest de iOS o en la sección Play Data Safety de Android. ¿Cuál es el riesgo real?