2026-07-04 · Workflow · 9 min de leitura

Como criar capturas de tela para o App Store em apps React Native (2026)

TL;DR. O React Native não oferece um pipeline nativo de capturas de tela. Suas opções reais para capturar os frames brutos são: fastlane (XCUITest no iOS, screengrab/Espresso no Android), Detox (criado para RN e o mais fácil dos três) ou captura manual no simulador. Qualquer que seja a escolha, o resultado são capturas brutas do app — transformá-las em um carrossel pronto para a loja, com legendas, molduras de dispositivo e variantes localizadas, é uma etapa de marketing separada. Para a maioria das equipes que lançam algumas vezes por ano, a captura manual mais composição no navegador supera um dia de configuração do fastlane.

Eis o que ninguém te conta quando você publica seu primeiro app React Native na App Store: não existe uma forma nativa de gerar as capturas de tela que a loja exige. Desenvolvedores iOS nativos recorrem ao gravador de testes de UI do Xcode; desenvolvedores Android nativos têm o Espresso integrado ao build. O React Native fica em cima de ambos, com a lógica do app rodando em JavaScript — e nenhuma dessas ferramentas sabe que seu JS existe. Você fica responsável por preencher essa lacuna.

Este post percorre as abordagens que realmente funcionam na era da New Architecture (RN 0.7x em diante, 2026), com comandos concretos. É honesto sobre os custos, porque toda opção tem um custo real. Depois cobre a parte que vem após a captura — a composição de marketing e a localização — que é um problema genuinamente separado, independentemente de como você obtém os frames de origem.

O problema real: nenhum pipeline nativo

O App Store Connect quer capturas de tela em dimensões exatas de pixels, idealmente um conjunto por classe de dispositivo e um por idioma que você suporta. O Google Play tem seus próprios tamanhos. Um projeto iOS nativo pode controlar o simulador via XCUITest e exportar frames; o React Native tecnicamente também pode, mas o teste que você escreve roda contra o shell nativo — o binário compilado — não diretamente contra seus componentes JavaScript. Você está automatizando uma caixa-preta que por acaso renderiza seu JS.

Essa distinção importa mais do que parece. Significa que sua automação de capturas de tela quebra por razões que não têm nada a ver com seu código React (um Metro bundler que não estava rodando, um simulador travado em um diálogo de permissão, um build nativo que divergiu do seu JS) e que a curva de aprendizado é a de dois frameworks de teste nativo, não a do seu stack RN familiar. Há três formas sérias de resolver isso. Escolha com base na frequência com que você lança.

Opção 1 — fastlane snapshot (iOS) e screengrab (Android)

O fastlane é o framework de automação mobile open-source canônico, e seus módulos de captura de tela são a opção mais testada e comprovada. São também os que dão mais trabalho para configurar no React Native, pois foram criados para projetos nativos e apenas toleram o RN.

iOS, via snapshot. Você adiciona um target de testes de UI no Xcode e escreve casos XCUITest em Swift que conduzem o app a cada tela que deseja capturar. fastlane snapshot init cria um Snapfile e um SnapshotHelper.swift na pasta fastlane/. No teste, você chama setupSnapshot(app), inicia o app e usa snapshot("01_home") em cada estado. Você executa pelo terminal com fastlane snapshot — não de dentro do Xcode, que não produz a saída correta. O comando percorre cada simulador e idioma configurados no Snapfile e grava os PNGs em fastlane/screenshots/.

O detalhe React Native: o snapshot inicializa o app compilado, que em modo debug precisa que o Metro bundler já esteja rodando. Por isso, seu Fastfile (ou um script wrapper) precisa iniciar o Metro primeiro — o truque comum é iniciar npx react-native start em uma sessão tmux em background antes de chamar o snapshot, encerrando-o depois. Builds de release com o bundle JS embutido evitam isso, mas custam um build completo de release a cada execução.

Android, via screengrab. Framework completamente diferente: o screengrab usa Espresso. Você adiciona chamadas Screengrab.screenshot("nome") dentro de testes instrumentados JUnit, declara as permissões (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION e permissões de armazenamento), compila um APK de debug e um APK de teste com ./gradlew assembleDebug assembleAndroidTest e executa fastlane screengrab. A saída vai para fastlane/metadata/android/. Assim como no iOS, o Metro e o emulador precisam já estar no ar — o screengrab não os inicia para você.

Pontos fortes:

Integrado ao CI e à prova de divergência. Conecte ao seu pipeline e as capturas serão regeneradas a cada build de lançamento, sempre refletindo o app publicado.
Renderização real por idioma. Cada idioma roda no simulador/emulador com as configurações reais de localidade, então datas, números e moedas são renderizados nativamente — não simulados em uma ferramenta de design.
Gratuito, open source e maduro. Sem assinatura, grande comunidade e falhas bem documentadas.

Pontos fracos (seja honesto consigo mesmo):

Você mantém dois suites de testes nativos. XCUITest em Swift para iOS, Espresso/JUnit em Kotlin/Java para Android — para um desenvolvedor RN, podem ser dois stacks desconhecidos.
Testa o shell nativo, não sua lógica JS. Os testes verificam views nativas renderizadas; não têm consciência da sua árvore de componentes.
A configuração leva um ou dois dias na primeira vez, e a dança com o Metro bundler é uma fonte recorrente de execuções instáveis de CI.
A saída são frames brutos. Sem legendas, sem molduras de dispositivo, sem gradientes, sem carrossel — apenas a interface do app na resolução do simulador.
Mac obrigatório para iOS. O simulador requer o Xcode.

Para uma comparação mais aprofundada sobre a questão de composição, veja fastlane snapshot vs capturas de tela no-code para o App Store e a comparação Mokbi vs fastlane.

Opção 2 — Detox screenshots (criado para React Native)

O Detox é um framework de testes end-to-end gray-box criado especificamente para React Native, pela equipe do Wix. Se você já usa Detox para testes e2e, as capturas de tela saem quase de graça, e a curva de aprendizado é a que você de qualquer forma quer percorrer — é uma API JavaScript, não Swift ou Kotlin.

A chamada de captura é uma linha dentro de qualquer teste:

// full screen
const path = await device.takeScreenshot('01_home');

// a single element
await element(by.id('paywallRoot')).takeScreenshot('paywall');

Se essas imagens são mantidas como artefatos é controlado pela flag --take-screenshots (none, failing, manual ou all) e configurado em .detoxrc.js. No modo manual ou all, os testes bem-sucedidos gravam em <artifacts-location>/✓ [test name]/[name].png. Você conduz o app a cada estado com os mesmos matchers do Detox que usaria para asserções e, em seguida, tira a captura.

Pontos fortes:

É uma API JavaScript. Você escreve os testes na mesma linguagem do app — sem um segundo suite de testes nativo para manter.
Gray-box, então entende o RN. O Detox sincroniza com a bridge/JSI do app e aguarda ele estar ocioso, tornando as capturas muito mais estáveis do que esperas temporizadas às cegas do XCUITest.
Um framework, as duas plataformas. O mesmo arquivo de teste captura iOS e Android.
Você provavelmente já o tem se faz testes e2e — nesse caso, o custo marginal de adicionar capturas de tela é mínimo.

Pontos fracos:

Configurar o Detox do zero não é trivial — configuração de build nativo, um build de teste dedicado e configuração de emulador/simulador. Se você ainda não o usa, é um investimento real.
O tratamento de idiomas fica por sua conta. O Detox não percorre todos os idiomas do App Store automaticamente como faz o Snapfile do snapshot; você precisa scripting das mudanças de idioma ou reiniciar com configurações diferentes.
A saída ainda são frames brutos. Assim como o fastlane — apenas a interface do app, sem camada de marketing.
As capturas podem diferir entre máquinas host (um problema conhecido do Detox), o que importa se você as compara no CI, mas não tem impacto nos assets da loja.

Opção 3 — Captura manual (a mais simples, e subestimada)

Abra o Simulator do iOS ou um emulador Android, navegue pelo app até cada tela manualmente e capture o frame. No iOS, Cmd-S no Simulator salva um PNG no tamanho correto na área de trabalho; xcrun simctl io booted screenshot home.png faz o mesmo pelo terminal e é fácil de usar em scripts simples. No Android, o botão de câmera do emulador ou adb exec-out screencap -p > home.png captura a tela. Um dispositivo físico também funciona — capture e transfira os arquivos via AirDrop ou outro meio.

Essa opção é descartada rápido demais. Zero configuração, nunca quebra no CI porque não há CI, e para um app que lança poucas vezes por ano é genuinamente o caminho mais rápido para um conjunto de frames de origem. A desvantagem é óbvia e real: é manual, então não se regenera sozinho, e se você alterar uma tela as capturas ficam desatualizadas até você refazê-las. Para um carrossel de cinco telas, isso significa dez minutos de trabalho por lançamento — mais barato do que manter automação de testes que você executa duas vezes por ano.

O que todo mundo esquece: composição e localização

Eis o que une as três opções: todas produzem capturas brutas do app, e capturas brutas não são o que converte na loja. O carrossel do App Store que realmente gera instalações tem uma moldura de dispositivo ao redor da tela, uma legenda de uma linha explicando o benefício, um fundo que não é o branco do seu app e continuidade entre os cinco painéis. Nenhuma das ferramentas de captura acima produz nada disso — elas param no frame bruto. Isso não é uma falha delas; é um trabalho diferente.

É aqui que o Mokbi entra, e vale ser preciso sobre o limite: ele não captura suas capturas de tela de origem — isso é feito pelo simulador, pelo dispositivo ou pelo fastlane/Detox acima. O que ele faz é a camada de composição de marketing e localização que vem em seguida. Você importa os frames brutos para um editor no navegador, envolve-os com molduras de dispositivo reais, adiciona legendas, monta carrosséis multipainel e, com um clique, traduz as legendas para 50 idiomas e exporta em todas as dimensões da loja. O design é gratuito com visualização com marca d'água; exportação e publicação ilimitadas vêm com uma assinatura — Solo €29.99/mo (1 app) ou Studio €49.99/mo (até 5 apps), sem compra avulsa. O motivo pelo qual ele se encaixa bem é que resolve o problema que seu pipeline de captura nem tenta resolver: transformar uma pasta de PNGs em um carrossel localizado e pronto para a loja sem abrir o Photoshop nem redimensionar manualmente para 50 idiomas.

O fluxo de trabalho combinado na prática

Capture os frames de origem. Escolha um: fastlane (snapshot + screengrab) no CI para lançamentos frequentes, Detox se você já usa testes e2e, ou captura manual no simulador para lançamentos esporádicos. Resultado: uma pasta de PNGs brutos por tela, por dispositivo.
Componha, adicione legendas e moldure. Importe os frames brutos para um editor no navegador. Adicione molduras de dispositivo, escreva as legendas de benefício, monte o carrossel de cinco painéis, escolha um fundo.
Traduza. Traduza as legendas para 50 idiomas com um clique e, em seguida, revise manualmente os idiomas que mais importam para você.
Exportação em lote. Exporte todos os idiomas em todas as dimensões exigidas para o App Store Connect e o Google Play em uma única passagem.
Atualize no próximo lançamento. Recapture os frames alterados (reexecute fastlane/Detox ou capture manualmente), reabra o projeto salvo, substitua as capturas de tela e reexporte. O trabalho de legendas e tradução já está feito.

Quando você pode pular a automação

Se você lança de um a três vezes por ano — o que descreve a maioria dos apps React Native indie — o custo de configuração do fastlane ou do Detox quase nunca se paga. Você gastaria um dia configurando XCUITest e a dança com o Metro bundler para economizar dez minutos de captura manual duas vezes por ano. Essa conta não fecha. Capture manualmente no simulador, componha e localize no navegador, e você termina em menos tempo total do que a automação levaria para ser configurada uma única vez.

A automação se justifica quando você lança semanal ou diariamente, quando a divergência das capturas vira um bug recorrente, ou quando você mantém um portfólio de apps e o custo de captura por app se multiplica. Nessa escala, o fastlane no CI (ou o Detox, se já estiver no seu stack) é a escolha certa para a etapa de captura — e você ainda o combina com uma ferramenta de composição no navegador para a camada de marketing, porque nenhum pipeline de captura produz um carrossel finalizado.

Antes de exportar qualquer coisa, vale confirmar os alvos: os tamanhos de captura de tela do App Store que você realmente precisa enviar e os requisitos de captura de tela do App Store que resultam em rejeições de submissão. Acertar isso de uma vez evita uma ida e volta com a App Review.

O que ler a seguir

Abrir o editor →