Busque em todas as páginas da documentação
Nomenclatura de canais EAS Update, política de versão de runtime, fluxo de promoção e gatilhos de rollback para Expo SDK 57. Atualizações OTA são poderosas e perigosas - JavaScript pode chegar à produção em minutos sem revisão da loja. Estas regras separam mudanças OTA seguras de lançamentos que quebram o nativo e definem quando fazer rollback.
eas update - runtimeVersion incorreta deixa usuários presos em bundles desatualizados silenciosamente.eas update com monitoramento de crash e feature flags - OTA sem observabilidade é voo cego.Defina a política explícita de runtimeVersion em app.config: Use policy: "appVersion", "sdkVersion", ou "fingerprint" consistentemente - documente qual política a equipe usa no README.
runtimeVersion dos artefatos de eas build deve corresponder ao que eas update tem como alvo.runtimeVersion e esperar que o EAS adivinhe corretamente entre os sabores.Incremente o runtime quando dependências nativas mudarem: Novo módulo nativo, upgrade de SDK, ou mudança de plugin de configuração → novo build de loja e novo runtime - OTA sozinho não pode adicionar código nativo.
Configure updates.url e projectId para EAS Update: extra.eas.projectId e updates.url em app.config - verifique com npx expo config --type public.
projectId e canais distintos por ID de bundle.eas update:list mostra bundles recentes após um publish de teste.Use eas update --environment <nome> no SDK 55+: Runners de atualização carregam variáveis do ambiente EAS nomeado - arquivos .env locais são ignorados, mantendo OTA alinhado com o ambiente de build.
eas update --channel production --environment production..env.local desatualizado.Verifique atualizações no lançamento com uma política sensata: expo-updates checkAutomatically e fallbackToCacheTimeout - equilibre novidade com inicialização offline.
Assinatura de código para atualizações quando necessário: Habilite a assinatura de código EAS Update para apps de alta segurança - verifique a rotação do certificado de assinatura no runbook.
Nomes de canal mapeiam para ambientes, não pessoas: development, preview, staging, production - não jane-test ou hotfix-tuesday.
eas.json atribuem channel por perfil.Fluxo de promoção é linear: development → preview (QA) → production - sem pular preview para mudanças JS "pequenas" que tocam pagamentos ou autenticação.
production de um branch de feature sem "soak" em preview.Builds de preview emparelham com canal de preview: QA instala binário do perfil EAS preview e recebe OTA no canal preview - corresponde ao comportamento de produção sem risco de loja.
Atualizações do canal de produção exigem regra de duas pessoas ou publicação via CI: eas update --channel production manual de laptops é propenso a erros - prefira GitHub Action em release taggeada.
eas update:list revisado no ticket de release.Versionar app.config version e números de build de loja independentemente: Versão de marketing vs ios.buildNumber / android.versionCode - incremente números de build a cada submissão de loja.
runtimeVersion: { policy: "appVersion" }, bumps de versão do app afetam o targeting OTA.Feature flags controlam payloads OTA arriscados: Flags remotas podem desabilitar caminhos de JS ruins sem um segundo OTA - flags não substituem testes de preview.
Seguro para OTA: JS, TS, assets, cópia, estilos, estrutura de navegação: Mudanças puramente JavaScript que não chamam novos símbolos nativos.
Requerido pela loja: módulos nativos, plugins, permissões, scheme, entitlements: Qualquer coisa que mude a saída de ios/ ou android/ após o prebuild.
Regressões de bytecode Hermes e tamanho de bundle podem ser enviadas via OTA - trate como eventos de release: Bundles grandes atrasam a inicialização - observe orçamentos de performance (veja Regras de Orçamento de Performance).
Mudanças de esquema de banco de dados e contrato de API precisam de compatibilidade retroativa: Usuários mobile pulam atualizações - JS deve tolerar respostas de API antigas até que a adoção da loja seja alta.
Não envie via OTA mudanças que quebram o formato do armazenamento local persistido sem migração: Aumentos de esquema MMKV/SQLite precisam de migração graciosa ou gate de versão - migração ruim pode quebrar instalações.
OTA de emergência ainda passa pelo preview quando possível: Sev-1 real pode pular o soak - documente a exceção e exija postmortem mais verificação de rollback em uma hora.
Defina gatilhos de rollback antes do lançamento:
| Gatilho | Responsável | Ação |
|---|---|---|
| Taxa de crash-free cai > X% vs baseline | Mobile on-call | Republicar bundle anterior ou redirecionamento de canal |
| Pico na taxa de falha de autenticação/login | Backend + mobile | Rollback OTA + desativar flag |
| Queda na taxa de sucesso de pagamento | Revenue + mobile | Rollback de produção imediato |
| Problema de segurança P0 em JS | Security + mobile | Correção OTA ou rollback dentro do SLA |
Saiba como fazer rollback de um EAS Update: Republicar o ID do bundle anterior no canal, ou usar o rollback do dashboard EAS - pratique em preview trimestralmente.
Rollback de loja é mais lento - planeje fallback de binário: Mantenha a versão anterior da loja disponível; rollout faseado na App Store e rollout escalonado na Play Store quando possível.
Monitore após cada OTA de produção por 24 horas: Sentry, analytics e dashboards de erro de API - on-call monitora sem assumir sucesso no momento do publish.
Alertas de incompatibilidade de runtime: Usuários com binários antigos que nunca recebem atualizações - rastreie falhas de verificação de expo-updates e versões de runtime desatualizadas em analytics.
Checklist de release são duas trilhas: Checklist de submissão de loja (nativo, screenshots, revisão) e checklist de OTA (soak em preview, flags, ID de rollback) - anexe ambos aos tickets de release.
Retrospectiva pós-release para qualquer rollback: Gatilhos de atualização, duração do preview, ou gates de CI - rollbacks são lições gratuitas se documentadas.
appVersion vincula o runtime à versão de marketing - simples para muitos apps. fingerprint faz hash do estado do projeto nativo - melhor quando mudanças nativas ocorrem sem bumps de versão. Escolha uma política, documente-a e nunca misture inconsistente entre os sabores.
Não - crashes nativos exigem um novo build de loja. OTA corrige apenas erros de JavaScript e bugs de lógica.
Mínimo: development, preview, production. Organizações maiores adicionam staging. Evite canais por desenvolvedor - use builds de preview com atualizações baseadas em branch em vez disso.
No SDK 55+, eas update --environment usa apenas variáveis de ambiente EAS - .env local é ignorado nos runners. Alinhe com como eas build resolve o env.
Obrigatório para correções de segurança e mudanças que quebram o contrato de API. Banner opcional para ajustes de UI. Documente a UX na estratégia de recarregamento do expo-updates.
Flags desabilitam caminhos de código em bundles já enviados - mais rápido que rollback OTA para erros de lógica. Flags não substituem testes de preview ou autorização do servidor.
Mínimo de 24 horas para caminhos de autenticação e pagamento; mais curto apenas com forte cobertura automatizada e cobertura on-call. Exceções Sev-1 documentadas post-hoc.
Não - cada ID de bundle e projeto EAS precisa de canais e linhas de runtime distintas. Um monorepo JS compartilhado pode publicar por app com comandos eas update separados.
Use builds de preview/dev client apontando para o canal development. Configurações de dev do expo-updates podem sobrescrever a URL de atualização em staging controlada - não em apps de produção.
Versão da loja, números de build, ID do bundle OTA, canal, último ID de rollback conhecido como bom, feature flags tocadas, janela de soak em preview e links de dashboards.
Fortemente recomendado - tags disparam eas update com ambiente production. Publicação manual via laptop requer segundo aprovador e postmortem.
Upgrade de SDK muda binários nativos - novo build de loja, nova linha de runtimeVersion. Runtimes antigos param de receber atualizações na nova linha nativa; planeje a comunicação de upgrade para usuários.
Esperado - usuários com builds de loja antigos permanecem em seu canal de runtime até que atualizem o binário. Monitore a distribuição de runtime e imponha a versão nativa mínima quando necessário.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0, e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 9 de jul. de 2026