Cómo cambiar las capturas de pantalla del App Store sin una nueva versión
Quieres cambiar las capturas de una app activa hoy mismo, abres App Store Connect y los campos de captura de la versión actual son de solo lectura. Eso es Apple funcionando como está diseñado, no un fallo. Las capturas son parte de los metadatos de una versión, y una vez que esa versión está aprobada y publicada, sus metadatos quedan congelados. Aquí están las rutas que realmente cambian lo que ven los usuarios, y lo que cuesta cada una en subidas de build y tiempo de revisión.
Por qué los campos están bloqueados
App Store Connect guarda las capturas asociadas a una versión concreta de la app. Cuando tu app está activa, esa versión está en estado publicado y sus capturas, descripción y palabras clave quedan bloqueadas. Para editar cualquiera de ellas trabajas sobre un registro de versión separado y editable, el que está en estado «Prepare for Submission». La ficha activa sigue mostrando las capturas antiguas hasta que se aprueba y se publica una nueva versión encima.
La propia documentación de Apple lo dice sin rodeos: una vez que tu app está enviada y aprobada, debes crear una nueva versión para actualizar las capturas. Así que la pregunta no es «¿puedo editar la versión activa?» (no puedes). Es «¿qué mecanismo produce el cambio más pequeño y rápido?».
Ruta 1: un nuevo registro de versión (la habitual)
Este es el camino que ya conoce la mayoría de desarrolladores. En App Store Connect creas una nueva versión, abres el registro editable «Prepare for Submission», reemplazas las capturas y envías a revisión. El detalle importante: no necesitas lanzar una función nueva ni corregir un error, pero sí necesitas un build adjunto a la versión.
App Store Connect no te ofrecerá el build que está activo en ese momento en el selector de build de la nueva versión. Así que en la práctica haces una de dos cosas: eliges otro build que ya hayas subido (uno sobrante de un TestFlight anterior sirve), o subes un binario nuevo con el mismo código fuente y un número de build incrementado. Ninguna de las dos añade funcionalidad. Pero tiene que haber un build, y toda la versión, capturas incluidas, pasa por App Review. Las nuevas capturas aparecen solo después de que esa versión se apruebe y la publiques.
Usa esta ruta cuando de todos modos vas a cambiar algo más que las capturas, por ejemplo una nueva descripción y palabras clave junto con lo visual, ya que todo puede ir en el mismo envío.
Ruta 2: Product Page Optimization (sin nueva versión, sin nuevo build)
Product Page Optimization (PPO) es la función nativa de pruebas A/B de Apple, y también es la única forma de cambiar capturas y vídeos de vista previa sin nueva versión y sin build alguno. Creas una prueba, añades una variante con tus nuevas capturas y la envías. Apple indica directamente que estos metadatos pueden enviarse sin enviar una nueva versión de tu app.
El matiz que mantiene esto honesto: el nuevo material sigue pasando por App Review antes de que la prueba pueda ejecutarse. La única excepción es reordenar capturas ya aprobadas y publicadas, que no requiere revisión nueva. Todo lo genuinamente nuevo se revisa primero.
PPO está pensada como un experimento, así que los resultados llegan como una mejora estimada en la tasa de conversión, un porcentaje frente a tu página actual con una lectura de confianza sobre los datos. Si solo quieres que las nuevas capturas queden activas para todos en lugar de una prueba medida, puedes crear la prueba, ejecutarla y luego aplicar la variante ganadora a tu página de producto por defecto. Aplicar una variante termina la prueba y publica ese material para todos los usuarios, siempre sin subir ningún binario.
Un límite que vale la pena dejar claro: las capturas y los vídeos de vista previa están libres de build a través de PPO, pero los iconos de app alternativos no. Un icono tiene que estar compilado en el binario que ya está en la tienda, así que un icono realmente nuevo sigue necesitando un build. Deja los iconos fuera de un cambio de capturas sin build.
Ruta 3: Custom Product Pages, para variantes específicas
Si quieres un conjunto de capturas distinto para una audiencia o campaña publicitaria concreta en lugar de un cambio en tu ficha principal, Custom Product Pages te permiten publicar versiones alternativas con su propia URL. Cada variante se revisa por separado y se accede a ella mediante enlace, así que tu página por defecto queda intacta. Es más una herramienta de segmentación que una herramienta de «cambiar la ficha activa», pero conviene tenerla en el mapa cuando decides cómo mover capturas sin un lanzamiento completo de la app.
El único campo que puedes cambiar en cualquier momento: el texto promocional
El texto promocional es el único campo del App Store que puedes editar sin nueva versión y sin App Review. Es un bloque de 170 caracteres que aparece en la parte superior de tu descripción, y las ediciones se publican por sí solas en unas horas (Apple permite hasta 48). No se indexa para el posicionamiento por palabras clave, así que no moverá tu posición en las búsquedas, pero es el lugar adecuado para una frase con caducidad mientras un cambio de capturas sigue en revisión.
Ruta por ruta: build y revisión de un vistazo
Qué ruta elegir
- Solo cambiar capturas, el camino más rápido. Product Page Optimization. Sin build, una sola pasada de revisión sobre el material nuevo, y luego aplicas la variante y queda activa para todos.
- Cambiar capturas más texto o palabras clave. Nuevo registro de versión, así toda la actualización va en un solo envío.
- Visuales distintos para una campaña, no para la página principal. Custom Product Page.
- Una frase que necesitas activa en la próxima hora. Texto promocional, mientras el cambio real de capturas sigue en revisión.
Dónde encaja Mokbi
Mokbi gestiona toda la renovación de capturas de principio a fin. Diseña las nuevas capturas y el gráfico destacado de Google Play, después redacta la ficha completa, título, subtítulo, descripción y texto promocional, y lo traduce todo a 50 idiomas en una sola pasada. Esa es la parte que suele frenar una renovación de capturas, y Mokbi la resuelve en un solo flujo.
Después publica. Mokbi envía la ficha y los recursos terminados directamente a Google Play mediante la Play Developer API, donde quedan activos al instante, y deja todo preparado en App Store Connect listo para que tú lo envíes. Apple exige que ese Submit final y el paso por App Review corran por tu propia cuenta, así que ese clic sigue siendo tuyo, pero el material creativo y los textos ya están en su sitio, en cada idioma, dentro de una nueva versión o de una prueba de Product Page Optimization en el momento en que abres la consola.