Expo, development build e EAS Build: como sair do prototipo no React Native

Um app React Native pode nascer rapido com Expo Go. Isso e otimo para validar telas, navegacao inicial e chamadas simples. Mas, em algum momento, o projeto corporativo precisa testar recursos nativos, variaveis por ambiente, notificacoes, permissao, deep link, build de homologacao, assinatura e distribuicao interna. Esse e o ponto em que development build e EAS Build deixam de ser detalhe e viram parte da arquitetura.

Para um app como o PraxyManager mobile, essa transicao importa porque o aplicativo precisa conversar com APIs reais, lidar com autenticacao, rodar em Android e iOS, receber ajustes sem confundir usuarios e chegar a validadores antes de ir para loja. O processo de build precisa ser repetivel, documentado e seguro.

Este guia organiza uma rota pratica para sair do prototipo e criar um fluxo mobile mais profissional com Expo, development builds, EAS Build e EAS Update.

1. Entenda o papel do Expo Go

Expo Go e excelente para comecar. Ele permite abrir o projeto rapidamente no aparelho, testar interface, componentes, navegacao e logica JavaScript sem gerar um binario proprio a cada mudanca.

Ele e util para:

• validar layout inicial;
• navegar entre telas;
• testar chamadas HTTP simples;
• ajustar componentes e estilos;
• compartilhar um prototipo com a equipe tecnica;
• acelerar aprendizado no comeco do projeto.

Mas Expo Go nao representa o app final. Ele tem um conjunto de modulos ja embutidos e nao inclui automaticamente qualquer biblioteca nativa especifica do seu projeto. Quando o app precisa de recurso nativo customizado ou configuracao real de producao, chega a hora de usar development build.

2. Saiba quando criar um development build

Development build e um aplicativo de desenvolvimento gerado para o seu projeto, com `expo-dev-client` e os modulos nativos que o app realmente usa. Ele continua tendo ferramentas de desenvolvimento, mas se aproxima muito mais do app real do que Expo Go.

Crie um development build quando o app tiver:

• notificacoes push;
• camera, galeria, arquivos ou biometria;
• modulo nativo que nao existe no Expo Go;
• configuracao propria de Android ou iOS;
• deep links reais;
• permissoes que precisam aparecer no aparelho;
• SDKs de analytics, crash ou monitoramento;
• necessidade de testar comportamento de build em validadores.

O erro comum e adiar esse passo ate perto da publicacao. Quanto mais tarde o development build entra, maior a chance de descobrir problema nativo quando a equipe ja achava que o app estava pronto.

3. Organize o app config antes de gerar build

O arquivo de configuracao do Expo define nome, slug, versao, bundle identifier, package, icones, splash screen, plugins, permissoes e varias propriedades que influenciam Android e iOS. Ele nao deve ser tratado como detalhe visual.

Antes do primeiro build, confira:

• nome publico do app;
• slug estavel;
• bundle identifier iOS;
• package Android;
• versao e build number;
• icone e splash coerentes com a marca;
• permissoes realmente usadas;
• scheme para deep link;
• plugins nativos necessarios;
• configuracao de updates.

Mudar alguns desses campos depois pode ser simples; outros podem criar dor em loja, assinatura, links ou instalacoes ja existentes. Em app corporativo, vale decidir com calma.

4. Separe ambientes desde cedo

O app nao deve apontar sempre para a mesma API. Desenvolvimento, homologacao e producao precisam ser separados. Isso evita que testes internos criem dados reais ou que uma build de producao use endpoint errado.

Ambientes comuns:

• development: API local ou ambiente de dev;
• preview: API de homologacao para validadores;
• production: API real;
• internal: build distribuido para um grupo pequeno de teste.

Defina tambem como variaveis entram no app. Algumas configuracoes podem ser publicas, como URL base da API. Segredos reais nao devem ir para o aplicativo, porque app mobile pode ser inspecionado. Senha, token mestre e credenciais criticas pertencem ao backend.

5. Use build profiles para repetir o processo

EAS Build usa perfis de build para declarar como cada tipo de binario deve ser gerado. Em vez de lembrar comandos manuais, o projeto registra perfis para desenvolvimento, preview e producao.

Um desenho simples:

• development: gera development build com dev client;
• preview: gera build interno para validacao, geralmente sem loja;
• production: gera build assinado para loja ou distribuicao final.

Perfis ajudam a responder: qual comando gera o app para teste? Qual usa API de homologacao? Qual incrementa versao? Qual plataforma sera gerada? Qual canal de update recebe aquele build?

O importante e que outra pessoa consiga repetir o build sem depender da memoria de quem configurou tudo.

6. Teste em aparelho real antes de confiar no simulador

Simulador e emulador ajudam, mas nao substituem aparelho real. Performance, permissao, notificacao, camera, biometria, armazenamento, rede e tamanho de tela aparecem de forma diferente no dispositivo.

Teste pelo menos:

• Android intermediario;
• Android com tela pequena;
• iPhone real quando iOS fizer parte do plano;
• rede Wi-Fi e rede movel;
• app fechado e reaberto;
• login expirado;
• permissao negada;
• atualizacao de build anterior para build novo.

Um app corporativo pode funcionar perfeitamente no computador do desenvolvedor e falhar na mao do usuario que tem aparelho mais simples e conexao instavel.

7. Entenda o que EAS Update pode e nao pode fazer

EAS Update permite distribuir mudancas de JavaScript, estilos e assets sem passar por novo build de loja, desde que sejam compativeis com a runtime version instalada. Isso e muito util para corrigir texto, ajustar tela, mudar fluxo JavaScript ou melhorar experiencia sem esperar revisao da loja.

Mas EAS Update nao substitui build quando muda:

• codigo nativo;
• permissao nativa;
• plugin de configuracao;
• SDK nativo;
• bundle identifier ou package;
• versao de runtime incompativel;
• dependencia que exige nova compilacao.

Regra pratica: se a mudanca altera o que esta dentro do binario nativo, precisa de novo build. Se muda apenas JavaScript compativel com o binario instalado, pode ser update.

8. Use canais de update com responsabilidade

Canal de update separa qual grupo de builds recebe determinada atualizacao. Isso permite enviar update para preview sem afetar producao.

Um fluxo saudavel:

1. Publicar update em canal de desenvolvimento.
2. Validar em aparelho real.
3. Promover para canal de preview.
4. Validar com usuarios internos.
5. Promover para producao quando houver confianca.

Enviar update direto para producao sem validacao pode quebrar app instalado mesmo sem passar pela loja. A velocidade e boa, mas continua precisando de criterio.

9. Planeje distribuicao interna

Antes da loja, o app precisa chegar a testadores. Em Android, builds internos podem ser instalados com mais flexibilidade. Em iOS, TestFlight costuma ser o caminho mais organizado para validacao externa ou interna, respeitando regras da Apple.

Defina:

• quem testa;
• qual aparelho cada pessoa usa;
• qual build esta instalada;
• qual ambiente de API esta sendo usado;
• que fluxo precisa ser validado;
• onde reportar erro;
• qual criterio permite promover o build.

Distribuicao interna sem roteiro vira conversa solta. Com roteiro, cada build gera aprendizado.

10. Versione app e API juntos

Mobile tem uma diferenca importante em relacao ao web: usuarios podem ficar com versoes antigas instaladas. O backend precisa aceitar essa realidade.

Cuidados:

• nao remover endpoint usado por app antigo sem janela de transicao;
• evitar mudanca quebradora em payload sem versionamento;
• registrar versao do app nas chamadas criticas;
• mostrar mensagem clara quando uma versao deixar de ser suportada;
• manter changelog tecnico de app e API;
• validar producao com build antigo e build novo quando a API mudar.

O artigo React Native para app corporativo explica por que a fronteira entre app e backend precisa ser desenhada desde o inicio.

11. Automatize sem esconder o processo

EAS ajuda a automatizar builds, mas a equipe ainda precisa entender o que acontece. Nao basta ter um comando que gera binario. E preciso saber qual perfil foi usado, qual ambiente entrou, qual canal recebe update, qual versao foi publicada e onde estao as evidencias.

Uma rotina minima registra:

• commit usado no build;
• perfil EAS usado;
• plataforma gerada;
• ambiente da API;
• versao e build number;
• canal de update;
• link ou identificador do artefato;
• resultado dos testes internos.

Isso aproxima mobile da disciplina que ja usamos em backend, Docker e VPS: publicar e validar fazem parte do mesmo trabalho.

12. Checklist para o primeiro fluxo Expo/EAS

1. Definir se Expo Go ainda atende ou se ja precisa de development build.
2. Instalar e configurar dev client quando houver recurso nativo real.
3. Revisar app config, icones, package, bundle identifier e permissoes.
4. Separar ambientes de API.
5. Criar perfis development, preview e production no EAS.
6. Gerar build de desenvolvimento e testar em aparelho real.
7. Gerar build preview para validadores.
8. Configurar EAS Update com runtime version e canais.
9. Testar update em canal nao produtivo.
10. Registrar versao, commit, perfil e evidencias.
11. Validar compatibilidade entre app e API.
12. So entao preparar build de producao.

13. Erros comuns

• achar que Expo Go e igual ao app final;
• descobrir recurso nativo apenas no fim do projeto;
• usar a API de producao em build de teste;
• guardar segredo real dentro do app;
• nao versionar app e backend juntos;
• mandar update direto para producao sem validar canal;
• nao testar em aparelho real;
• esquecer de documentar qual build foi validado;
• trocar package ou bundle identifier sem entender impacto.

Expo, development build e EAS Build ajudam muito, mas nao sao apenas ferramentas de conveniencia. Eles definem como o app sai da maquina do desenvolvedor e chega a pessoas reais com controle.

Quando esse fluxo nasce cedo, o time consegue testar melhor, publicar com mais calma e corrigir com menos susto. Para apps corporativos, isso e uma vantagem enorme: o mobile deixa de ser uma aventura paralela e passa a fazer parte da operacao tecnica.

Referencias editoriais: Expo development builds, EAS Build, EAS Update, EAS configuration, Expo app config e React Native Get Started.