Capturas de pantalla de la App Store con Expo: por qué EAS Submit no las gestiona y cómo publicarlas rápido (2026)

Si publicas una app con Expo, tu flujo de lanzamiento probablemente termina en una sola línea: eas submit. Toma el build que produjo EAS y lo entrega a Apple o Google. Limpio, aburrido, fiable. Luego abres App Store Connect para activar el build y — las ranuras de capturas de pantalla están vacías. Siempre.

Esto sorprende a mucha gente porque EAS da la sensación de hacerlo todo. Compila, firma, envía. ¿Seguro que también gestiona las capturas de pantalla? No lo hace, y la documentación lo dice claramente. Esto no es un bug ni una función que puedas reclamar — simplemente está fuera del alcance de EAS Submit.

Qué hace (y no hace) EAS Submit

EAS Submit es un servicio de entrega de binarios. Sube exactamente una cosa: tu archivo compilado de la app — un .ipa para iOS, un .aab para Android — al pipeline de procesamiento de la tienda. La documentación de Expo es explícita sobre este límite:

«EAS Submit sube tu binario pero no gestiona los metadatos de la ficha de la tienda, las capturas de pantalla ni las notas de la versión.»

Existe una herramienta complementaria, EAS Metadata, que sí puede automatizar partes de tu ficha en la App Store — nombre de la app, subtítulo, descripciones localizadas, palabras clave, URLs de soporte — a partir de un archivo de configuración. Es genuinamente útil y vale la pena configurarla. Pero lee bien su alcance: las capturas de pantalla no están incluidas. EAS Metadata envía texto, no imágenes. Las capturas de pantalla, en ambas tiendas, siguen siendo tuyas para producir y subir.

El problema de las capturas de pantalla con Expo se divide en dos trabajos distintos, y conviene mantenerlos separados mentalmente:

1. Captura — obtener fotogramas sin procesar de las pantallas reales de tu app desde un build.
2. Componer y localizar — convertir esos fotogramas sin procesar en los paneles de marketing con marco, texto y en varios idiomas que las tiendas realmente muestran.

EAS no hace ninguno de los dos. La propia guía de recursos de la tienda de Expo te indica que captures los fotogramas tú mismo y diseñes los paneles en una herramienta como Figma. Veamos ambos trabajos con comandos concretos.

Trabajo 1: capturar fotogramas desde un build de desarrollo o vista previa

Quieres capturas de pantalla de la app real, así que necesitas la app en ejecución en algún lugar donde puedas capturarla. Con Expo eso significa un dev client o un preview build — no Expo Go, ya que Expo Go muestra la interfaz envolvente de Expo y tu configuración nativa puede diferir. Compila y ejecuta en local con los comandos estándar de Expo:

• npx expo run:ios — hace el prebuild nativo de iOS, compila y arranca tu app en el iOS Simulator.
• npx expo run:android — lo mismo para un emulador Android (o un dispositivo conectado).

Con la app visible en el iOS Simulator, la captura es un solo comando desde el terminal de tu Mac:

xcrun simctl io booted screenshot home.png

booted apunta al simulador en ejecución y escribe un PNG de píxel exacto en tu directorio de trabajo. Hay dos flags relevantes para la tienda: --type=png (el predeterminado, y lo que piden las tiendas) y --mask=ignored frente a --mask=black — la máscara controla si el notch y las esquinas redondeadas se renderizan en la imagen. Para subir a la App Store, generalmente querrás los píxeles rectangulares sin máscara y añadir el marco de dispositivo después en la composición, así que la captura sin máscara suele ser el punto de partida correcto.

En Android, captura directamente desde el emulador (o dispositivo) con adb:

adb exec-out screencap -p > home.png

Usa exec-out, no shell screencap. La forma básica con shell hace pasar el PNG por un pseudo-terminal que corrompe el binario en algunos entornos (obtienes un archivo dañado con retornos de carro espurios); exec-out transmite los bytes directamente y es la forma fiable. Si ejecutas varios emuladores, apunta a uno con adb -s <serial> obtenido de adb devices.

Eso es todo el kit de captura manual: dos comandos, uno por plataforma, sin dependencias más allá de Xcode y el Android SDK que ya tienes para un build nativo con Expo.

Trabajo 1, automatizado: Maestro o Detox

Navegar hasta la pantalla correcta a mano y ejecutar esos comandos es perfectamente válido para un puñado de capturas. Cuando tienes ocho pantallas en dos clases de dispositivo, o quieres regenerar las capturas en cada lanzamiento para que nunca queden desfasadas de la interfaz real, automatizas la captura con una herramienta de pruebas end-to-end que pueda manejar la app y capturar fotogramas.

Maestro es la herramienta a la que recurre el propio Expo en sus ejemplos documentados de EAS Workflows. Los flujos son YAML simple, lo que mantiene la barrera de entrada baja. Un flujo que navega hasta una pantalla y la captura tiene este aspecto:

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

Ejecútalo con maestro test flows/home.yaml. El comando takeScreenshot escribe un PNG en el directorio de salida de las pruebas (apunta MAESTRO_TESTS_DIR donde quieras que caigan los recursos). Los mismos flujos se ejecutan en CI con EAS Workflows — el ejemplo documentado de Expo compila un .apk con un perfil de build e2e-test y luego ejecuta un flujo de .maestro/ contra él — así que puedes integrar la captura de pantallas en el mismo job que ejecuta tu suite de pruebas e2e.

Detox es la otra opción consolidada, con una API de JavaScript más estricta y programática:

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

Sé honesto contigo mismo sobre la configuración de Detox con Expo, no obstante. Detox no soporta Expo oficialmente. En la práctica funciona si ejecutas npx expo prebuild para generar los proyectos nativos y compilas un cliente de estilo release (no un dev client) con el bundle JS incluido — y luego apuntas Detox a ese binario. Implica más piezas móviles que el YAML de Maestro, y la ventaja es la API de sincronización y aserciones más estricta de Detox. Si ya usas Detox, reutilízalo para la captura; si estás eligiendo desde cero y tu objetivo son las capturas de pantalla de la tienda, Maestro es el camino más ligero.

Trabajo 1, manual: la opción correcta para lanzamientos poco frecuentes

La automatización se rentabiliza cuando publicas con frecuencia. Si haces uno o tres lanzamientos al año — lo que describe a la mayoría de las apps indie con Expo — configurar flujos de Maestro o una config de Detox para capturar pantallas es trabajo que pagas una vez y apenas amortizas. Para esa cadencia, simplemente:

1. Arranca el build con npx expo run:ios / run:android y cárgalo con datos de demo realistas.
2. Navega hasta cada pantalla clave a mano.
3. Captura cada una con el comando simctl / adb indicado arriba.

Veinte minutos haciendo clic superan a medio día de entorno de pruebas que habrás olvidado cómo mantener para el próximo lanzamiento. No hay ninguna vergüenza en la captura manual — las tiendas no pueden saber cómo se generó el PNG.

Trabajo 2: composición y localización en 50 idiomas

Aquí está la parte que las herramientas de captura deliberadamente no abordan, y es la parte por la que las tiendas realmente te evalúan. Un PNG sin procesar de simctl es la interfaz de tu app sobre un fondo blanco. Lo que posiciona en la búsqueda y convierte en la página del producto es el panel de marketing: la captura de pantalla dentro de un marco de dispositivo, sobre un fondo con identidad de marca, con un texto de una línea que explica por qué importa esa pantalla — normalmente como un carrusel de varios paneles que se lee de izquierda a derecha. Y en la App Store, las capturas de pantalla se localizan por tamaño de dispositivo y por idioma, así que un lanzamiento serio implica docenas de variantes, no cinco.

Este es el lugar concreto donde encaja Mokbi, y vale la pena ser preciso sobre el límite. Mokbi no captura tu app — tú sigues produciendo los fotogramas de origen con los comandos de Expo descritos arriba. Lo que hace es tomar esos fotogramas y permitirte, en el navegador: colocarlos en marcos de dispositivo reales, añadir textos y fondos con degradado, componer carruseles de varios paneles, traducir el texto de los paneles a 50 idiomas en un clic, y exportar por lotes en todas las dimensiones de la App Store y Play Store a la vez. Diseñas gratis con una vista previa con marca de agua; la exportación ilimitada viene con una suscripción — Solo €29.99/mo (1 app) o Studio €49.99/mo (hasta 5 apps), sin compra única. Sustituye el paso de plantilla de Figma al que la guía de Expo hace referencia de pasada — nada más, nada menos.

El flujo de trabajo combinado realista

1. Compila un dev/preview client. npx expo run:ios y npx expo run:android, cargados con buenos datos de demo.
2. Captura los fotogramas de origen. Manualmente con xcrun simctl io booted screenshot y adb exec-out screencap -p, o de forma automatizada con Maestro takeScreenshot / Detox device.takeScreenshot — idealmente en EAS Workflows para que se regeneren en cada lanzamiento.
3. Compón los paneles de marketing. Enmarca, añade textos y organiza el carrusel a partir de esos fotogramas sin procesar.
4. Localiza y exporta por lotes. Traduce los textos a tus idiomas objetivo y exporta todas las dimensiones requeridas para ambas tiendas.
5. Sube los recursos de la ficha. Las capturas de pantalla a App Store Connect y Play Console; combina con EAS Metadata para los campos de texto si lo usas.
6. Envía el binario. eas submit — el único paso que EAS sí gestiona.
7. Próximo lanzamiento: recaptura las pantallas modificadas, vuelve a abrir el proyecto de composición guardado, intercambia los fotogramas y vuelve a exportar. Los textos y traducciones se conservan.

Cuándo puedes prescindir de la automatización

Recurre a la captura con Maestro o Detox cuando el desfase de capturas tiene un coste real: publicas cada semana, tu interfaz cambia constantemente, o mantienes muchas apps y no puedes permitirte imágenes obsoletas en la tienda. En esos casos los fotogramas regenerados en CI se pagan solos y la historia de herramientas de captura de pantalla de React Native (que Expo hereda) merece la inversión.

Para todos los demás — quien publica una vez al trimestre — prescinde de ello. La captura manual con dos comandos de terminal, más la composición y localización en el navegador, te lleva a una ficha pulida y multilingüe en una tarde sin nada que mantener entre lanzamientos. Adapta las herramientas a tu cadencia, no a lo que queda impresionante en un dashboard de CI.

En cualquier caso, la mitad del binario está resuelta: eas submit se encarga de ella. Asegúrate de revisar tus capturas de pantalla contra los requisitos actuales de la tienda antes de subirlas — Apple rechaza una ficha por un solo píxel de diferencia — y el resto del lanzamiento es solo diseño.

Qué leer a continuación

• Para desarrolladores de Expo
• Capturas de pantalla para la App Store con React Native
• Comparación: Mokbi vs Fastlane
• Tamaños de capturas de pantalla de la App Store
• Requisitos de capturas de pantalla de la App Store

Abrir el editor →