# Guideline 2.3.3: Apple rechazó tus capturas, cómo rehacerlas > Guideline 2.3.3: más de la mitad de tus capturas deben mostrar la pantalla real de la app en uso. Qué pasa, qué se rechaza y cómo corregirlo sin nuevo build. Página original: [Guideline 2.3.3: Apple rechazó tus capturas, cómo rehacerlas](https://devoria.fr/es/blog/guideline-2-3-3-capturas-rechazadas-apple) Autor: [Mehdi Azizi](https://devoria.fr/es/mehdi-azizi) Publicación: 2026-11-04 Última revisión del contenido: 2026-11-04 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: ```text 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](https://developer.apple.com/forums/thread/765166) 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: ```text 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](https://developer.apple.com/app-store/review/guidelines/#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](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) 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](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), 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](https://devoria.fr/es/blog/tamano-capturas-app-store-medidas). ## 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](https://devoria.fr/es/blog/guideline-2-3-10-app-rechazada-metadatos) | 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](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets), 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](https://developer.apple.com/help/app-store-connect/reference/app-information/app-and-submission-statuses) 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](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/manage-a-submission-with-unresolved-issues/): 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: ```text 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](https://devoria.fr/es/blog/resolution-center-apple-responder-rechazo-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](https://developer.apple.com/app-store/product-page/), 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](https://devoria.fr/es/blog/rechazo-apple-por-que-rechazan-tu-app). ## Capturas que pasan a la primera El [App Store Screenshots Kit](https://devoria.fr/es/kits/app-store-screenshots) 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](https://devoria.fr/es/kits/app-review) 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](https://devoria.fr/es/expertise/app-rechazada-por-apple). Si estás preparando tu primer lanzamiento, [haz tu diagnóstico gratuito](https://devoria.fr/es/diagnostic): 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. ## Tu proyecto [Review Kit](https://devoria.fr/es/kits/app-review): Mi checklist de revisión de App Store, mis rechazos de Apple corregidos, la de Google Play y tres skills de Claude Code. 49 €. [iOS & Android Kit](https://devoria.fr/es/kits/ios): Crea tu app para iPhone y Android con Claude Code: el código base de mis apps, el camino hasta las tiendas y todos los kits. 99 €. [Diagnóstico: lo que te separa de tu app para iPhone](https://devoria.fr/es/diagnostic): 7 preguntas, 60 segundos: descubre qué te frena de verdad para publicar tu app para iPhone, tu ruta en 4 etapas y el kit ideal para ti.