EAS Build, Update e Submit: do código às lojas

EAS Build compila um binário Android ou iOS; EAS Update envia JavaScript e assets compatíveis para um binário já instalado; EAS Submit entrega um binário às lojas. São três etapas diferentes. Saber essa fronteira evita tentar corrigir uma mudança nativa com update ou acreditar que submit já publicou a ficha da loja.

Esta lição parte de um projeto com configuração nativa reproduzível e uma development build. Os comandos de nuvem exigem conta, projeto e credenciais; por isso os passos não são apresentados como uma publicação realmente executada pelo ambiente editorial.

Fábrica, encarte e transportadora

Imagine um produto físico. A fábrica monta uma caixa com todas as peças: esse é o EAS Build. Um encarte pode corrigir instruções sem trocar o produto: esse é o EAS Update, limitado ao conteúdo que a caixa já consegue interpretar. A transportadora leva a caixa para o varejista: esse é o EAS Submit.

No mapa técnico, a caixa é o binário .aab, .apk ou .ipa; o encarte é um update com bundle JavaScript e assets; a transportadora é o envio para Google Play ou App Store Connect. Revisão, metadados, classificação e liberação nas lojas continuam existindo depois da entrega.

O limite da analogia é que um update não é texto passivo: ele executa lógica no app. Tecnicamente, só deve chegar a binários cujo runtimeVersion declara compatibilidade. Se o código espera um módulo nativo ausente, é preciso gerar e distribuir outra build.

Instale e confira a CLI sem esconder a versão

Você pode usar a CLI sem instalação global:

npx eas-cli@latest --version

Em 22 de agosto de 2026, o ambiente verificado respondeu:

Antes de configurar serviços, autentique-se:

npx eas-cli@latest login
npx eas-cli@latest whoami

Use conta da organização e política de acesso adequada ao projeto. Não cole token em app.json, repositório ou tutorial. Em CI, utilize o mecanismo de segredos do provedor e tokens com o menor alcance possível.

Dê um trabalho específico a cada perfil de build

Um eas.json inicial pode separar desenvolvimento, preview e produção:

{
  "cli": {
    "version": ">= 22.2.0",
    "appVersionSource": "remote"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {}
  }
}

Development inclui o dev client; preview entrega uma build interna parecida com produção; production prepara o artefato de loja. autoIncrement ajuda a evitar número de build repetido, e appVersionSource: remote centraliza esse número no EAS. Adapte ambientes e credenciais à equipe; esse arquivo não resolve sozinho distribuição, assinatura ou acesso às contas das lojas.

Configure o projeto de forma interativa:

npx eas-cli@latest build:configure

Na EAS CLI 22.2.0, build:configure não aceita a flag --non-interactive. Ao testá-la, a saída real foi:

Não espalhe uma flag porque outro subcomando a aceita. Consulte --help da versão usada e automatize somente depois de completar a associação inicial do projeto.

Gere o artefato adequado ao destino

Depois da configuração e autenticação, uma build interna Android usa:

npx eas-cli@latest build --platform android --profile preview

Uma build de produção para as duas plataformas usa:

npx eas-cli@latest build --platform all --profile production

Build remoto envia o projeto à infraestrutura do EAS, instala dependências, executa prebuild quando aplicável, compila, assina e disponibiliza o artefato. Tempo, fila e sucesso dependem do serviço e das credenciais; não invente uma saída local para representar essas etapas.

Antes de gastar uma build, rode npx expo-doctor@latest, testes, typecheck e uma exportação local. Eles não substituem a compilação nativa, mas encontram falhas mais baratas de corrigir.

Configure Update com uma versão de runtime consciente

Instale o módulo compatível e associe o projeto:

npx expo install expo-updates
npx eas-cli@latest update:configure

O processo adiciona URL de updates, project id e uma política de runtime à app config. Uma opção que acompanha a versão do aplicativo é:

{
  "expo": {
    "runtimeVersion": { "policy": "appVersion" },
    "version": "1.0.0",
    "updates": {
      "url": "https://u.expo.dev/SEU-PROJECT-ID"
    }
  }
}

O objetivo de runtimeVersion é casar update e código nativo compatíveis. A política precisa acompanhar seu processo de releases. Se você acrescentou uma permissão ou biblioteca nativa, incremente a versão conforme a política, gere nova build e só envie JavaScript destinado a esse runtime.

Publique JavaScript apenas dentro da caixa compatível

No SDK 55 em diante, eas update exige ambiente explícito. Um envio de preview pode ser:

npx eas-cli@latest update \
  --channel preview \
  --environment preview \
  --message "Corrige validação do formulário"

Canal direciona builds a uma linha de updates; environment seleciona variáveis do ambiente EAS. Branch e canal têm papéis relacionados, mas não trate seus nomes como sinônimos sem revisar a estratégia oficial de deployment.

Use esta fronteira antes de publicar:

Pode ir por EAS Update:
- JavaScript/TypeScript, estilos e assets compatíveis.

Exige nova build:
- módulo nativo novo;
- permissão ou config plugin alterado;
- mudança que torna o runtime anterior incompatível.

Uma correção urgente não suspende essa regra. Enviar bundle incompatível pode quebrar justamente os usuários que ainda têm o binário antigo.

Submit entrega; a loja ainda decide a publicação

Depois de uma build de produção bem-sucedida, envie o artefato mais recente:

npx eas-cli@latest submit --platform android --profile production --latest
npx eas-cli@latest submit --platform ios --profile production --latest

EAS Submit automatiza o upload. Você ainda precisa preencher listagem, imagens, privacidade, classificação etária, territórios e preço, além de lidar com a revisão. No Google Play, o primeiro envio de um app pode exigir uma etapa manual antes de a automação assumir o fluxo previsto pela conta.

Não coloque senha da Apple ou arquivo de service account no Git. Siga o fluxo de credenciais do EAS e restrinja quem pode iniciar submissões de produção.

Reproduza o bloqueio real sem fingir uma publicação

Executado sem sessão autenticada, o configurador parou antes de qualquer alteração remota:

CI=1 npx eas-cli@22.2.0 build:configure --platform android

O erro observado foi:

Esse bloqueio é parte da honestidade do teste. Não houve autenticação, consumo de build, update publicado nem envio às lojas. O artigo está com codeTested: false porque provar a sintaxe local não prova o pipeline remoto.

Missão: ensaie uma release sem apertar o botão final

Escreva uma tabela com uma mudança de cada tipo e a ação correta. Rode todos os checks locais e use --help para conferir as flags da CLI instalada.

Mudança                         Ação
Cor de um texto                 Update, se runtime compatível
Adicionar módulo de câmera      Prebuild + nova Build
Enviar .aab já aprovado         Submit
Editar screenshots da loja      Console da loja

O ensaio está pronto quando existe responsável, perfil, canal, runtimeVersion e plano de reversão. Antes da release, aplique a bateria de testes e performance para React Native e Expo.