EAS Update no app: quando usar OTA, quando exigir nova build e como evitar update incompativel

Quando uma equipe descobre o EAS Update, a primeira sensacao costuma ser de alivio: finalmente existe um caminho para corrigir texto, layout, regra JavaScript e pequenos bugs sem esperar todo o ritual de loja. O problema aparece quando esse alivio vira excesso de confianca. Se o time passa a tratar qualquer mudanca como OTA, cedo ou tarde publica algo que depende de codigo nativo ausente, runtime errado, canal confuso ou validacao insuficiente. Ai o update rapido vira risco rapido.

Em app corporativo, EAS Update e excelente quando usado com criterio. Ele encurta o caminho entre detectar um problema e disponibilizar uma correcao compativel. Mas ele nao elimina a necessidade de build nova, de staging, de rollout gradual nem de leitura cuidadosa do que mudou no binario. O ganho real nao esta em atualizar tudo sem loja. Esta em saber exatamente o que pode ser atualizado sem loja.

Este guia organiza esse limite na pratica. A ideia e responder a pergunta que mais salva time pequeno de retrabalho: isso pode ir por OTA agora ou precisa de uma nova build? E, depois disso, mostrar como operar canais, runtime, rollout, republish e code signing de um jeito que caiba em um app React Native corporativo com Expo.

1. O que o EAS Update realmente entrega

A documentacao da Expo define o EAS Update como um servico que distribui atualizacoes para projetos que usam a biblioteca expo-updates. Na pratica, ele publica a camada nao nativa do app: bundle JavaScript, estilos e assets compativeis. Ou seja: ele nao substitui o binario instalado no aparelho. Ele troca apenas a parte que aquele binario ja sabe executar.

Isso e a chave da decisao. Se a mudanca fica na camada JavaScript, visual ou de asset, o OTA pode ser um bom caminho. Se a mudanca pede novo codigo nativo, nova permissao ou outro runtime, o app precisa de build nova. O EAS Update existe para acelerar correcao compativel, nao para burlar dependencia nativa.

A Expo tambem lembra que, para usar EAS Update, o app precisa incluir a biblioteca expo-updates no binario. Por isso, o primeiro setup ainda exige build nova. Depois disso, os updates publicados sao baixados no app e aplicados conforme a configuracao, normalmente no proximo app launch.

2. Quando um ajuste pode sair por OTA

Pelo material oficial da Expo, o EAS Update e indicado quando voce quer corrigir bug ou crash em JavaScript, ajustar copy, traducao, estilos, layout ou telas e publicar isso rapidamente entre submissoes de loja. Em app corporativo, isso costuma cobrir varios cenarios uteis:

• texto errado em tela operacional;
• regra de validacao JavaScript que nao depende de modulo nativo novo;
• pequeno ajuste de layout ou fluxo visual;
• correcao de feature flag, endpoint publico ou ordem de exibicao;
• hotfix em comportamento de tela que ja existe no binario.

Nesse tipo de caso, OTA ajuda bastante porque evita esperar loja apenas para empurrar um ajuste compativel. Se o app ja esta com a malha de observabilidade montada, o time consegue corrigir, publicar, observar e decidir se promove ou recua com muito mais velocidade.

3. Quando OTA nao resolve e build nova e obrigatoria

A mesma documentacao tambem deixa claro quando o EAS Update nao deve ser usado como atalho. A Expo lista explicitamente mudancas em codigo nativo, dependencias nativas, permissoes do app, upgrade de Expo SDK e qualquer alteracao que exija novo binario. Isso cobre boa parte dos erros mais caros em times pequenos.

Na pratica, pare e gere build nova quando houver:

• instalacao ou atualizacao de biblioteca nativa;
• mudanca em camera, localizacao, biometria, notificacao ou outra permissao;
• ajuste que depende de manifest, plist, scheme, package, bundle ou capability;
• upgrade de Expo SDK ou alteracao relevante no runtime nativo;
• qualquer mudanca que o binario atual simplesmente nao conhece.

Esse e o ponto em que o artigo ambientes e build profiles volta a ser importante. OTA funciona bem quando o binario ja foi preparado para a familia de comportamentos que voce quer atualizar. Quando esse preparo nao existe, o atalho certo e build nova.

4. Runtime version e a fronteira que protege seu app

A pagina oficial de runtime versions e muito direta: runtime version existe para garantir compatibilidade entre o codigo nativo do build e o update que sera baixado depois. O app tem uma camada nativa embutida no binario e uma camada de update que pode ser trocada. O runtimeVersion e o que garante que o update novo ainda sabe conversar com essa base nativa.

O risco mais comum aparece quando a equipe muda algo nativo, mas mantem o mesmo runtime. Nesse caso, builds antigos podem tentar carregar um update que chama codigo que nao existe neles. A Expo explica que o expo-updates pode detectar esse problema e tentar voltar ao update anterior, mas confiar nisso como estrategia principal e caro. O objetivo deveria ser evitar o update incompativel antes de publicar.

Por isso, sempre que o app ganhar nova dependencia nativa ou mudanca estrutural, vale tratar isso como um novo runtime. E ai o artigo compatibilidade entre app e API entra como leitura obrigatoria.

5. Qual politica de runtime costuma funcionar melhor

No guia de deploy da Expo, a recomendacao atual para a maioria dos apps e usar "runtimeVersion": { "policy": "appVersion" }. Isso faz o runtime acompanhar a versao nativa do app exibida na loja e simplifica bastante a leitura do que esta rodando em producao.

A documentacao tambem cita a politica fingerprint, mas observa que ela ainda e experimental e nao e a mais recomendada de forma ampla neste momento. Entao, para um time pequeno que quer previsibilidade, a inferencia mais segura a partir da documentacao e: comece com appVersion, discipline seu versionamento e so complique isso quando houver uma necessidade muito clara.

Em termos operacionais, isso gera uma regra simples: nova versao nativa, novo runtime, novo grupo de OTAs compativeis.

6. Canais resolvem mais problema do que branches na maioria dos apps

No guia de deploy de updates, a Expo apresenta um processo simples que privilegia canais e quase ignora branches. A propria documentacao diz que esse costuma ser o caminho com menor sobrecarga conceitual para a maioria dos apps. Em vez de transformar cada Git branch em uma estrategia de update, o time pode operar canais claros como preview, staging e production.

Isso combina muito bem com app corporativo, porque o objetivo normalmente nao e fazer experimento exuberante de release management. E conseguir testar hotfix, validar com um grupo menor e promover o mesmo pacote com seguranca. O guia tambem lembra uma restricao importante: cada binario sempre aponta para um unico canal, e esse canal nao pode ser trocado dinamicamente depois.

Em outras palavras: o build nasce sabendo para que familia de updates ele olha. Isso ajuda a organizar a operacao e evita misturar publico de preview com publico de producao sem querer.

7. Um fluxo simples de OTA costuma bastar

Juntando o guia de deploy com o artigo que acabamos de criar sobre CI/CD mobile com Expo e GitLab, um fluxo enxuto e forte para time pequeno pode ser este:

1. gerar build preview, staging e production com canais coerentes;
2. publicar o update primeiro em staging com runtime compativel;
3. validar o hotfix em binario com o mesmo runtime da producao;
4. promover exatamente o mesmo bundle testado para production;
5. observar crash, login, API e eventos antes de ampliar rollout.

A Expo inclusive recomenda que staging e production usem variaveis de ambiente e configuracao de code signing identicas, para que o que foi validado em staging se comporte do mesmo jeito em producao. Esse e um detalhe pequeno, mas com impacto enorme na confianca do release.

8. Republish e melhor do que gerar bundle diferente na promocao

No guia de deploy, a Expo sugere que, se o time validou a correcao em staging e quer garantir que o mesmo pacote chegue em producao, pode usar eas update:republish --destination-channel production. A inferencia pratica aqui e bem boa: promover o mesmo bundle reduz o risco de publicar outro pacote sem querer entre o teste e a producao.

Esse ponto e especialmente valioso quando ha pressa. O problema nao e apenas corrigir rapido. E corrigir rapido sem introduzir variacao nova no pacote da producao. Republish ajuda exatamente nisso.

9. Rollout gradual vale ouro quando o hotfix e sensivel

A pagina de rollouts mostra dois mecanismos: rollout por update e rollout por branch. Para a maioria dos cenarios simples, o rollout por update ja resolve bastante. Ele permite publicar com --rollout-percentage, por exemplo eas update --rollout-percentage=10, e depois ampliar esse percentual com eas update:edit.

Isso e excelente quando o hotfix mexe em login, sincronizacao, calculo, navegacao sensivel ou algum fluxo que ainda gera duvida. Em vez de entregar para 100% da base de uma vez, o time observa primeiros sinais e decide se amplia, segura ou reverte. A propria Expo tambem destaca que, se a rollout estiver em andamento, ela precisa ser encerrada antes de outra update com o mesmo runtime ser publicada naquela branch.

Para times pequenos, isso cria um bom habito: publicar menos no impulso e observar mais.

10. Rollback existe, mas o objetivo e precisar pouco dele

A Expo oferece caminhos para reverter rollout e para fazer rollback de update ja publicada. Isso e util e deve existir no procedimento. Mas rollback nao deveria ser o plano principal de compatibilidade. Ele e a rede de seguranca, nao a tecnica de navegacao.

O uso maduro de rollback em mobile combina tres coisas:

• runtime version bem disciplinado;
• staging com mesmo runtime da producao;
• rollout gradual quando o impacto e incerto.

Quando isso esta em ordem, rollback continua importante, mas aparece menos como resposta desesperada e mais como ferramenta controlada.

11. Code signing faz sentido quando OTA ja virou caminho critico

A documentacao de code signing da Expo mostra uma camada adicional de protecao: as updates podem ser assinadas criptograficamente e o cliente verifica essa assinatura antes de aplicar o pacote. Isso reduz risco de adulteracao por intermediarios e pelo proprio caminho de distribuicao. A Expo tambem destaca que essa funcionalidade de EAS Update Code Signing esta disponivel apenas em planos Production ou Enterprise.

Alguns pontos praticos merecem destaque:

• a chave privada deve ficar fora do source control;
• o certificado pode ser versionado no projeto;
• o processo de assinatura acontece localmente quando voce publica;
• rotacao de chave exige nova estrategia de runtime para builds que vao confiar no novo certificado.

Nem todo time pequeno precisa ligar code signing no primeiro dia. Mas, se OTA passa a ser parte critica da operacao, esse assunto deixa de ser luxo e vira governanca de release.

12. O app nao precisa checar update de qualquer jeito

A introducao do EAS Update tambem lembra que a biblioteca expo-updates oferece a API useUpdates() e metodos como checkForUpdateAsync() e fetchUpdateAsync() para estrategias personalizadas. Isso e importante porque nem todo app precisa baixar update em qualquer momento ou interromper fluxo sensivel para tentar aplicar pacote novo.

Em app corporativo, a decisao mais saudavel costuma ser combinar isso com contexto operacional:

• nao disparar refresh agressivo em meio a uma tarefa critica;
• avisar o usuario quando a nova versao ja foi baixada e faz sentido reiniciar;
• evitar confundir OTA com mecanismo de bloqueio total, papel que combina mais com versao minima e atualizacao obrigatoria;
• usar feature flag ou remote config quando o ajuste e de comportamento e nao de bundle.

13. App store continua existindo mesmo com OTA

A FAQ da Expo tambem lembra que updates precisam seguir as regras das plataformas e app stores. Em termos praticos, isso significa que usar OTA nao apaga responsabilidade sobre comportamento, conteudo e mudancas que podem precisar de revisao. O raciocinio seguro e: OTA acelera distribuicao de camada compativel, mas nao te isenta de cumprir o que App Store e Google Play exigem.

Por isso, vale manter o fluxo inteiro amarrado com beta real antes da loja, review e metadata e publicacao oficial. OTA entra no meio do sistema. Ele nao substitui o sistema.

14. Checklist para decidir rapido sem publicar no escuro

1. A mudanca mexe so em JavaScript, estilo, copy ou asset? Se nao, pare e gere build nova.
2. O runtime atual ainda e compativel com o que o update vai executar?
3. O canal de destino esta correto para o publico que deve receber a mudanca?
4. Existe staging com o mesmo runtime da producao para validar o pacote?
5. Vale usar republish para promover exatamente o bundle testado?
6. O update precisa sair para 100% da base ou um rollout por percentual faz mais sentido?
7. Se algo der errado, o time sabe como reverter e quem acompanha os sinais?

15. Quando vale um diagnostico tecnico

Se hoje o time ainda discute no feeling se um ajuste pode sair por OTA, se depende de nova build ou se runtime ficou coerente, o problema nao esta apenas no Expo. Falta um processo de release comum entre app, backend e operacao. Nessa hora, um diagnostico tecnico ajuda a desenhar canais, runtime, rollout, observabilidade e pontos de aprovacao sem excesso de ritual e sem improviso perigoso.

O melhor uso de EAS Update nao e atualizar tudo. E atualizar rapido apenas o que continua compativel, observavel e controlado.

Referencias editoriais: Expo - EAS Update introduction, Expo - Runtime versions and updates, Expo - Deploy updates, Expo - Rollouts e Expo - End-to-end code signing with EAS Update.