Como acelerar o lançamento de apps React Native com Codemagic e atualizações Over-the-Air

O problema dos lançamentos tradicionais em React Native

Antes de introduzirmos o Codemagic no nosso processo, os lançamentos eram feitos manualmente: disparar builds, assinar a app e submeter o binário resultante à App Store Connect ou à Google Play Console. Esta abordagem tinha um risco real de erro humano, uma variável de ambiente em falta, um certificado de assinatura errado, um número de versão trocado, entre outros. Introduzia também inconsistência e falhas do tipo "funciona na minha máquina".

Além disso, cada lançamento, mesmo uma correção pequena, tinha de passar pelo processo completo de submissão e revisão da Apple e da Google, que podia demorar entre algumas horas a vários dias até ser aprovado. Isto aplicava-se mesmo a correções pequenas ou alterações que não tocavam em código nativo, como um ajuste de interface.

A solução: Codemagic e atualizações OTA para React Native

O problema que estávamos a resolver tinha duas frentes: os lançamentos dependiam de passos manuais suscetíveis a erro humano, e mesmo a correção mais pequena tinha de passar pela mesma fila de espera que um lançamento maior. Para resolver isto, introduzimos dois tipos de ferramentas diferentes, uma que automatiza o processo de lançamento em si, e outra que dá às correções não nativas uma forma de contornar o processo de revisão: CI/CD e atualizações OTA.

3.1 Construir apps React Native com o Codemagic

Integração e Entrega Contínua (CI/CD) é a prática de compilar e testar uma app de forma consistente e repetível, preparando-a depois para lançamento, em vez de fazer tudo isto manualmente. O Codemagic é uma das plataformas de CI/CD disponíveis, pensada especificamente para desenvolvimento mobile, o que é importante porque o React Native tem as suas próprias dores de cabeça, como certificados de assinatura, provisioning profiles e passos específicos de cada plataforma.

O Codemagic pode iniciar builds automaticamente ou manualmente com um clique, e também suporta testes automatizados que apanham bugs cedo, antes de uma build ser enviada para a App Store Connect ou Google Play Console. Na Codepoint, fazemos push para um branch e iniciamos as builds nós próprios a partir do painel do Codemagic, em vez de as disparar automaticamente. Mesmo sem o lado automático, a diferença é significativa. O que era uma sequência de passos suscetíveis a falhas passou a acontecer num ambiente consistente, substituindo um processo manual longo por um clique.

Isto resolve metade do problema. Não resolve a outra questão: a fila de revisão em si, que pode demorar um tempo desproporcional face à dimensão da alteração.

3.2 Entregar atualizações React Native via Over-the-Air

Over-the-Air (OTA) é um método de entrega sem fios que permite a uma app React Native já instalada no dispositivo do utilizador ir buscar e aplicar atualizações ao seu bundle de JavaScript e assets diretamente a partir de um servidor, sem passar pelo processo de revisão da Apple ou da Google. Uma atualização tradicional das lojas substitui o binário inteiro, mas o OTA não toca nessa parte, limita-se às partes da app que vivem fora da camada nativa.

A experiência é praticamente invisível para o utilizador. A app verifica se existe um bundle mais recente e aplica-o, e consoante a configuração da atualização, isto pode acontecer silenciosamente em segundo plano ou pedir ao utilizador para reiniciar, caso a atualização seja marcada como obrigatória.

Várias plataformas tratam disto no ecossistema React Native. Para equipas que trabalham com Expo, o EAS Update é uma escolha comum, mas na Codepoint usamos o RevoPush, porque oferece uma alternativa mais económica a outras soluções de OTA.

Juntas, estas duas peças resolvem o problema descrito anteriormente. O Codemagic retira o trabalho manual e o erro humano da forma como um lançamento é construído e distribuído. O RevoPush dá às nossas correções não nativas uma forma de chegar aos utilizadores sem passar pela fila de revisão da Apple ou da Google, transformando o que costumava demorar dias em horas.

Arquitetura do sistema

4.1 Dois fluxos separados

Usamos dois fluxos separados consoante a alteração toque ou não em código nativo:

O fluxo OTA aplica-se a alterações que não tocam em código nativo. Publicamos diretamente através do RevoPush, com configuração obrigatória ou opcional, e a atualização chega diretamente aos dispositivos dos utilizadores.

O fluxo Codemagic aplica-se a alterações que tocam em código nativo. Iniciamos uma build manualmente a partir do painel do Codemagic, e assim que está concluída, é submetida à App Store ou à Google Play, onde aguarda revisão antes de ficar disponível aos utilizadores.

O fluxo usado depende sobretudo de a alteração tocar ou não em código nativo, uma alteração nativa tem sempre de passar pela loja. O tamanho do bundle também importa, as atualizações OTA funcionam melhor para alterações pequenas e incrementais.

4.2 Ferramentas e serviços

O nosso setup inclui um serviço de controlo de versões como o GitHub ou o GitLab, o Codemagic para as builds, e o RevoPush para o fluxo OTA.

4.3 Estrutura de ambientes

Esta estrutura não é exclusiva do Codemagic ou do OTA, mas vale a pena descrevê-la aqui já que é onde ambos os fluxos acabam por operar:

Development: a nossa build de desenvolvimento da app, para testar alterações antes de avançarem no pipeline.

Staging: onde a nossa equipa de testes tem acesso, é para aqui que enviamos as atualizações OTA para testar antes de chegarem a utilizadores reais.

Production: o que os utilizadores reais usam, onde o lançamento sai através do fluxo OTA ou do fluxo Codemagic.

Resultados e desafios

5.1 Resultados

Desde que adotámos este setup, notámos lançamentos mais rápidos, com ciclos de horas em vez de dias para alterações não nativas. A produtividade da equipa de desenvolvimento aumentou, porque se gasta menos tempo em logística de lançamento e mais tempo a programar. Vimos também uma melhor experiência para o utilizador, com menos pessoas presas a versões da app com bugs. E passámos a conseguir lançar com mais frequência, já que o custo e o risco de lançar uma alteração pequena baixaram de forma significativa.

5.2 Desafios

A abordagem não está isenta de limitações. O OTA só pode ser usado para alterações não nativas, por isso atualizações de SDK, novos pacotes nativos, entre outros, continuam a exigir um lançamento pela loja. Dependemos também da disponibilidade do Codemagic e de manter a configuração do pipeline correta, e tivemos de ser deliberados sobre como gerir os dois fluxos em conjunto, para evitar lançar código com problemas.

Porque é que isto importa para equipas React Native

Combinar o Codemagic com atualizações Over-the-Air resolveu os dois maiores problemas do nosso ciclo tradicional de lançamento em React Native: o processo manual e suscetível a erros de build e submissão, e a fila de revisão imprevisível das app stores. Juntos, eliminaram o incómodo de construir e distribuir manualmente novas versões, e reduziram o tempo até um utilizador ver uma correção de interface de dias para horas. O resultado é um ciclo de desenvolvimento com feedback rápido, e uma melhor experiência para quem usa a app.

Se a sua equipa está a avaliar opções de CI/CD e OTA para uma app React Native, ou lida com ciclos de lançamento lentos no setup atual, temos todo o gosto em conversar sobre o que faria sentido para o seu projeto.