Cómo publicar una app en App Store y Google Play

Programar la app es la mayor parte del trabajo, pero publicarla es un proyecto aparte. Cada tienda tiene sus propias cuentas, trámites, reglas de prueba y revisores, y la mayoría de los primeros lanzamientos se retrasan por estos pasos, no por el código. Esta guía explica cómo funciona el proceso en 2026 y dónde suelen atascarse los fundadores.

Paso 1: Crea tus cuentas de desarrollador

Hazlo primero, antes de terminar la app. La aprobación de la cuenta es el paso que no puedes acelerar, y puede tardar desde un día hasta varias semanas.

Apple Developer Program

• Costo: USD 99 al año (Apple exime de la tarifa a algunas organizaciones sin fines de lucro, instituciones educativas y entidades de gobierno).
• Persona física u organización: una cuenta individual muestra tu nombre personal como vendedor. Una cuenta de organización muestra el nombre de tu empresa, pero necesitas una entidad legal y un número D-U-N-S (gratuito, lo emite Dun & Bradstreet, aunque puede tardar una semana o más).
• Quién debe ser el titular: la empresa. Si una agencia desarrolla tu app, igual debe publicarse en tu cuenta, con la agencia agregada como miembro del equipo. Transferir una app entre cuentas después es posible, pero engorroso.
• Distribución en la UE: Apple te pide declarar tu condición de comerciante según la Ley de Servicios Digitales de la UE, y los datos de contacto de los comerciantes se muestran públicamente.

Google Play Console

• Costo: una tarifa de registro única de USD 25.
• Verificación de identidad: Google verifica tu nombre legal y tu dirección, y las cuentas de organización también necesitan un número D-U-N-S. Cuenta con unos días, a veces más.
• El requisito de prueba cerrada: las cuentas personales creadas después de noviembre de 2023 deben hacer una prueba cerrada antes de poder publicar en producción. Al momento de escribir esto, eso significa al menos 12 testers inscritos durante al menos 14 días seguidos (Google ya ha cambiado la cifra antes). Las cuentas de organización no tienen este requisito.

Paso 2: Prepara los recursos y declaraciones de la tienda

Ambas tiendas piden más o menos el mismo material. Reúnelo en una carpeta compartida mientras se cierra el desarrollo, porque si falta cualquiera de estas piezas no podrás enviar la app.

• Ícono de la app: 1024×1024 px para Apple (sin transparencia) y 512×512 px para Google Play, más un gráfico destacado de 1024×500 para Play.
• Capturas de pantalla: Apple pide un juego para el tamaño de pantalla de iPhone más grande (y de iPad si lo soportas) y las adapta a los dispositivos más pequeños. Google exige al menos dos capturas de teléfono, más capturas de tablet si quieres verte bien en tablets.
• Nombre, subtítulo y descripción: consulta la sección de ASO más abajo para los límites de caracteres.
• URL de la política de privacidad: obligatoria en ambas tiendas, para cualquier app. Debe ser una página web activa que coincida con lo que la app realmente recopila.
• Declaraciones de privacidad: la sección App Privacy de Apple (la "etiqueta nutricional") y el formulario de Seguridad de los datos de Google. Ambos preguntan qué datos recopilas, para qué y si están vinculados al usuario o se usan para rastreo. Los SDK de terceros (analítica, reportes de fallos, anuncios) también cuentan.
• Eliminación de cuenta: si los usuarios pueden crear una cuenta, ambas tiendas exigen una forma de eliminarla, dentro de la app y (en el caso de Google) también mediante un enlace web.
• Clasificación por edad: Apple tiene su propio cuestionario y Google usa el cuestionario de IARC. Responde con honestidad: las clasificaciones que no coinciden son una causa común de problemas en la revisión.
• URL de soporte y correo de contacto.

Redacta la política de privacidad y llena las declaraciones a partir de la misma lista de SDK y flujos de datos. Si la política dice una cosa y el formulario otra, los revisores pueden marcarlo, y lo hacen.

Paso 3: Compila y firma la versión de producción

Una build para la tienda es un binario firmado y configurado para producción. No se sube código fuente.

• iOS: archiva la app en Xcode y súbela a App Store Connect, o deja que un servicio en la nube lo haga por ti. Apple gestiona los certificados de distribución y los perfiles de aprovisionamiento, y la firma automática de Xcode cubre la mayoría de los casos.
• Android: Google Play exige un Android App Bundle (AAB) para apps nuevas, no un APK. Lo firmas con una clave de carga, y la Firma de apps de Play guarda la clave de firma real de la app. Respalda tu clave de carga y su contraseña, porque perderlas significa abrir una solicitud de soporte con Google.
• React Native / Expo: usamos EAS Build para generar ambos binarios en la nube y EAS Submit para enviarlos a App Store Connect y a Play Console. Elimina casi todos los dolores de cabeza de la firma local y hace que los lanzamientos sean repetibles.
• Números de versión: cada carga necesita un número de build mayor que el anterior. Automatízalo desde el principio.
• Nivel de API objetivo: Google exige que las apps nuevas y las actualizaciones apunten a un nivel de API de Android reciente, normalmente dentro de aproximadamente un año desde la última versión. Revisa la fecha límite vigente antes de enviar.

Si todavía estás decidiendo cómo construir para ambas plataformas, nuestras páginas de desarrollo de apps iOS y desarrollo de apps Android explican cómo llevamos una sola base de código a las dos tiendas.

Paso 4: Prueba con TestFlight y los canales de prueba de Play

Nunca dejes que un revisor de la tienda sea la primera persona fuera de tu equipo en instalar la build de producción. Ambas tiendas ofrecen distribución beta gratuita:

Prueba en dispositivos reales y antiguos, con redes lentas y con una instalación limpia (sin sesión guardada). Esto último detecta una cantidad sorprendente de fallos que, si no, encontrarían los revisores por ti.

Paso 5: Envía la app a revisión

Apple revisa cada build y cada actualización, y la mayoría se revisa en uno o dos días. La revisión de Google es más automatizada, pero los primeros envíos de cuentas nuevas suelen tardar varios días, y a veces una semana o más. Planea tu fecha de lanzamiento en función de la más lenta de las dos.

Los motivos de rechazo más comunes

1. Fallos y errores (directriz 2.1 de Apple, App Completeness). Los revisores prueban en dispositivos y versiones de sistema actuales. Si la app se cierra al abrir o un botón no hace nada, la rechazan.
2. Sin cuenta de demostración. Si tu app requiere inicio de sesión, dale al revisor credenciales que funcionen en las notas de revisión (Apple) o en la sección de Acceso a la app (Google). Si el login usa un código de un solo uso o un estado especial del backend, explica cómo saltarlo.
3. Funcionalidad mínima (directriz 4.2 de Apple). Una app que solo envuelve un sitio web, una utilidad de una sola pantalla o un folleto de marketing probablemente será rechazada. La app tiene que hacer algo útil que justifique ser una app.
4. Spam y apps copiadas (directriz 4.3). Las apps casi idénticas a otras tuyas o a plantillas comunes se marcan.
5. Pagos fuera de las compras dentro de la app (directriz 3.1.1). Los bienes digitales y las suscripciones que se desbloquean dentro de la app, por lo general, deben usar In-App Purchase de Apple y Google Play Billing. Los bienes físicos y los servicios del mundo real (entrega de comida, viajes, consultoría) pueden usar Stripe o similares. Fallos judiciales y regulaciones recientes han flexibilizado esto en EE. UU. y la UE, pero los detalles varían por país y siguen cambiando.
6. Inconsistencias de privacidad. Pedir permisos sin un texto que explique claramente el propósito, recopilar datos que no declaraste en tu etiqueta de privacidad o no ofrecer la opción de eliminar la cuenta.
7. Contenido de relleno y enlaces rotos. Lorem ipsum, pantallas de "próximamente" y una URL de soporte caída cuentan.

Un rechazo no es una prohibición. Recibes un mensaje que cita la directriz, puedes responder en el Resolution Center de App Store Connect y volver a enviar. Si respondes rápido y de forma concreta, la mayoría de los rechazos cuesta unos días, no semanas.

Paso 6: Elige una estrategia de lanzamiento

Que la app esté aprobada no significa que tenga que publicarse al instante. Ambas tiendas te permiten controlar cuándo y a cuántos usuarios llega la actualización.

• Lanzamiento manual: retén una build aprobada y publícala cuando tu marketing, backend y soporte estén listos. Ideal para el primer lanzamiento.
• Lanzamiento por fases de Apple: las actualizaciones automáticas llegan a una proporción creciente de usuarios durante siete días. Puedes pausarlo si se disparan los reportes de fallos. Los usuarios nuevos que descargan desde la tienda reciben la versión nueva de inmediato en cualquier caso.
• Lanzamiento escalonado de Google: eliges el porcentaje (por ejemplo 5 %, luego 20 %, luego 100 %) y puedes detenerlo si algo falla.
• Feature flags del lado del servidor: publica código desactivado y enciende funciones de forma remota, para que una función defectuosa no necesite una nueva revisión de la tienda para apagarse.

Recuerda que no puedes revertir una versión publicada en la tienda. Si la versión 1.3 está rota, la solución es la versión 1.3.1 y otra revisión. Los lanzamientos escalonados y los feature flags son la forma de que una mala versión afecte a pocos usuarios.

Paso 7: Lo básico de ASO (optimización en tiendas de apps)

El ASO es el SEO de las tiendas de apps. El primer día no vas a superar a las grandes marcas, pero algunos básicos importan:

• Nombre: ambas tiendas permiten 30 caracteres. Pon tu marca más una frase clave si se lee natural (por ejemplo "Acme: Turnos de Trabajo" en lugar de solo "Acme").
• Subtítulo de Apple (30 caracteres) y campo de palabras clave (100 caracteres, oculto): no repitas palabras que ya están en el nombre. Separa las palabras clave con comas, sin espacios.
• Descripción breve de Google (80 caracteres) y descripción completa (4.000 caracteres): Google indexa la descripción, así que usa tus términos principales de forma natural.
• Las capturas venden, no describen. Las dos primeras aparecen en los resultados de búsqueda. Empieza por el beneficio principal con un texto corto, no con una pantalla de ajustes.
• Calificaciones: pide reseñas después de un momento de éxito usando las API nativas de reseñas, nunca justo después de instalar.
• Localiza la ficha para cada mercado importante, aunque al principio la app solo esté en inglés.

Checklist de publicación: Apple vs. Google

La columna de comisiones está simplificada: ambas tiendas tienen programas regionales y excepciones. Lee los términos vigentes para los países donde planeas vender.

Cuánto tarda publicar, siendo realistas

Según nuestra experiencia, un primer lanzamiento en ambas tiendas tarda de una a tres semanas desde "la app funciona" hasta "la app está publicada", si las cuentas ya existen. Suma una semana o más por el D-U-N-S y la verificación de cuentas, y dos semanas por la prueba cerrada de Google con una cuenta personal nueva. Por eso empezamos a configurar las tiendas en la primera semana del proyecto, no en la última. Para ver el panorama completo, lee cuánto tarda desarrollar una app y el proceso de desarrollo de una app explicado.

Si prefieres no pasar esas semanas aprendiendo los trámites de las tiendas, nuestro servicio de desarrollo de apps móviles incluye las cuentas, la firma, las pruebas beta, las fichas de la tienda y las respuestas a la revisión. Puedes obtener un plan gratuito para tu app y ver qué implicaría tu lanzamiento.