Lista de Verificación para el Lanzamiento en la App Store 2025
Ser rechazado por la App Store o Google Play después de semanas de preparación es una de las experiencias más desmoralizadoras en el camino del fundador. La mayoría de los rechazos son evitables con la preparación adecuada.
Requisitos de la App Store de Apple
Metadatos - Nombre de la app: máximo 30 caracteres, sin relleno de palabras clave, sin nombres de marcas competidoras - Subtítulo: máximo 30 caracteres, descriptivo de tu valor principal - Descripción: hasta 4.000 caracteres; las primeras 3 líneas son visibles antes de "más", hazlas contar - Campo de palabras clave: 100 caracteres en total; usa comas, sin espacios, sin palabras repetidas del nombre/subtítulo - URL de la política de privacidad: obligatoria para todas las apps; debe ser accesible sin inicio de sesión - URL de soporte: obligatoria; debe funcionar realmente
Activos visuales - Icono de la app: PNG 1024x1024px, sin esquinas redondeadas (Apple aplica el redondeo), sin transparencia - Capturas de pantalla: obligatorias para iPhone (tamaños 6,7" y 5,5"), iPad si tu app lo admite; muestra la UI real, no solo imágenes de marketing - Vídeo de vista previa de la app: opcional pero muy recomendado; máximo 30 segundos por clase de tamaño
Técnico - Manifiesto de privacidad: obligatorio desde la primavera de 2024; declara todas las API que acceden a datos del usuario - Transparencia de seguimiento de apps: obligatoria si usas seguimiento; solicita permiso con una descripción de uso personalizada - Iniciar sesión con Apple: obligatorio si ofreces cualquier otro inicio de sesión de terceros - Compatibilidad con IPv6: tu app debe funcionar en redes solo IPv6 - Sin caídas al iniciar: el equipo de revisión de Apple rechazará inmediatamente si la app se cae durante la revisión
Contenido y legal - Clasificación de edad: debe reflejar con precisión el contenido (violencia, temas para adultos, juegos de azar) - Sin menciones a competidores de Apple en tu listado de la app store o en la app misma - Sin referencias a "beta", "prueba" o "demostración" en la app o en el listado - Sin enlaces rotos o contenido de marcador de posición visible en la app
Requisitos de Google Play
Metadatos - Descripción corta: 80 caracteres; aparece en los resultados de búsqueda - Descripción completa: hasta 4.000 caracteres - Gráfico de funcionalidades: 1024x500px; se muestra en la tienda y en los resultados de búsqueda de Google - Icono de la app: PNG 512x512px con alfa
Técnico - Nivel de API objetivo: debe apuntar al nivel de API de Android actual (o dentro de una versión principal) - Soporte de 64 bits: obligatorio para todas las nuevas apps - Permisos sensibles: cada permiso que accede a datos sensibles requiere una declaración en el Formulario de Seguridad de Datos - Formulario de Seguridad de Datos: debe declarar con precisión qué datos recopilas, cómo los usas y si los compartes
Política de contenido - Metadatos engañosos: las descripciones y capturas de pantalla deben representar con precisión la funcionalidad - Sin contenido prohibido: Google tiene políticas de contenido más estrictas que Apple en algunas categorías (apps financieras, afirmaciones de salud)
El plazo de envío
Permite de 2 a 5 días para la revisión de la App Store (Apple ha mejorado significativamente los tiempos de revisión, pero sigue siendo variable). Permite de 1 a 3 días para la revisión de Google Play. Nunca planifiques un evento de lanzamiento o un anuncio de prensa para el mismo día del envío.
Envía al menos una semana antes de tu fecha de lanzamiento prevista. Esto te da tiempo para abordar cualquier comentario de rechazo y volver a enviar sin perder tu ventana de lanzamiento.
Qué hace que una captura de pantalla de lanzamiento sea buena
Tus capturas de pantalla son el recurso más influyente de toda tu ficha en la tienda. La mayoría de la gente decide si instala basándose en las dos o tres primeras imágenes, a menudo sin leer una sola palabra de tu descripción. Trátalas como un argumento de venta, no como un álbum de fotos.
Apple ha endurecido sus reglas para las capturas. Para apps nuevas y actualizadas, las imágenes base obligatorias ahora son una captura de iPhone de 6,9 pulgadas (1320 x 2868 píxeles) y, si tu app es compatible con iPad, una captura de iPad de 13 pulgadas (2064 x 2752 píxeles). Apple las reduce automáticamente para dispositivos más pequeños, así que ya no tienes que subir una imagen distinta para cada tamaño de pantalla. Los archivos deben ser PNG o JPEG, en color RGB, sin canal alfa (sin transparencia), y las dimensiones en píxeles deben ser exactas. No hay tolerancia de ni un píxel. Puedes subir entre 1 y 10 capturas por clase de dispositivo.
Google Play es más flexible con las dimensiones. Puedes subir hasta 8 capturas por tipo de dispositivo, con un mínimo de 2 para teléfonos. Las imágenes deben ser JPEG o PNG de 24 bits sin canal alfa, con cada lado entre 320 y 3.840 píxeles. Google también exige un gráfico de funcionalidades de 1024 x 500 píxeles, que aparece en la parte superior de tu ficha y en espacios promocionales.
Más allá de las especificaciones, esto es lo que realmente convierte:
- Empieza por tu mejor funcionalidad. Coloca primero la pantalla que entrega tu valor principal. No malgastes el primer hueco en una pantalla de inicio de sesión o de carga.
- Añade textos breves. Una captura de la interfaz sin más obliga al espectador a esforzarse. Un texto como "Registra cada entrenamiento con un toque" le dice por qué importa esa pantalla. Mantén los textos en unas cinco palabras como máximo.
- Muestra contenido real, no pantallas vacías. Rellena la app con datos realistas. Las listas vacías y el texto de relleno hacen que la app parezca inacabada.
- Cuenta una secuencia. Leídas en conjunto, tus capturas deben guiar al espectador por el recorrido principal: el problema, la acción, el resultado.
- Adáptalas a cada mercado. Si te diriges a España y Alemania, traduce los textos. Las capturas en el idioma del usuario convierten notablemente mejor que las que solo están en inglés.
Una regla que ambas tiendas aplican: tus capturas deben representar la app con fidelidad. Los montajes que muestran funcionalidades que no existen son un motivo habitual de rechazo y minan la confianza incluso cuando logran pasar el filtro.
Durante la espera de la revisión
Una vez que envías, Apple afirma que el 90% de los envíos se revisan en menos de 24 horas. En la práctica aún puede tardar más, sobre todo cerca de lanzamientos importantes de iOS o en periodos festivos. Los tiempos de revisión de Google Play varían de forma similar y pueden alargarse a varios días en un primer envío. Cuenta con esa variabilidad y nunca programes un anuncio de prensa o una campaña de pago para el mismo día en que pulsas enviar.
El periodo de espera no es tiempo muerto. Aprovéchalo para:
- Preparar tus canales de soporte. La URL de soporte que enviaste tiene que estar activa y vigilada desde el primer día. Monta una página de ayuda básica o una bandeja de entrada supervisada.
- Dejar listas tus comunicaciones de lanzamiento sin publicarlas. Redacta tu correo de lanzamiento, tus publicaciones en redes y cualquier contacto con prensa para que estén preparados en el momento en que te aprueben.
- Verificar tus analíticas una vez más. Confirma que los eventos principales de tu embudo se disparan correctamente en la versión de producción, no solo en pruebas.
- No subir nuevas versiones salvo que sea imprescindible. Enviar un binario nuevo mientras hay uno en revisión puede reiniciar tu posición en la cola.
Si tienes un motivo realmente urgente, Apple te permite solicitar una revisión acelerada. Apple indica concretamente dos casos válidos: una corrección de un error crítico (incluye los pasos para reproducir el error) y un evento con fecha límite (incluye el nombre del evento, la fecha y la relación de tu app con él). Úsalo con moderación. Está pensado para emergencias, no para lanzamientos rutinarios.
Cómo gestionar un rechazo
Un rechazo no es un veredicto sobre tu producto. Es una lista de cosas que corregir, y en la mayoría de las apps son cosas pequeñas. La categoría de rechazo más citada es la Directriz 2.1 de Apple, Completitud de la App: caídas, errores, enlaces rotos y contenido de relleno. Casi siempre se resuelven en uno o dos días.
Cuando tu envío no pasa, Apple te indica las directrices concretas que no cumpliste a través de la página de Revisión de Apps en App Store Connect, que funciona como tu centro de resolución. Así es como responder:
- Lee la directriz exacta que se cita. Apple te dice qué regla se incumplió. Búscala en las Directrices de Revisión y aborda ese punto concreto, no lo que tú supongas que es el problema.
- Responde en el centro de resolución. Puedes comunicarte directamente con el equipo de Revisión para pedir aclaraciones o explicar cómo funciona tu app antes de volver a enviar. Una respuesta clara y educada suele resolver malentendidos sin necesidad de una versión nueva.
- Corrige y vuelve a enviar. Una vez resuelto el problema, envía la versión corregida. Cada reenvío pasa de nuevo por revisión.
- Apela solo cuando estés seguro de que Apple se equivocó. Si crees de verdad que tu app cumple y que el revisor la malinterpretó, puedes presentar una apelación ante el Consejo de Revisión de Apps (App Review Board). Apple permite una apelación por envío rechazado, así que aprovéchala bien: da razones concretas, vinculadas a directrices concretas, que expliquen por qué tu app cumple.
Google Play gestiona los rechazos a través de la Play Console, con el motivo y la política infringida indicados en tu bandeja de entrada y en la página de estado de la app. Google también ofrece un proceso de apelación cuando crees que una decisión se tomó por error.
La conclusión práctica: añade un margen a tu calendario. Envía al menos una semana antes de cualquier fecha que hayas comprometido públicamente. Ese único hábito convierte un rechazo de una crisis en una ronda rutinaria de ajustes, que es lo que suele ser.