Cómo crear capturas de pantalla para la App Store con React Native (2026)

Esto es lo que nadie te cuenta cuando publicas tu primera app con React Native en la App Store: no hay una forma integrada de generar las capturas de pantalla que la tienda requiere. Los desarrolladores nativos de iOS recurren al grabador de pruebas de interfaz de Xcode; los desarrolladores nativos de Android tienen Espresso integrado en el build. React Native se sitúa encima de ambas plataformas, con la lógica real de la app ejecutándose en JavaScript — y ninguna de esas herramientas sabe que tu JS existe. Te toca a ti salvar esa distancia.

Este artículo recorre los enfoques que realmente funcionan en la era de la Nueva Arquitectura (RN 0.7x en adelante, 2026), con comandos concretos. Es honesto sobre los costes, porque cada una de estas opciones tiene uno real. Después aborda la parte que viene tras la captura — la composición de marketing y la localización — que es un problema genuinamente distinto independientemente de cómo obtengas los fotogramas de origen.

El problema real: sin flujo nativo

App Store Connect exige capturas de pantalla en dimensiones de píxel exactas, idealmente un conjunto por clase de dispositivo y uno por configuración regional que soportes. Google Play tiene sus propios tamaños. Un proyecto nativo de iOS puede dirigir el simulador mediante XCUITest y volcar fotogramas; React Native técnicamente también puede, pero la prueba que escribes se ejecuta contra la capa nativa — el binario compilado — no directamente contra tus componentes JavaScript. Estás automatizando una caja negra que da la casualidad de que renderiza tu JS.

Esa distinción importa más de lo que parece. Significa que tu automatización de capturas falla por razones que no tienen nada que ver con tu código React (un Metro bundler que no estaba en marcha, un simulador bloqueado en un diálogo de permisos, un build nativo que se ha desincronizado de tu JS) y que la curva de aprendizaje es la curva de dos frameworks de pruebas nativos, no la de tu stack de RN habitual. Hay tres formas serias de abordar esto. Elige según la frecuencia con que publicas.

Opción 1 — Fastlane snapshot (iOS) y screengrab (Android)

Fastlane es el framework de automatización móvil de código abierto de referencia, y sus módulos de captura de pantalla son la opción más probada en combate. También son las que más trabajo requieren para configurar con React Native, porque fueron diseñadas para proyectos nativos y solo toleran RN.

iOS, con snapshot. Añades un target de pruebas de interfaz en Xcode y escribes casos XCUITest en Swift que llevan la app a cada pantalla que quieras capturar. fastlane snapshot init genera un Snapfile y un SnapshotHelper.swift en tu carpeta fastlane/. En la prueba llamas a setupSnapshot(app), lanzas la app y luego snapshot("01_home") en cada estado. Lo ejecutas desde el terminal con fastlane snapshot — no desde dentro de Xcode, que no produce la salida correcta. Recorre todos los simuladores y configuraciones regionales de tu Snapfile y escribe PNG en fastlane/screenshots/.

El matiz de React Native: snapshot lanza la app compilada, que en modo debug necesita que el Metro bundler ya esté en marcha. Por tanto, tu Fastfile (o un script envolvente) tiene que iniciar Metro primero — el truco habitual es lanzar npx react-native start en una sesión tmux en segundo plano antes de llamar a snapshot, y cerrarlo después. Los builds de release con el bundle JS incluido evitan esto, pero te cuestan un build de release completo por ejecución.

Android, con screengrab. Framework completamente distinto: screengrab usa Espresso. Añades llamadas Screengrab.screenshot("name") dentro de pruebas instrumentadas JUnit, declaras permisos (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION y permisos de almacenamiento), compilas un APK de debug y un APK de pruebas con ./gradlew assembleDebug assembleAndroidTest, y ejecutas fastlane screengrab. La salida va a fastlane/metadata/android/. Al igual que en iOS, Metro y el emulador deben estar ya en marcha — screengrab no los inicia por ti.

Ventajas:

• Integrado en CI y sin desfase. Conéctalo a tu pipeline y las capturas de pantalla se regeneran en cada build de lanzamiento, siempre coincidiendo con la app publicada.
• Renderizado real por configuración regional. Cada configuración regional se ejecuta en el simulador/emulador con sus ajustes reales, por lo que fechas, números y monedas se renderizan de forma nativa — sin falsificación en una herramienta de diseño.
• Gratuito, de código abierto y maduro. Sin suscripción, gran comunidad, modos de fallo bien documentados.

Desventajas (sé honesto contigo mismo aquí):

• Mantienes dos suites de pruebas nativas. XCUITest en Swift para iOS, Espresso/JUnit en Kotlin/Java para Android — como desarrollador de RN, eso puede ser dos stacks desconocidos.
• Prueba la capa nativa, no tu lógica JS. Las pruebas operan sobre vistas nativas renderizadas; no conocen tu árbol de componentes.
• La configuración inicial lleva uno o dos días, y el baile del Metro bundler es una fuente recurrente de ejecuciones de CI inestables.
• La salida son fotogramas sin procesar. Sin textos, sin marcos de dispositivo, sin degradados, sin carrusel — solo la interfaz básica de la app a la resolución del simulador.
• Requiere Mac para iOS. El simulador necesita Xcode.

Para una comparación más detallada sobre la cuestión de la composición concretamente, consulta Fastlane snapshot vs capturas de pantalla para la App Store sin código y la comparación Mokbi vs Fastlane.

Opción 2 — capturas de pantalla con Detox (diseñado para React Native)

Detox es un framework de pruebas end-to-end de caja gris creado específicamente para React Native, por el equipo de Wix. Si ya usas Detox para pruebas e2e, las capturas de pantalla son casi gratuitas, y la curva de aprendizaje es la que de todas formas querrías superar — es una API de JavaScript, no de Swift ni de Kotlin.

La llamada de captura es una sola línea dentro de cualquier prueba:

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

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

Si esas imágenes se conservan como artefactos lo controla el flag --take-screenshots (none, failing, manual o all) y se configura en .detoxrc.js. En modo manual o all, las pruebas que pasan escriben en <artifacts-location>/✓ [test name]/[name].png. Llevas la app a cada estado con los mismos matchers de Detox que usarías para las aserciones y luego capturas la pantalla.

Ventajas:

• Es una API de JS. Escribes las pruebas en el mismo lenguaje en que está escrita tu app — sin una suite de pruebas nativas en un segundo lenguaje que mantener.
• Caja gris, por lo que entiende RN. Detox se sincroniza con el bridge/JSI de la app y espera a que esté en reposo, lo que hace las capturas mucho menos inestables que las esperas con tiempo fijo de XCUITest.
• Un framework, ambas plataformas. El mismo archivo de pruebas captura iOS y Android.
• Probablemente ya lo tienes si haces pruebas e2e, en cuyo caso el coste marginal de las capturas es mínimo.

Desventajas:

• Poner en marcha Detox desde cero no es trivial — configuración de build nativo, un build de prueba dedicado y preparación del emulador/simulador. Si aún no lo tienes, es una inversión real.
• El manejo de configuraciones regionales corre por tu cuenta. Detox no recorre automáticamente todas las configuraciones regionales de la App Store como hace el Snapfile de snapshot; tú escribes el script para cambiar la configuración regional o relanzas con distintos ajustes.
• La salida sigue siendo fotogramas sin procesar. Igual que Fastlane — interfaz básica de la app, sin capa de marketing.
• Las capturas pueden diferir entre equipos host (un problema conocido de Detox), lo que importa si las comparas en CI pero es inofensivo para los recursos de la tienda.

Opción 3 — captura manual (la más sencilla, y subestimada)

Abre el iOS Simulator o un emulador Android, navega por tu app hasta cada pantalla a mano y captura el fotograma. En iOS, Cmd-S en el Simulator guarda un PNG con las dimensiones correctas en el escritorio; xcrun simctl io booted screenshot home.png hace lo mismo desde el terminal y es fácil de automatizar de forma básica. En Android, el botón de cámara del emulador o adb exec-out screencap -p > home.png captura la pantalla. Un dispositivo físico también funciona — captura y luego transfiere los archivos por AirDrop o de otra forma.

Se descarta demasiado rápido. Tiene cero configuración, nunca falla en CI porque no hay CI, y para una app que publica unas pocas veces al año es genuinamente el camino más rápido hasta un conjunto de fotogramas de origen. La desventaja es obvia y real: es manual, por lo que no se regenera solo, y si cambias una pantalla tus capturas quedan desactualizadas hasta que las rehaces. Para un carrusel de cinco paneles eso supone diez minutos de trabajo por publicación — más barato que mantener una automatización de pruebas que ejecutas dos veces al año.

Lo que todo el mundo olvida: composición y localización

Esto es lo que une a las tres opciones: todas producen capturas de pantalla sin procesar de la app, y las capturas sin procesar no son lo que convierte en la tienda. El carrusel de la App Store que realmente impulsa instalaciones tiene un marco de dispositivo alrededor de la pantalla, un texto de una línea encima que explica el beneficio, un fondo que no es el blanco de tu app, y continuidad entre los cinco paneles. Ninguna de las herramientas de captura anteriores produce nada de eso — se detienen en el fotograma básico. No es un defecto de ellas; es un trabajo diferente.

Este es el paso donde encaja Mokbi, y vale la pena ser preciso sobre el límite: no captura tus capturas de pantalla de origen — eso es el simulador, el dispositivo o Fastlane/Detox como se describe arriba. Lo que hace es la capa de composición de marketing y localización que viene a continuación. Sueltas tus fotogramas sin procesar en un editor de navegador, los envuelves en marcos de dispositivo reales, añades textos, compones carruseles de varios paneles, luego traduces los textos a 50 idiomas de un solo clic y exportas por lotes en todas las dimensiones de la tienda. Diseñar es gratuito con una vista previa con marca de agua; la exportación y la publicación ilimitadas vienen con una suscripción — Solo €29.99/mo (1 app) o Studio €49.99/mo (hasta 5 apps), sin compra única. La razón por la que encaja bien es que resuelve el problema que tu pipeline de captura ni siquiera intenta abordar: convertir una carpeta de PNG en un carrusel localizado y listo para la tienda sin abrir Photoshop ni redimensionar a mano para 50 idiomas.

El flujo de trabajo combinado realista

1. Captura los fotogramas de origen. Elige uno: Fastlane (snapshot + screengrab) en CI para publicaciones frecuentes, Detox si ya tienes pruebas e2e, o captura manual desde el simulador para las esporádicas. Resultado: una carpeta de PNG sin procesar por pantalla y por dispositivo.
2. Compón, añade textos y enmarca. Sueltas los fotogramas sin procesar en un editor de navegador. Añades marcos de dispositivo, escribes los textos de beneficio, construyes el carrusel de cinco paneles, eliges un fondo.
3. Traduce. Traduce los textos por lotes a 50 idiomas de un clic, luego revisa a mano los idiomas que más te importan.
4. Exporta por lotes. Exportas todas las configuraciones regionales en todas las dimensiones requeridas para App Store Connect y Google Play de una sola vez.
5. Reemplaza en la siguiente versión. Recapturas los fotogramas modificados (vuelves a ejecutar Fastlane/Detox, o los tomas a mano), reabres el proyecto guardado, intercambias las capturas de pantalla y vuelves a exportar. El trabajo de textos y traducción ya está hecho.

Cuándo puedes prescindir de la automatización

Si publicas entre uno y tres lanzamientos al año — lo que describe a la mayoría de las apps indie con React Native — el coste de configuración de Fastlane o Detox casi nunca se amortiza. Pasarías un día conectando XCUITest y el baile del Metro bundler para ahorrar diez minutos de captura manual dos veces al año. Esa cuenta no cierra. Captura a mano desde el simulador, compón y localiza en el navegador, y habrás terminado en menos tiempo total del que llevaría configurar la automatización una sola vez.

La automatización se paga sola cuando publicas cada semana o cada día, cuando el desfase de capturas se convierte en un bug recurrente, o cuando gestionas un portfolio de apps y el coste de captura por app se multiplica. A esa escala, Fastlane en CI (o Detox si ya está en tu stack) es la elección correcta para el paso de captura — y aun así lo combinas con una herramienta de composición en el navegador para la capa de marketing, porque ningún pipeline de captura produce un carrusel terminado.

Antes de exportar cualquier cosa, vale la pena confirmar los objetivos: los tamaños de capturas de pantalla de la App Store que realmente necesitas subir, y los requisitos de capturas de pantalla de la App Store que provocan rechazos de envíos. Tenerlos claros desde el principio te ahorra una vuelta con App Review.

Qué leer a continuación

• Para desarrolladores de React Native
• Comparación: Mokbi vs Fastlane
• Fastlane snapshot vs capturas de pantalla para la App Store sin código
• Tamaños de capturas de pantalla de la App Store
• Requisitos de capturas de pantalla de la App Store

Abrir el editor →