El día que el binario “está listo” no es el día del lanzamiento. Es el día en que empieza otro proyecto: cuentas, contratos, capturas, textos legales, cuestionarios de privacidad y una cola de review que no controlas. Quien no lo ha hecho cree que es un upload. Quien lo ha hecho reserva dos o tres semanas —y a veces más.
Publicar app App Store Google Play no es un trámite simétrico. Apple y Google no piden lo mismo, no tardan lo mismo y no rechazan por lo mismo. Si tu calendario de marketing asume “el viernes está en las stores”, o tienes un equipo que ya ha pasado por esto o estás vendiendo una fecha que no te pertenece.
En Truman lo hemos vivido con producto propio y con cliente. Klapper es web y app de entradas; Weddle es una app social alrededor de una boda. Los dos casos terminan en la misma cola. Este artículo es el trabajo que casi nunca entra en el presupuesto de desarrollo de app y que, si se ignora, come el mes del launch.
Publicar app App Store Google Play: el trabajo que empieza cuando el código está listo
Hay tres capas, y solo una es el binario. La primera es jurídica y de cuentas: quién es el titular, si es persona o empresa, impuestos, banca para cobros. La segunda es de ficha: nombre, subtítulo, capturas, categoría, edad, textos. La tercera es de review: un humano o un sistema que abre la app y decide si cumple las reglas de esta semana.
En un estudio, la capa uno se debería abrir el mismo mes que el kickoff, no la semana del store freeze. Un alta de Apple Developer Program de organización (DUNS, verificación) no es un formulario de una tarde. Google Play Console es más rápido de abrir y más fácil de subestimar: ficha de Data safety, testers, política. Las dos stores te pueden dejar en espera sin que el código tenga un bug.
Lo que piden las stores (y no es simétrico)
Apple cobra el programa de desarrollador por año. Google Play cobra un alta. Eso es lo de menos. Lo que alarga es el contenido de la ficha y la coherencia entre lo que la app hace y lo que declaras.
| Tema | App Store | Google Play |
|---|---|---|
| Alta de cuenta empresa | Días o semanas (DUNS, verificación) | Horas o pocos días si la ficha está completa |
| Review del primer envío | 24–48 h, a veces más | Horas a varios días; revisiones nuevas más estrictas |
| Privacidad | Nutrition labels + ATT si trackeas | Data safety; permisos justificados |
| Login obligatorio | Credenciales de demo | Mismo requisito en la práctica |
| Apps sociales / citas | Escrutinio extra | Políticas de usuario y menores |
En Weddle el producto es conocerse entre solteros invitados a una boda: grupos privados, chat, un contexto sensible. Eso no es publicar un catálogo. Apple y Google miran de otra forma el contenido generado por usuarios, la edad, el reporte y el bloqueo. Si eso no está en la 1.0, el rechazo no es “la store es lenta”. Es que el producto no está listo para store, aunque el diseño sí lo esté.
Klapper, como plataforma de entradas, añade pagos, QR y datos de evento. El reviewer va a intentar el flujo. Si el entorno de review no tiene un evento de prueba, un pago sandbox o una nota que lo explique, el rechazo es Guideline de “app incompleta”, no un fallo de UX. Lo mismo aplica si estás eligiendo stack: nativa o híbrida cambia el binario, no te ahorra la ficha. Esa decisión está en app nativa o híbrida en 2026; la store es otro oficio.
Rechazos que alargan semanas (y se evitan en el brief)
Los rechazos que más duelen no son un crash. Son papeles. Política de privacidad en un PDF que no carga. Capturas de un build distinto. Permiso de cámara declarado y no usado. “Sign in with Apple” ausente cuando hay login social. Descripción que promete una función que en el binario aún no está.
Si Apple rechaza el viernes y el anuncio es el lunes, ¿quién tiene autoridad para cambiar la ficha el sábado?
Versiones, tracks y el hotfix que no cabe en el vídeo del launch
Publicar no es un evento: es un hábito. TestFlight y las pistas internas de Play deberían existir desde el primer mes de desarrollo, no la semana de QA. El número de versión, el build, quién firma y qué certificado caduca son deuda operativa. Un estudio que entrega “el .ipa y el .aab” y desaparece te deja solo en el segundo rechazo.
Reserva un canal de emergencia. En iOS, una review acelerada se pide; no se garantiza. En Play, una release gradual te salva de un crash al 100% de usuarios. Nada de eso se improvisa el día que Product Hunt o el festival anuncian la app. Si vas a mandar notificaciones push en el launch, los certificados y consentimientos van en este mismo paquete, no en un sprint posterior.
Tip técnico: el binario de review no es el de desarrollo
Flags de entorno, logs verbosos, endpoints de staging, API keys de debug: si eso viaja al binario de store, o se ve en el review o se ve en un extracto. Configura un scheme / flavor de producción con la URL pública de privacidad, sin menús ocultos de desarrollador. Documenta en las notas del reviewer cómo reproducir el flujo feliz en menos de tres minutos. El reviewer no va a leer tu Notion.
Cómo no mentir en el calendario (ni al cliente ni al equipo)
Una agencia de apps en València que no pone la store en el Gantt no está siendo ágil: está omitiendo. En nuestros proyectos el “code complete” y el “live en stores” son hitos distintos. Entre medias: ficha, legales, primer review, un rechazo probable, resubida. Si el negocio necesita una fecha pública, se anuncia después del primer aprobado, no antes del primer envío.
El desarrollo puede estar redondo y el launch irse dos semanas porque el DUNS no llegó o porque el cuestionario de privacidad no coincidía con un SDK. Eso no es mala suerte. Es un trabajo que no estaba en el plan. En Klapper y en Weddle lo aprendimos en carne propia: la store se diseña, no se “sube”.
Antes de dar por cerrada la app, verifica esto
- ¿La cuenta de Apple y de Play está a nombre de la empresa, con el estudio como rol?
- ¿La política de privacidad está en una URL pública y coincide con permisos y SDKs?
- ¿El cuestionario de Apple y el Data safety de Play se rellenaron contra el binario real?
- ¿Hay usuario y contraseña de review, con pasos en las notas, si hay login?
- ¿Las capturas son del build que se envía, en los tamaños que pide cada store?
- ¿TestFlight y la pista interna de Play existen desde antes del “código listo”?
- ¿El calendario de marketing está anclado al primer aprobado, no al primer upload?
- ¿Quién puede responder un rechazo el fin de semana sin esperar al lunes?
Preguntas frecuentes sobre publicar una app en las stores
¿Cuánto tarda publicar una app en App Store y Google Play?
El upload es el menor de los tiempos. El primer review de Apple suele resolverse en 24–48 horas, pero un rechazo te devuelve a la cola. Play puede ser más rápido o alargarse en apps nuevas. Lo que de verdad suma son cuentas, legales y fichas: en un primer lanzamiento, planifica dos o tres semanas desde “binario estable” hasta “disponible en ambos catálogos”, y más si hay DUNS o una categoría sensible.
¿Qué diferencia hay entre publicar en App Store y en Google Play?
Apple es más rígida en cuentas de empresa, metadatos y coherencia de privacidad. Play es más ágil de abrir y más exigente de lo que era en Data safety y testers. Los rechazos no se copian: un aprobado en una store no garantiza la otra. Trata dos procesos, no un “y también Android”.
¿Cuándo hay que empezar el papeleo de las stores?
En el kickoff, no en el QA. Alta de cuentas, titularidad, textos legales y un entorno de review se pueden avanzar mientras se diseña. Si esperas al feature freeze, el papelerío compite con el anuncio. El código no desbloquea el DUNS.
¿Cómo elijo quién aparece como desarrollador en la ficha?
La empresa dueña del producto. El estudio entra como usuario con rol, no como titular “para ir más rápido”. Publicar a nombre del partner te deja sin la cuenta el día que cambias de equipo. Recuperar un Apple Developer no es un trámite simpático.
