Reduzir o tempo de build em CI é desafio antigo para líderes técnicos em mobile, e quem acompanha meus conteúdos já percebeu o quanto falo sobre isso nas minhas publicações. Agora, existe uma técnica que me surpreendeu nos testes: usar Expo Fingerprint, Expo Repack e EAS workflows juntos pode cortar até 80% do tempo de compilação. Pode parecer mágica no começo, mas calma, é só arquitetura voltada à realidade de quem quer automatizar ao máximo.
O que é o repack e por que ele faz tanta diferença
Vou direto ao ponto. Repack é uma solução oferecida pelo Expo que permite reutilizar uma build nativa existente, trocando só o pacote JavaScript. Em vez de compilar o projeto mobile inteiro do zero toda vez que há uma mudança em código JS, você pode pedir para o CI só embutir o novo JavaScript em um app já pronto.
Você pula toda a parte nativa!
Com isso, o tempo de build despenca de cerca de 25 minutos para 5 minutos (ou menos). Essa diferença parece pequena em um único build, mas pense em equipes que fazem 1.000 builds por ano. Dá mais de 300 horas salvas. Ou seja, quase duas semanas úteis de alguém trabalhando só pra esperar builds que, agora, terminam rapidinho.
O funcionamento do Repack está detalhado na documentação do Expo. O ponto forte é justamente poder testar, experimentar e validar código JavaScript de forma muito mais ágil, sem ocupar filas do CI com compilações que nunca mudaram nada por baixo do capô.
Arquitetura do react native: o segredo está na separação
App React Native padrão é dividido em duas parte principais:
- Lado nativo (código Objective-C/Swift no iOS, Java/Kotlin no Android)
- Pacote JavaScript (tudo que você realmente codifica no React Native)
Assim, boa parte das melhorias em testes, deployments e atualizações rápidas dependem de aproveitar que mudanças só em JavaScript não exigem build nativa nova.
Era comum pensar que builds em CI precisavam ser totalmente recompilados sempre. Só que não. Se o lado nativo, ou seja, frameworks e plugins, não sofreu alteração, é perda de tempo recompilar tudo. O segredo está em detectar essas alterações. E aqui entra o Expo Fingerprint.
Expo fingerprint: detectando mudanças nativas automaticamente
Expo Fingerprint é uma ferramenta que gera um hash único para identificar o estado do código nativo do app. Ao rodar o workflow do EAS com Fingerprint ativado, ele compara se houve alguma alteração no pacote nativo. Se não mudou nada importante, ele sabe que basta reaproveitar a build existente — e pronto, só injeta o novo JS.
Isso faz com que:
- O build do nativo só roda quando realmente necessário.
- O CI detecta mudanças pequenas e só repackaging (no JS) é feito.
- O tempo de build reduz drasticamente em vários cenários.
Parece simples, mas só quem já esperou um CI travando por 30 minutos entende o alívio.
Menos espera, mais código em produção!
Quando (não) usar: advertências e limites do repack
Nem tudo são flores. O Repack não é indicado para builds de produção. Isso porque builds reconstruídas dessa forma podem faltar arquivos nativos adicionais que ferramentas como Sentry usam para relatórios de crash, ou arquivos que dependem de configuração pós-build. O próprio Expo reforça esse ponto. É interessante, por exemplo, para builds de QA, homologação, testes de pull request — mas builds para Play Store ou App Store devem seguir o caminho tradicional.
Exemplo prático: testando o repack em um projeto real.
Recentemente, para validar algumas das ideias que venho aplicando e compartilhando, testei essa abordagem em um projeto React Native preparado para CI. A meta era simples: ver o processo funcionando de ponta a ponta em ambiente de testes, utilizando o EAS.
O fluxo foi assim:
- Criei pastas separadas para workflows de Android e iOS, como sugerido na documentação do Expo (é bom para organização e logs).
- No workflow, adicionei tarefas para:
- Calcular o fingerprint nativo antes de qualquer build;
- Buscar builds existentes e compatíveis (baseadas nesse fingerprint);
- Executar repack se possível, ou build normal se houve mudança nativa.
- Para Android, segui as tarefas orientadas para arquivos .apk/.aab. No iOS, precisei adaptar por conta dos profiles de provisionamento e certificados.
- O acionamento dos workflows foi feito no terminal:
Comando: eas build --platform android|ios --profile test
Você pode até parametrizar para builds automáticos em PR no GitHub. Todo esse processo exige atenção especial ao validar nas primeiras execuções — sempre algo pega em configuração da máquina, paths, múltiplas branches. Faz parte.
O resultado? Na primeira build, levou aqueles 23 minutos clássicos. Na segunda, com o mesmo fingerprint do nativo, subiu em 4 minutos e meio. Senti diferença no ciclo de feedback dos desenvolvedores. Quando se tem pull request para cada nova feature, e builds em todas as branches, esse tempo ganho pode ser a diferença entre uma equipe cansada e uma equipe engajada.
Benefício multiplicado: horas salvas, time mais ágil
Ninguém quer perder tempo esperando CI. Se o time executa builds a cada pull request (PR), a soma dos minutos economizados vira horas semanais. Isso reflete diretamente na entrega, na qualidade dos testes e naquele respiro que falta entre uma entrega e outra.
Com o processo emplacado, mais tempo para pensar em arquitetura, mentorar pessoas, melhorar processos — valores que carrego em tudo o que construo. Pode parecer exagero, mas só rodando um mês inteiro de Repack no CI para perceber como libera energia para o que realmente importa.
Conclusão
Cortar o tempo de build no CI com Expo Fingerprint e Repack é totalmente possível, e na maioria dos cenários de testes internos faz muita diferença. O segredo está em enxergar onde realmente existem mudanças no nativo e automatizar o EAS para detectar isso automaticamente. Líderes, tech leads e desenvolvedores que aplicam essa abordagem ganham tempo e fôlego para evoluir, tanto tecnicamente quanto na busca por destaque de carreira.
Se você se interessa por processos de Engenharia Mobile, carreira em liderança técnica e integração de tecnologias como IA. Experimente essas técnicas, compartilhe seus aprendizados e evolua sua prática, assim como temos feito juntos no projeto. Quanto maior seu domínio sobre build automations, mais valor você entrega sem perder tempo. Bora evoluir junto!
Perguntas frequentes
O que é Expo Fingerprint?
Expo Fingerprint é uma ferramenta que calcula um hash único baseado em todos os arquivos e configurações da camada nativa do app, ajudando a identificar quando precisa (ou não) refazer uma build nativa. Isso possibilita reutilizar builds já existentes sempre que não houver mudanças nesse contexto, agilizando o processo e cortando espera desnecessária.
Como usar o Repack no CI?
Primeiro, configure o workflow do EAS para calcular o fingerprint antes do build. O CI verificará se já existe uma build compatível com o fingerprint gerado. Se sim, fará apenas o repack, substituindo apenas o JS, sem recompilar nativo. O fluxo detalhado e exemplos práticos podem ser encontrados na documentação do Expo relacionada ao Repack e EAS workflows.
Vale a pena implementar o Fingerprint?
Sim, principalmente em projetos com muitos builds para testes, QA ou homologação. O tempo salvo acumulado é alto. Porém, para builds de produção, ainda é preferível seguir o build integral por questões de arquivos adicionais e integrações externas.
Quais vantagens do Repack no Expo?
O Repack permite testar rapidamente alterações JS sem precisar compilar tudo de novo. Isso acelera feedbacks, libera o CI para mais builds concorrentes e reduz custo. Ajuda, também, a identificar gargalos e investir tempo em melhorias de produto em vez de infraestrutura.
Como reduzir tempo de build no CI?
Implemente o uso do Expo Fingerprint juntamente com o Repack e configure os EAS workflows otimizados. Dessa forma, o CI só faz builds nativos realmente necessários. Isso tira pressão das filas, libera builds mais rápidas para testes e alinha todo o processo com práticas modernas de desenvolvimento mobile.
