Publicar en la App Store y Google Play: la checklist completa 2026

Construir la aplicación es la parte que todo el mundo planifica. Publicarla es la que sorprende, porque es sobre todo trabajo administrativo con reglas estrictas y ciclos de respuesta asíncronos. Un rechazo que podría haber evitado en diez minutos le cuesta una semana de calendario. Esta guía recorre las dos tiendas en el orden en que realmente las necesita: cuentas, recursos, declaraciones, envío, revisión y qué hacer el día después del lanzamiento.

Antes de nada: las dos cuentas

Ambas tiendas exigen una cuenta de desarrollador de pago, y ambas tardan en activarse. Empiece este paso antes de terminar la app, no después.

Una decisión que conviene tomar pronto: regístrese a nombre de su empresa, no del suyo personal. Mover una app entre cuentas más tarde es posible pero tedioso, y un nombre personal visible en la ficha resta credibilidad ante clientes profesionales.

Los materiales que le van a pedir

Ambas tiendas piden prácticamente lo mismo, con tamaños distintos y distinta tolerancia a la improvisación. Prepárelo todo de una sentada en lugar de descubrir cada requisito a mitad del envío.

• El icono. Un cuadrado en alta resolución, sin transparencia y sin esquinas redondeadas por su cuenta: las tiendas aplican la máscara. Evite el texto pequeño, ilegible a tamaño real.
• Las capturas de pantalla. Varios tamaños de dispositivo, incluido al menos un teléfono grande. Son la mayor palanca de la tasa de instalación: anótelas con un beneficio breve en lugar de subir capturas en crudo.
• Título y subtítulo. Cortos, e indexados por el buscador de la tienda. Ponga en el título la palabra clave que la gente escribe, no una frase de marca ingeniosa.
• La descripción. Solo se leen de verdad las dos primeras líneas. Empiece por lo que la app hace por el usuario, no por la historia de su empresa.
• Gráfico destacado (Google Play). Un banner ancho que aparece en varias ubicaciones. Mantenga el texto esencial lejos de los bordes, que se recortan.
• Cuestionario de clasificación por edad. Responda con honestidad. Una incoherencia entre sus respuestas y el contenido real es la forma más segura de que le retiren la app tras el lanzamiento.

Privacidad: lo que hace que rechacen las apps

Ambas tiendas exigen ya un inventario explícito y estructurado de qué datos recoge y para qué. Apple lo llama etiquetas de privacidad; Google, sección de Seguridad de los datos. Son formularios distintos, con vocabulario distinto, y los dos deben coincidir con lo que su app hace realmente.

• Una URL de política de privacidad accesible. Obligatoria en ambas, publicada antes del envío y describiendo su app de verdad, no una plantilla genérica.
• Un inventario de datos exacto. Enumere cada categoría que recoge, incluida la que capturan sus SDK de analítica o de informes de fallos. Lo que recogen las bibliotecas de terceros por usted cuenta como suyo.
• Eliminación de cuenta. Si el usuario puede crear una cuenta en la app, debe ofrecer una forma de eliminarla, accesible desde dentro de la app. Es uno de los rechazos tardíos más frecuentes.
• Permiso de seguimiento en iOS. Si rastrea usuarios a través de apps o sitios de otras empresas, debe pedir permiso mediante el aviso del sistema. Saltárselo implica la retirada.

Canales de prueba: nunca envíe directo a producción

Ambas tiendas ofrecen un circuito de preproducción, gratuito en los dos casos. Úselo: un fallo encontrado por diez testers no cuesta nada, y el mismo fallo encontrado por un revisor le cuesta un ciclo de revisión.

• TestFlight (Apple). Distribución casi inmediata a testers internos, o a testers externos tras una revisión más ligera. Los builds caducan a los 90 días.
• Pruebas internas, cerradas y abiertas (Google). La prueba interna es casi instantánea. Una prueba cerrada con un grupo pequeño merece al menos una semana antes de producción, y las cuentas de desarrollador personales nuevas pueden estar obligadas a realizarla.

Sea cual sea el canal, pruebe como mínimo en un Android pequeño y antiguo y en un iPhone reciente. Esos dos cubren casi todas las sorpresas de diseño y rendimiento.

El envío, paso a paso

• 1. Crear la ficha de la app. Reserve el nombre y el identificador de bundle o paquete. Ese identificador es definitivo: no se cambia tras publicar, solo se publica una app nueva.
• 2. Subir un build firmado. Apple exige un archivo firmado enviado desde macOS. Google exige un Android App Bundle y una clave de firma que no debe perder jamás: active Play App Signing para que Google conserve una copia.
• 3. Rellenar la ficha de tienda. Título, descripción, capturas, categoría, datos de contacto y URL de soporte.
• 4. Completar las declaraciones. Privacidad, seguridad de datos, clasificación por edad, publicidad, cumplimiento de exportación y el cuestionario de permisos si usa alguno sensible.
• 5. Dar a los revisores una cuenta funcional. Si su app tiene inicio de sesión, facilite credenciales de prueba y, si hace falta, una nota breve explicando cómo llegar a la funcionalidad principal. Omitirlo es la causa número uno de rechazos inútiles.
• 6. Enviar y fijar la estrategia de lanzamiento. Elija publicación manual si quiere coordinar una fecha, y use despliegue progresivo en Google Play para que un build defectuoso llegue al 5 % de los usuarios y no a todos.

Los motivos de rechazo que se encontrará de verdad

Los rechazos son normales, también en equipos con experiencia. Casi todos caben en un puñado de categorías.

• El revisor no pudo iniciar sesión. Credenciales de demostración ausentes o caducadas, o un acceso que exige un código enviado a su teléfono.
• Enlaces rotos o cierres inesperados. Una URL de soporte caída o un fallo en la versión del dispositivo del revisor. Pruebe todos los enlaces de la ficha antes de enviar.
• «Funcionalidad insuficiente». Apple rechaza las apps que son un sitio web envuelto sin valor nativo. Si entrega una WebView, añada funciones reales del dispositivo y comportamiento sin conexión.
• Pagos fuera de la tienda. Vender contenido digital que se consume dentro de la app suele exigir compra integrada. Los bienes físicos y los servicios del mundo real, no.
• Declaración de privacidad incoherente. Declara que no recoge nada, pero un SDK de analítica captura un identificador de dispositivo.
• Problemas de metadatos. Capturas que ya no corresponden a la app, nombres de competidores en la descripción o un texto provisional que se quedó puesto.

Cuando le rechacen, lea el número exacto de la directriz citada, corrija solo eso y responda en el centro de resolución con una explicación breve y factual. Discutir rara vez ayuda; una respuesta precisa, casi siempre.

Después del lanzamiento: los primeros treinta días

Estar publicado es el principio del trabajo, no el final. El primer mes decide cómo le posicionan las tiendas y si los primeros usuarios se quedan.

• Vigile la tasa de fallos por dispositivo. Ambas consolas la reportan. Por encima del 1 % de las sesiones, su posicionamiento y sus valoraciones se resienten.
• Responda a cada reseña, rápido. Las respuestas públicas cambian visiblemente cómo se lee una ficha, y una queja resuelta suele convertirse en una nota mejorada.
• Itere sobre la ficha, no solo sobre la app. Cambiar la primera captura o el subtítulo mueve la tasa de instalación más que una función nueva.
• Publique una actualización pequeña cada pocas semanas. La frescura es una señal de posicionamiento, y un ritmo constante hace previsibles los plazos de revisión.
• Traiga su propio tráfico. El buscador de la tienda no le descubrirá solo. Su web, su lista de correo y sus clientes actuales son el canal de lanzamiento.

Dónde encaja Cadrant

Cadrant interviene en lo que precede al envío: poner una app real y funcional en manos de usuarios lo bastante rápido como para saber qué merece publicarse. Describe sus pantallas, sus datos y sus roles de usuario en lenguaje natural, itera sobre una app viva en horas en vez de meses, y la base de datos permanece en su propio proyecto de Supabase. Cuando el producto se ha ganado la razón con usuarios reales, afronta el proceso de tienda con un alcance estable en lugar de adivinar.

Ese orden importa. La mayoría de quienes publican por primera vez envían un alcance que nadie ha probado y luego gastan los ciclos de revisión corrigiendo problemas de producto en vez de problemas de tienda.

En resumen

Publicar es un proyecto administrativo con una dependencia de código. Abra pronto las dos cuentas de desarrollador, prepare icono, capturas, descripción, política de privacidad y declaraciones de datos en una sola pasada, use un canal de prueba real antes de producción y dé a los revisores una cuenta funcional con instrucciones claras. Con eso, la revisión suele ser la parte fácil.