La checklist de envío a las tiendas: todos los recursos para ambas tiendas (2026)

Ya has construido la app. Ahora ambas tiendas quieren una pila de recursos y respuestas antes de dejarla pasar, y las dos pilas son distintas. Este es el superconjunto: todos los recursos y campos que piden App Store Connect y Google Play Console, agrupados por tienda, con las reglas de build de 2026 que bloquean la subida antes de que empiece la revisión.

Ya tenemos una checklist solo de capturas de pantalla (enlazada al final). Esta es la lista más amplia: las capturas son un elemento más aquí, junto a iconos, gráficos de funciones, texto de ficha, formularios de privacidad, clasificaciones y los requisitos de build que condicionan la propia subida.

Los requisitos y plazos cambian. Trata cualquier regla con fecha de abajo como un indicador para confirmar en la documentación propia de la tienda el día del envío, no como un hecho fijo.

Paso 0: las dos cuentas de desarrollador

No puedes enviar nada sin una cuenta en cada tienda, y tienen modelos de precio distintos:

• Apple Developer Program — 99 $ al año (USD, cobrado en tu moneda local). Es una membresía recurrente. Si dejas que caduque, tus apps desaparecen de App Store hasta que renueves.
• Google Play Console — 25 $, pago único al registrarte. Único, no reembolsable, sin renovación.
• Verificación de identidad en ambos casos. Las cuentas personales y de organización pasan por verificación. Las cuentas de organización en Google necesitan un número D-U-N-S; Apple verifica la entidad legal para el registro como organización. Reserva unos días para esto antes de planear el lanzamiento.

Apple: qué pide App Store Connect

La build:

• Binario compilado con un SDK actual. Desde abril de 2025, las apps de iOS e iPadOS deben compilarse con el SDK de iOS 18 (Xcode 16) o posterior para poder subirse. Apple ha anunciado que, a partir del 28 de abril de 2026, las subidas necesitarán el SDK de iOS 26 o posterior: confirma qué SDK está vigente en tu fecha de envío.
• Icono de la app dentro de la build. Apple extrae el icono del catálogo de recursos de la app; no hay una subida de icono aparte en App Store Connect. Un icono ausente o mal formado hace fallar la validación al subir.
• ID de paquete único, firma válida y respuestas de cumplimiento de exportación. Las preguntas de cifrado/exportación aparecen al subir; la mayoría de apps responde con una exención estándar, pero hay que contestar.

Recursos visuales:

• Capturas de pantalla para el iPhone de 6.9 pulgadas. Al menos una, hasta diez. Los tamaños aceptados incluyen 1320 × 2868, 1290 × 2796 y 1260 × 2736 (vertical). Apple reescala este conjunto automáticamente para iPhones más pequeños, así que el conjunto de 6.5 pulgadas solo hace falta si te saltas por completo el de 6.9.
• Capturas de pantalla de iPad si la app admite iPad. El conjunto de 13 pulgadas es 2064 × 2752 o 2048 × 2732 (vertical). Obligatorio cuando tu app funciona en iPad.
• Vídeo de App Preview opcional por tamaño de dispositivo, de 15 a 30 segundos.

Texto de la ficha:

• Nombre de la app (hasta 30 caracteres) y subtítulo (hasta 30).
• Palabras clave: un único campo de 100 caracteres separado por comas que nunca se muestra a los usuarios pero impulsa la búsqueda.
• Descripción (hasta 4.000 caracteres) y texto promocional (hasta 170, editable sin una nueva build).
• URL de soporte, y una URL de marketing si quieres una.

Legal, privacidad y clasificación:

• URL de política de privacidad. Obligatoria para toda app.
• Respuestas de App Privacy: la "etiqueta nutricional". Declaras qué datos recopilan tu app y sus SDKs de terceros, y cómo se usan. Estas respuestas son obligatorias para enviar y se muestran como la etiqueta de privacidad en tu ficha.
• Clasificación por edad. Se responde mediante un cuestionario. Apple pasó a un sistema de clasificación por edad más granular (con niveles 13+, 16+ y 18+) que se muestra en dispositivos con iOS 26 o posterior, así que revisa tus respuestas si clasificaste una app por última vez con el esquema anterior.
• Categoría principal (y secundaria opcional), además de una vía para eliminar la cuenta dentro de la app si esta admite la creación de cuentas.

Google: qué pide Play Console

La build:

• Un Android App Bundle (.aab), no un APK, para apps nuevas.
• Nivel de target API. Actualmente, las apps nuevas y las actualizaciones deben apuntar a Android 15 (nivel de API 35) o superior. Google ha dicho que, a partir del 31 de agosto de 2026, las apps nuevas y las actualizaciones deberán apuntar a Android 16 (nivel de API 36); verifica el nivel vigente cuando envíes.
• Build de lanzamiento firmada, normalmente mediante Play App Signing.

Recursos visuales:

• Icono de la app: 512 × 512 px, PNG de 32 bits, menos de 1 MB.
• Gráfico de funciones: 1024 × 500 px, JPEG o PNG de 24 bits sin alfa. Es un recurso de ficha obligatorio en Play, sin equivalente en Apple, y es el banner que se muestra en la parte superior de tu ficha.
• Al menos 2 capturas de pantalla de móvil (hasta 8). JPEG o PNG de 24 bits, cada lado entre 320 y 3.840 px, relación de aspecto 16:9 o 9:16. Las capturas de tablet y otros formatos son opcionales salvo que apuntes a esos dispositivos.
• Vídeo promocional opcional como URL de YouTube.

Texto de la ficha:

• Nombre de la app (hasta 30 caracteres).
• Descripción breve (hasta 80): la primera línea que leen los usuarios.
• Descripción completa (hasta 4.000).

Legal, privacidad y clasificación:

• URL de política de privacidad. Obligatoria.
• El formulario de seguridad de datos de Google (Data safety). El equivalente de Google a la etiqueta de privacidad de Apple: declaras qué datos recopilas, compartes y cómo se gestionan. Obligatorio antes de publicar, y debe coincidir con el comportamiento real de tu app.
• Cuestionario de clasificación de contenido (IARC). Genera clasificaciones por edad específicas de cada región a partir de tus respuestas.
• Categoría de la app, además de declaraciones de público objetivo y anuncios. Si parte del público son menores, se aplican requisitos adicionales.

Las reglas de 2026 que rechazan una build antes de la revisión

No son cuestión de pulido: bloquean la subida o el lanzamiento directamente, así que conviene confirmarlas primero:

• El SDK mínimo de Apple. Las subidas han necesitado el SDK de iOS 18 (Xcode 16) desde abril de 2025, y el SDK de iOS 26 se convertirá en el mínimo hacia el 28 de abril de 2026 según el anuncio de Apple. Compila con un SDK antiguo y App Store Connect rechaza el binario al subirlo.
• El nivel de target API de Google. Las apps nuevas y las actualizaciones apuntan hoy a Android 15 (API 35), y pasarán a Android 16 (API 36) a partir del 31 de agosto de 2026 según el calendario declarado por Google. Un nivel de target demasiado bajo bloquea el lanzamiento.
• La puerta de pruebas cerradas de Google para cuentas personales. Las cuentas de desarrollador personales creadas después del 13 de noviembre de 2023 deben ejecutar una prueba cerrada con al menos 12 probadores inscritos durante 14 días consecutivos antes de poder solicitar acceso a producción. (Google bajó esta cifra desde 20 probadores a finales de 2024.) Las cuentas de organización verificadas están exentas. Esto es lo que más sorprende a los desarrolladores solitarios: añade dos semanas mínimas entre "la app está lista" y "la app está en vivo", así que empieza la prueba cerrada pronto.

La revisión previa compartida (ambas tiendas)

Unas cuantas comprobaciones aplican en ambos lados y son fáciles de saltarse con las prisas del lanzamiento:

• Los textos de las capturas de pantalla en el idioma de cada locale. Los textos en inglés en una ficha alemana o japonesa se marcan. El idioma del texto y el locale de la ficha deben coincidir.
• Los recursos y el texto coinciden con la app. Si una captura de pantalla o una descripción muestra una función, la app publicada debe tenerla de verdad. Ambas tiendas rechazan por metadatos que exageran la app.
• Sin precios ni URLs externas incrustadas en las capturas. Los precios van en la ficha de la tienda, no en las imágenes; las capas de "visita nuestro sitio" provocan rechazos.
• Las declaraciones de privacidad coinciden con la realidad. Tanto la etiqueta de privacidad de Apple como el formulario de seguridad de datos de Google deben reflejar lo que hacen realmente tu código y tus SDKs.
• Una cuenta de prueba funcional, si la app está tras un login, entregada al revisor en las notas de revisión.

Dónde encaja Mokbi

La mayor parte de esta checklist es cosa tuya: la cuenta, la build, las respuestas de privacidad, las clasificaciones. Mokbi cubre los recursos visuales y de texto, que es la parte que más horas consume cuando lo haces a mano para dos tiendas y muchos idiomas.

• Los recursos visuales. Produce las capturas de pantalla para ambas tiendas en los tamaños requeridos, y el gráfico de funciones de Play, a partir de un solo proyecto, para que no recortes de nuevo el mismo arte entre clases de dispositivo.
• El texto de la ficha. Redacta tu nombre, subtítulo, descripción y descripción breve, y luego traduce toda la ficha a 50 idiomas, para que cada locale se publique con textos y copy a juego.
• Publicar la ficha terminada. Mokbi envía por ti los recursos y el texto de la tienda ya terminados: directo a Google Play a través de la Play Developer API, y preparado en App Store Connect como una versión lista para que tú la envíes. Apple exige ese último paso de Enviar y revisión de tu parte; esa es una regla de Apple, no una limitación de Mokbi.

El objetivo no es sustituir la checklist, sino quitarle las columnas de recursos y traducción para que el resto sea una tarde más corta.

Qué leer a continuación

• Los requisitos de ficha de Google Play, recurso por recurso
• Qué puedes cambiar sin una versión nueva
• La checklist solo de capturas de pantalla antes de enviar

Abrir el editor →