Dos SDK móviles para un editor SaaS de e-commerce

El contexto

Un editor SaaS de personalización para comercio electrónico ofrecía su solución en la web y quería llevarla a las aplicaciones móviles de sus clientes — grandes cadenas de distribución. Lo que había que entregar no era, por tanto, una aplicación, sino un componente que otros equipos integran en la suya.

El reto

Un SDK no sigue las reglas de una aplicación. Nadie ve el código, y ese es justamente el problema: lo que los desarrolladores clientes sí ven es la superficie de la API, el mensaje de error a las 18 h de un viernes y el tiempo que tardan en entender cómo conectar aquello.

De ahí se derivaban tres restricciones:

1. La API pública es un compromiso. Una vez que una cadena ha integrado el SDK en su aplicación, cada cambio de firma se convierte en un coste para ella. Hay que acertar desde el principio.
2. No se controla la aplicación anfitriona. El SDK debe convivir con arquitecturas y versiones que no elegimos, sin imponer sus dependencias.
3. Dos plataformas, una sola coherencia. Un desarrollador iOS y uno Android deben encontrar los mismos conceptos, aunque el lenguaje sea distinto.

Lo que hicimos

• SDK Android, distribuido como biblioteca autónoma, con gestión explícita de las dependencias transitivas — el punto en el que una integración falla casi siempre primero.
• SDK iOS, distribuido vía Swift Package Manager, con una API pensada para reflejar la del SDK Android: mismos conceptos, mismos nombres, inicialización simétrica.
• Varios inicializadores, del más simple (una clave de API) al más completo (URL de servidor, entorno, registro de eventos). Caso simple inmediato, caso avanzado posible.
• Configuración multi-tenant y cambio entre producción y preproducción, para que los equipos clientes puedan probar sin tocar datos reales.
• Aplicaciones de demostración en UIKit en iOS y, en Android, tanto en vistas clásicas como en Jetpack Compose. Un integrador encuentra un ejemplo parecido a su propio código, sea cual sea la generación de arquitectura que use.
• Documentación de integración entregada con cada SDK.

El resultado

Dos SDK nativos entregados en paralelo, listos para ser integrados por los equipos técnicos de las cadenas clientes del editor.

En este tipo de encargo, la calidad se mide por una sola cosa: el número de preguntas que el integrador tiene que hacer antes de que funcione. Todo el trabajo de API, de nomenclatura simétrica y de ejemplos múltiples sirve para acercar ese número a cero.