Guideline 2.3.3: Apple rechazó tus capturas, cómo rehacerlas

Un rechazo «Guideline 2.3.3 - Performance - Accurate Metadata» significa que Apple considera que tus capturas no muestran la app mientras se usa. La regla tiene una cifra: para cada tipo de dispositivo, más de la mitad de las capturas deben mostrar la pantalla real de la app en uso. El rechazo afecta a la ficha, no al binario: reemplazas las capturas y vuelves a enviar el mismo build.

Me pasó el 27 de octubre de 2026 con Vigie, mi app de seguimiento de ASO. Mis capturas mostraban tarjetas de interfaz rediseñadas alrededor de una mascota, sin teléfono. Apple las rechazó. Esta guía recoge el mensaje que recibí, lo que Apple llama «app in use», lo que pasa y lo que no, y luego la checklist que aplico desde entonces. Las reglas citadas vienen de las páginas oficiales de Apple, revisadas el 3 de noviembre de 2026.

El mensaje de Apple, palabra por palabra

El mensaje empieza con el título de la regla y luego nombra el tamaño de dispositivo afectado. Para Vigie, la frase que contenía el rechazo era esta:

The 6.7-inch iPhone screenshots do not show the actual app in use.

Otros rechazos 2.3.3 detallan lo que espera el revisor. Este fue publicado en los foros de Apple en octubre de 2024 por un desarrollador cuyos espacios de iPad mostraban un marco de iPhone. Este es el fragmento que enumera los requisitos, palabra por palabra:

Some or all of the provided screenshots do not sufficiently show
the app in use. Screenshots should highlight the app's core concept
to help users understand the app's functionality and value.

- Marketing or promotional materials that do not reflect the UI
  of the app are not appropriate for screenshots.
- The majority of the screenshots should highlight the app's main
  features and functionality.
- Confirm that the app looks and behaves identically in all
  languages and on all supported devices.
- Make sure that the screenshots show the app in use on the
  correct device, unless they are included to demonstrate that
  the app can be used on multiple Apple platforms. For example,
  iPhone screenshots should be taken on iPhone, not on iPad.

En resumen: una imagen publicitaria que no muestra la interfaz de la app no tiene lugar entre las capturas. La mayoría debe mostrar las funciones principales. Y cada captura muestra el dispositivo correcto: una captura de iPhone se toma en iPhone, no en iPad, salvo para mostrar que la app funciona en varias plataformas de Apple.

Lo que Apple llama «app in use»

El texto de la guideline 2.3.3 es corto: «Screenshots should show the app in use, and not merely the title art, login page, or splash screen.» Las capturas deben mostrar la app en uso, no solo el logo, la pantalla de inicio de sesión o la pantalla de arranque. El mismo texto permite textos e imágenes superpuestos.

La página de ayuda de App Review sobre la 2.3.3 precisa cómo se evalúa. Apple evalúa la serie de cada tipo de dispositivo y solo aprueba si más de la mitad de las capturas muestran la app en uso. Cada idioma se evalúa por separado. La página también enumera lo que hay que evitar:

• capturas que solo muestran una página de inicio de sesión o una pantalla de arranque;
• una interfaz que no corresponde a la real, o una imagen publicitaria engañosa;
• decoraciones que tapan la app, o el hardware solo, sin interfaz detrás.

En pocas palabras, «en uso» significa: la interfaz real de tu build, con contenido, haciendo aquello para lo que la gente descarga la app. Un título corto sobre una pantalla real sigue siendo una captura en uso.

Cuántas capturas deben mostrar la app

Apple da dos ejemplos: con tres capturas, dos deben mostrar la app. Con cuatro, tres. El resto se deduce de la misma regla: más de la mitad.

Capturas enviadas	Mínimo en uso	Imágenes de marketing posibles
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
8	5	3
10	6	4

La cuenta se hace por tipo de dispositivo y por idioma. Una sola captura por dispositivo basta, si muestra la app en uso. Según las especificaciones de capturas, Apple exige al menos una captura para el iPhone con Dynamic Island de pantalla mediana, y acepta hasta 10 por tamaño. Si tu interfaz es igual en todos los tamaños y en todos los idiomas, basta con la resolución más alta exigida: App Store Connect la reduce para los tamaños más pequeños. Las dimensiones exactas están en el tamaño de las capturas del App Store.

Lo que pasa y lo que no

Captura	Veredicto	Lo que decide
Pantalla real de la app, título corto encima	Pasa	La 2.3.3 permite el texto añadido
Pantalla real dentro de un iPhone	Pasa	La interfaz real, en el dispositivo correcto
Logo, pantalla de arranque o inicio de sesión solos	Rechazada	Citado palabra por palabra en la regla
Imagen de marketing sin interfaz	Tolerada en minoría	Solo si la mayoría muestra la app
Tarjetas de interfaz rediseñadas, sin la app	Rechazada	Mi rechazo del 27 de octubre de 2026
Pantalla maquetada que no existe en el build	Rechazada	Interfaz que no corresponde a la real
Teléfono vacío o decorado sin interfaz detrás	Rechazada	Incluido en lo que hay que evitar
Captura de iPhone en los espacios de iPad	Rechazada	Dispositivo equivocado, según el rechazo del foro
Imagen que se extiende sobre dos capturas	Pasa	Permitido, mientras la app siga visible
Barra de estado de otra plataforma	Rechazada, por la 2.3.10	Apple la remite a la guideline 2.3.10

Apple no impone un marco de teléfono. Basta con una captura de la app a pantalla completa. El marco tiene una ventaja: deja claro, a primera vista, que la imagen es la app.

Mi caso: Vigie rechazada el 27 de octubre de 2026

Para la versión 1.1 de Vigie, seguí una tendencia de los estudios de capturas: un mural continuo, una mascota y tarjetas de interfaz flotantes en lugar de un teléfono completo. Las tarjetas estaban rediseñadas para la ocasión, con apps ficticias. Se veía bonito. No era la app.

El revisor escribió que las capturas del iPhone de 6.7 pulgadas no mostraban la app en uso. No lo discutí: tenía razón. Rehice toda la serie con una regla sencilla:

1. Cada panel muestra un iPhone con una captura nativa del simulador, pegada al píxel, sin retocar la interfaz.
2. Una tarjeta ampliada solo aparece además del teléfono, nunca en su lugar, y está recortada de esa misma captura.
3. El decorado se queda alrededor, nunca encima de la pantalla.

Este rechazo no pedía ningún build nuevo. Reemplacé las capturas y volví a enviar la misma versión esa misma noche. Después cambié de build para corregir un título dentro de la app, sin relación con las capturas. Vigie 1.1 estaba a la venta el 29 de octubre con esta serie.

Una tarjeta rediseñada, aunque sea fiel, no es la app. El revisor quiere ver la pantalla que el usuario tendrá en sus manos.

Corregir sin un build nuevo

1. Lee el mensaje completo. Indica qué tamaño de dispositivo está afectado, a veces qué idioma. Todas las series afectadas deben cambiar, no solo la primera.
2. Rehaz las capturas desde el build enviado. En simulador o en dispositivo, con contenido real. Más de la mitad en uso, para cada dispositivo y cada idioma.
3. Reemplaza las capturas en App Store Connect. Según la ayuda sobre la gestión de recursos, es posible cuando la app está en uno de estos estados: Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected o Developer Rejected.
4. Vuelve a enviar según el estado que aparece. Para Metadata Rejected, la tabla de estados dice: lee el mensaje, corrige los metadatos y luego responde al mensaje de App Review. Si el envío muestra Unresolved Issues, sigue el procedimiento de Apple: en Apps, View App Review Issues & Messages, luego Resolve, Edit en el elemento rechazado, Add for Review y, por último, Resubmit to App Review.
5. No toques más las capturas una vez enviadas. Según la misma tabla de estados, en Waiting for Review no puedes ni subir ni modificar capturas.

Cada elemento rechazado solo se modifica una vez antes del reenvío: revisa tu nueva serie antes de hacer clic. La respuesta que yo le escribiría al revisor, en inglés:

Hello App Review team,

Thank you for your feedback regarding Guideline 2.3.3.

We replaced the [6.9-inch iPhone] screenshots in all localizations.
Each screenshot now shows the actual app interface, captured from
the submitted build: [main screen], [key feature], [result screen].

The build is unchanged.

Best regards,
[Your name]

El tono y la forma de una buena respuesta están detallados en responder a App Review.

La checklist antes de enviar tus capturas

• Más de la mitad de las capturas de cada tipo de dispositivo muestran la pantalla real, con contenido.
• La misma regla se cumple en cada idioma, no solo en inglés.
• Ninguna captura muestra solo el logo, la pantalla de arranque o el inicio de sesión.
• La interfaz mostrada existe en el build enviado, idéntica.
• Los títulos y el decorado dejan la interfaz legible.
• Las capturas de iPhone se toman en iPhone, las de iPad en iPad.
• Ningún rastro de otra plataforma, ni siquiera en la barra de estado.
• Si tu app tiene modo oscuro, una captura lo muestra: la página de ayuda de Apple lo recomienda.
• Los archivos están en JPEG o PNG, sin transparencia.

Apple también recuerda, en su página sobre la ficha de producto, que las primeras capturas pueden aparecer en los resultados de búsqueda. Para mí, una captura que muestra claramente la app en acción vende más que un eslogan. Los demás motivos de rechazo de la ficha están en por qué Apple rechaza una app.

Capturas que pasan a la primera

El App Store Screenshots Kit reúne mis plantillas y el skill que crea tus capturas a partir de las pantallas reales de tu app, en los tamaños que pide Apple. Si acaban de rechazar tu ficha, el Review Kit contiene mi checklist antes del envío, mis rechazos corregidos y las plantillas de respuesta al revisor. El proceso completo está en la página app rechazada por Apple.

Si estás preparando tu primer lanzamiento, haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist contra rechazos de Apple.

Preguntas frecuentes

¿Qué significa «Guideline 2.3.3 - Performance - Accurate Metadata»?

Es el título del rechazo por capturas que no muestran la app en uso. Apple considera que demasiadas capturas son imágenes de marketing, pantallas de arranque o interfaces que no son las de la app. El mensaje suele indicar el tamaño de dispositivo afectado.

¿Hace falta un build nuevo después de un rechazo 2.3.3?

No. El rechazo afecta a la ficha del App Store. Reemplazas las capturas en App Store Connect y vuelves a enviar la misma versión respondiendo al mensaje de App Review.

¿Cuántas capturas deben mostrar la app en uso?

Más de la mitad, para cada tipo de dispositivo y en cada idioma. Con tres capturas, dos deben mostrar la app. Con cuatro, tres. Una sola captura basta si muestra la app en uso.

¿Se puede poner texto de marketing en las capturas del App Store?

Sí. La guideline 2.3.3 permite textos e imágenes superpuestos. No deben ocultar la interfaz, y la mayoría de las capturas debe seguir mostrando la app en uso.

¿Hace falta un marco de iPhone alrededor de las capturas?

No, Apple no lo exige: una captura de la app a pantalla completa pasa. El marco ayuda a entender que la imagen es la app. Debe ser el del dispositivo correcto: nunca un marco de iPhone en una captura destinada al iPad.

¿Se pueden modificar las capturas mientras la app espera la revisión?

No. En estado Waiting for Review, App Store Connect no permite ni subir ni modificar capturas. Para cambiarlas, retira el envío de la revisión o espera la decisión.