iOS @ brMalls: como criamos e gerenciamos 26 aplicativos na AppStore
Os desafios e soluções encontradas para manter e escalar nossos apps.
Atualmente, a brMalls possui por característica a identidade e marca própria de cada shopping que administra. Neste cenário, durante o processo de tranformação digital, optamos por seguir a linha de um app para cada shopping. No momento possuímos 26 apps publicados na AppStore. Nesta publicação, vou descrever de forma breve como gerenciamos este processo de geração e personalização de cada app.
Visão geral
Iniciando por nossa estrutura, nós trabalhamos com monorepo, e utilizamos GitLab tanto para o repo em si como para o CI/CD. Todos os apps são gerados via CI, com scripts de customização para cada shopping. Ou seja, uma única base de código gera os 26 apps, sem utilização de targets para cada app. Tudo é realizado via script, Fastlane e CI. Atualmente o processo de geração dos 26 ipas para o Connect/TestFlight leva em média 2 horas (sem contar o tempo de processamento da build no Connect).
A seguir, destaco as principais etapas de customização durante a geração de cada app, bem como quais desafios e soluções encontramos em cada uma delas.
ℹ️ Informações do app
Para manter as informações gerais de cada app (como Bundle ID, URL schemes, nomes, referência a certificados, ids, etc), utilizamos arquivos .env que são lidos no processo de geração para substituição via faslane/scripts. As informações são substituídas nos Info.plist equivalentes.
🎨 Cores
Possuímos um arquivo em formato JSON que possui a paleta de cores de cada app, que é substituído via script e convertido em uma struct de cores (via SwiftGen) utilizada em momento de execução.
🖼 Imagens
Durante algum tempo, nós utilizamos arquivos PDFs duplicados para cada shopping e os substituíamos na pasta Assets durante o build. Porém este processo gerava muito trabalho manual (principalmente ao time de UX!), além de erros por eventuais arquivos divergentes.
Recentemente migramos para um esquema com arquivos de imagem tipo SVG, e via script, customizamos as cores internamente de acordo com o app que está sendo gerado. Desta forma, basta um arquivo svg para geração de todas suas variações. Nosso script faz uma substituição dentro do arquivo SVG, por exemplo procurando por #primary_color# e substituindo por #bd4461 .
🌐 Comunicação com APIs/SDKs
Além de cores e imagens, nosso app possui um arquivo de configuração que possui o id do shopping utilizado nas chamadas para nosso BFF. Este arquivo também é personalizado no momento da geração do IPA.
Neste artigo o foco está nas configurações locais do app, mas a título de informação, nosso app trabalha com um "feature manager", que retorna quais funcionalidades estarão disponíveis em cada app, qual a ordem de exibição e seu conteúdo. Tudo é gerenciado remotamente e em tempo real, sem necessidade de release. Desta forma, cada shopping pode customizar o conteúdo do app para exibir as informações pertinentes ao seu público ;)
Os arquivos de configuração das bibliotecas externas também são substituídos nesta etapa.
💻 Processo de Desenvolvimento
Todo nosso processo de desenvolvimento é feito com base em um app “padrão”, isto é, sem identidade visual de um shopping em particular. Caso o dev/QA necessite validar a identidade visual de um app específico, possuímos uma lane que faz a personalização do app para execução no simulador/device. Também possuímos pipelines específicos para geração dessas customização via TestFlight.
🗂 Organização
Para organizar e padronizar toda a inclusão/edição das informações de cada app, nós desenvolvemos uma ferramenta interna para MacOS usando AppKit: o iOS Customer Tools. Este app indica todas as informações necessárias e faz a criação de todos os arquivos no projeto.
📱Interação com AppStore Connect
Devido a quantidade de apps, nosso processo de release acaba sendo mais trabalhoso, então priorizamos automatizar tudo que é possível mesmo nas etapas mais simples. Aqui um grande aliado nosso é o Fastlane/Spaceship. Também usamos match para gerenciar todos os certificados/provisioning profiles (que são muitos por sinal!).
Todas as etapas da subida do app foram disponibilizadas via jobs no CI. Temos pipelines para:
- Criação da versão
- Inclusão do release notes (What's New)
- Envio para review
- Liberação para os usuários
Antes de automatizar todos estes passos, nossa release levava uma média de 9h para conclusão. Atualmente o processo completo leva menos de 4h \0/
Conclusão
O gerenciamento de diversos apps em uma estratégia "white label" pode ser muito desafiador, principalmente quando trabalhamos com múltiplas equipes. Após 2 anos da release dos apps, a lição que aprendemos aqui na brMalls é que devemos periodicamente revisitar nossos processos a fim de buscar melhorias. Automatizar fluxos, mesmo os mais simples, pode fazer uma grande diferença para uma estratégia de release bem sucedida. Por fim, manter todo o time Dev engajado e por dentro das particularidades do projeto é essencial para o sucesso dessa estratégia.
Muito obrigado pela leitura e até a próxima!
