Dois SDK móveis para uma editora SaaS de e-commerce

O contexto

Uma editora SaaS de personalização para e-commerce oferecia a sua solução na web e queria levá-la às aplicações móveis dos seus clientes — grandes cadeias de distribuição. O que havia a entregar não era, portanto, uma aplicação, mas um componente que outras equipas integram na sua.

O desafio

Um SDK não obedece às regras de uma aplicação. Ninguém vê o código, e é precisamente esse o problema: o que os programadores clientes veem é a superfície da API, a mensagem de erro às 18h de uma sexta-feira e o tempo que demoram a perceber como ligar aquilo.

Daí decorriam três restrições:

1. A API pública é um compromisso. Depois de uma cadeia integrar o SDK na sua aplicação, cada alteração de assinatura passa a ser um custo para ela. É preciso acertar desde o início.
2. Não se controla a aplicação anfitriã. O SDK tem de conviver com arquiteturas e versões que não escolhemos, sem impor as suas dependências.
3. Duas plataformas, uma só coerência. Um programador iOS e um programador Android têm de encontrar os mesmos conceitos, ainda que a linguagem seja diferente.

O que fizemos

• SDK Android, distribuído como biblioteca autónoma, com gestão explícita das dependências transitivas — o ponto onde uma integração falha quase sempre em primeiro lugar.
• SDK iOS, distribuído via Swift Package Manager, com uma API pensada para espelhar a do SDK Android: mesmos conceitos, mesmos nomes, inicialização simétrica.
• Vários inicializadores, do mais simples (uma chave de API) ao mais completo (URL de servidor, ambiente, registo de eventos). Caso simples imediato, caso avançado possível.
• Configuração multi-tenant e alternância entre produção e pré-produção, para que as equipas clientes possam testar sem tocar em dados reais.
• Aplicações de demonstração em UIKit no iOS e, no Android, tanto em vistas clássicas como em Jetpack Compose. Um integrador encontra um exemplo parecido com o seu próprio código, seja qual for a geração de arquitetura que usa.
• Documentação de integração entregue com cada SDK.

O resultado

Dois SDK nativos entregues em paralelo, prontos a ser integrados pelas equipas técnicas das cadeias clientes da editora.

Neste tipo de missão, a qualidade mede-se por uma coisa: o número de perguntas que o integrador tem de fazer antes de aquilo funcionar. Todo o trabalho de API, de nomenclatura simétrica e de exemplos múltiplos serve para aproximar esse número de zero.