Capturas de tela do App Store com Expo: por que o EAS Submit as ignora e como publicá-las rapidamente (2026)

Se você publica um app Expo, seu processo de lançamento provavelmente termina em uma linha: eas submit. Ele pega o build produzido pelo EAS e entrega para a Apple ou para o Google. Limpo, sem drama, confiável. Então você abre o App Store Connect para colocar o build no ar e — os campos de captura de tela estão vazios. Sempre.

Isso pega muita gente de surpresa porque o EAS parece fazer tudo. Ele builda, assina e envia. Será que não cuida das capturas de tela também? Não cuida, e a documentação diz isso claramente. Não é um bug nem uma funcionalidade faltando para você reportar — está simplesmente fora do escopo do EAS Submit.

O que o EAS Submit realmente faz (e não faz)

O EAS Submit é um serviço de entrega de binários. Ele faz upload de exatamente uma coisa: o arquivo compilado do seu app — um .ipa para iOS, um .aab para Android — no pipeline de processamento da loja. A documentação do Expo é explícita sobre esse limite:

"O EAS Submit faz o upload do seu binário, mas não gerencia metadados da listagem da loja, capturas de tela ou notas de versão."

Existe uma ferramenta complementar, o EAS Metadata, que pode automatizar partes da sua listagem no App Store — nome do app, subtítulo, descrições localizadas, palavras-chave, URLs de suporte — a partir de um arquivo de configuração. É genuinamente útil e vale a pena configurar. Mas leia com atenção o seu escopo: capturas de tela não estão incluídas. O EAS Metadata envia texto, não imagens. Suas capturas de tela, em ambas as lojas, continuam sendo sua responsabilidade produzir e enviar.

Então o problema das capturas de tela no Expo se divide em dois trabalhos distintos, e ajuda mantê-los separados na sua cabeça:

1. Capturar — extrair frames brutos das telas reais do seu app a partir de um build.
2. Compor e localizar — transformar esses frames brutos nos painéis de marketing enquadrados, legendados e multilíngues que as lojas realmente exibem.

O EAS não faz nenhum dos dois. O próprio guia de assets da loja do Expo indica que você mesmo capture os frames e projete os painéis em uma ferramenta como o Figma. Vamos percorrer os dois trabalhos com comandos concretos.

Trabalho 1: capturando frames de um build de dev ou preview

Você quer capturas de tela do app real, então precisa que o app esteja rodando em algum lugar onde você possa capturá-lo. No Expo, isso significa um dev client ou um build de preview — não o Expo Go, já que o Expo Go exibe a interface do wrapper do Expo e sua configuração nativa pode ser diferente. Build e execute localmente com os comandos padrão do Expo:

• npx expo run:ios — faz o prebuild nativo do iOS, compila e inicializa seu app no iOS Simulator.
• npx expo run:android — o mesmo para um emulador Android (ou um dispositivo conectado).

Com o app na tela do iOS Simulator, a captura é um único comando no terminal do Mac:

xcrun simctl io booted screenshot home.png

booted aponta para o simulador em execução e grava um PNG com pixels exatos no seu diretório de trabalho. Dois flags importam para o trabalho na loja: --type=png (o padrão, e o que as lojas querem) e --mask=ignored versus --mask=black — a máscara controla se o notch e os cantos arredondados são renderizados na imagem. Para uploads no App Store, em geral você quer os pixels retangulares planos e adiciona a moldura de dispositivo depois na composição, então a captura sem máscara costuma ser o ponto de partida correto.

No Android, capture direto do emulador (ou do dispositivo) com o adb:

adb exec-out screencap -p > home.png

Use exec-out, não shell screencap. O caminho pelo shell simples passa o PNG por um pseudo-terminal que corrompe o binário em algumas configurações (você recebe um arquivo corrompido com retornos de carro extras); o exec-out transmite os bytes diretamente e é a forma confiável. Se você rodar vários emuladores, aponte para um específico com adb -s <serial> obtido do adb devices.

Esse é o kit completo de captura manual: dois comandos, um por plataforma, sem dependências além do Xcode e do Android SDK que você já tem para um build nativo com Expo.

Trabalho 1, automatizado: Maestro ou Detox

Navegar até a tela certa manualmente e rodar esses comandos na mão funciona bem para um punhado de capturas. Quando você tem oito telas em duas classes de dispositivo, ou quer que as capturas sejam regeneradas a cada lançamento para nunca ficarem desatualizadas em relação à interface real, você automatiza a captura com uma ferramenta de teste end-to-end que consegue controlar o app e tirar os frames.

Maestro é a ferramenta que o próprio Expo usa nos exemplos documentados de EAS Workflows. Os fluxos são YAML simples, o que mantém a barreira de entrada baixa. Um fluxo que navega até uma tela e a captura tem esta aparência:

appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard

Execute com maestro test flows/home.yaml. O comando takeScreenshot grava um PNG no diretório de saída dos testes (defina MAESTRO_TESTS_DIR para o caminho onde você quer que os assets fiquem). Os mesmos fluxos rodam em CI no EAS Workflows — o exemplo documentado pelo Expo builda um .apk com um perfil de build e2e-test e depois roda um fluxo .maestro/ contra ele — então você pode integrar a captura de capturas de tela no mesmo job que executa sua suite e2e.

Detox é a outra opção consolidada, com uma API JavaScript mais programática e rigorosa:

const path = await device.takeScreenshot('dashboard');

Seja honesto consigo mesmo sobre a configuração do Detox com Expo, porém. O Detox não oferece suporte oficial ao Expo. Na prática, funciona se você rodar npx expo prebuild para gerar os projetos nativos e buildar um client no estilo release (não um dev client) para o bundle JS estar embutido — e então apontar o Detox para esse binário. São mais peças em movimento do que o YAML do Maestro, e o benefício é a API de sincronização e asserção mais rígida do Detox. Se você já usa o Detox, aproveite-o para captura; se está escolhendo agora e seu objetivo são capturas de tela da loja, o Maestro é o caminho mais simples.

Trabalho 1, manual: a escolha certa para lançamentos pouco frequentes

A automação se paga quando você lança com frequência. Se você publica de um a três lançamentos por ano — o que descreve a maioria dos apps Expo indie — configurar fluxos do Maestro ou uma config do Detox para captura de tela é um trabalho que você paga uma vez e mal amortiza. Para esse ritmo, apenas:

1. Inicialize o build com npx expo run:ios / run:android e popule-o com dados de demonstração realistas.
2. Navegue até cada tela principal manualmente.
3. Capture cada uma com o comando simctl / adb acima.

Vinte minutos de cliques superam meio dia de harness de testes que você terá esquecido como manter até o próximo lançamento. Não há nada de errado na captura manual — as lojas não conseguem saber como o PNG foi produzido.

Trabalho 2: composição e localização em 50 idiomas

Aqui está a parte que as ferramentas de captura deliberadamente não tocam — e é a parte pela qual as lojas realmente te avaliam. Um PNG bruto do simctl é a interface do seu app sobre um fundo branco. O que aparece bem nos resultados de busca e converte na página do produto é o painel de marketing: a captura de tela dentro de uma moldura de dispositivo, sobre um fundo com a identidade visual da marca, com uma legenda de uma linha explicando por que aquela tela importa — geralmente em um carrossel multipainel que se lê da esquerda para a direita. E no App Store, as capturas de tela são localizadas por tamanho de dispositivo e por idioma, então um lançamento sério é dezenas de variantes, não cinco.

É aqui que o Mokbi se encaixa, e vale ser preciso sobre esse limite. O Mokbi não captura seu app — você ainda produz os frames de origem com os comandos do Expo acima. O que ele faz é pegar esses frames e deixar você, no navegador: colocá-los em molduras de dispositivo reais, adicionar legendas e fundos em gradiente, organizar carrosséis multipainel, traduzir o texto das legendas para 50 idiomas com um clique e exportar em lote todas as dimensões do App Store e do Play Store de uma vez. Você projeta gratuitamente com uma visualização com marca d'água; a exportação ilimitada vem com uma assinatura — Solo €29.99/mo (1 app) ou Studio €49.99/mo (até 5 apps), sem compra única. Ele substitui a etapa de modelo do Figma que o guia do Expo trata de forma superficial — nada mais, nada menos.

O fluxo de trabalho combinado na prática

1. Builde um client de dev/preview. npx expo run:ios e npx expo run:android, populados com bons dados de demonstração.
2. Capture os frames de origem. Manualmente via xcrun simctl io booted screenshot e adb exec-out screencap -p, ou automatizado via Maestro takeScreenshot / Detox device.takeScreenshot — de preferência no EAS Workflows para que sejam regenerados a cada lançamento.
3. Componha os painéis de marketing. Enquadre, adicione legendas e organize o carrossel a partir dos frames brutos.
4. Localize e exporte em lote. Traduza as legendas nos idiomas-alvo e exporte todas as dimensões exigidas pelas duas lojas.
5. Envie os assets da listagem. Capturas de tela para o App Store Connect e o Play Console; combine com o EAS Metadata para os campos de texto, se você o usar.
6. Envie o binário. eas submit — a única etapa que o EAS realmente faz.
7. No próximo lançamento: recapture as telas alteradas, reabra o projeto de composição salvo, substitua os frames e reexporte. As legendas e traduções já estão prontas.

Quando você pode pular a automação

Recorra ao Maestro ou ao Detox para captura quando a desatualização das capturas de tela for um custo real: você lança semanalmente, sua interface muda constantemente, ou você mantém muitos apps e não pode se dar ao luxo de ter imagens antigas na loja. Nesses casos, frames regenerados pelo CI valem o investimento, e a história das ferramentas de captura de tela no React Native (que o Expo herda) vale o esforço de configuração.

Para todos os outros — quem publica uma vez por trimestre — pule a automação. Captura manual com dois comandos de terminal, depois composição e localização no navegador, e você chega a uma listagem polida e multilíngue em uma tarde, sem nada para manter entre os lançamentos. Adeque as ferramentas ao seu ritmo, não ao que parece impressionante num dashboard de CI.

De qualquer forma, a parte do binário está resolvida: eas submit cuida disso. Certifique-se de conferir suas capturas de tela em relação aos requisitos atuais da loja antes de enviá-las — a Apple rejeita uma listagem por um único pixel fora do lugar — e o restante do lançamento é só design.

O que ler a seguir

• Para desenvolvedores Expo
• Capturas de tela do App Store no React Native
• Comparação lado a lado: Mokbi vs fastlane
• Tamanhos de captura de tela do App Store
• Requisitos de captura de tela do App Store

Abrir o editor →