· Publicación · 6 min de lectura

App Store Connect vs Google Play Console: el flujo de publicación

App Store Connect vs Google Play Console: el flujo de publicación
TL;DR. Apple revisa una versión —build y metadatos juntos— y luego te da lanzamiento automático, manual o programado, además de un lanzamiento gradual de 7 días en actualizaciones automáticas. Google revisa un release de la app en un track, mantiene las ediciones de la ficha separadas y ofrece publicación gestionada más lanzamiento escalonado por porcentaje. Mismo objetivo, mecánica distinta. La tabla de abajo es el mapa.

Si publicas en una sola tienda, aprendes una consola y sigues adelante. Si publicas en ambas, manejas dos modelos mentales que usan las mismas palabras para cosas distintas. «Release», «revisión» y «rollout» significan algo ligeramente diferente en App Store Connect que en Google Play Console. Este artículo alinea los dos flujos etapa por etapa para que puedas planear un lanzamiento que llegue a ambas tiendas sin sorpresas.

El flujo, lado a lado

Empieza aquí. Cada fila es una etapa para poner en vivo una actualización; las dos columnas muestran qué ocurre en cada consola.

Edición solo de metadatosLa mayoría de los cambios de ficha viajan con una nueva versión a través de revisión; solo unos pocos campos se editan en vivo.Una edición de la ficha de la tienda, enviada y revisada sin publicar un nuevo build.

Cómo Apple lanza una versión

En App Store Connect la unidad de trabajo es una versión. Adjuntas un build, completas metadatos y capturas de pantalla, y envías todo el paquete a App Review. Apple lo evalúa como un único conjunto, por eso un cambio de captura o un ajuste de descripción, por sí solos, suelen implicar una nueva versión y otro paso por revisión.

Una vez que App Review aprueba, tu opción de lanzamiento decide qué pasa. Elige automático y se publica de inmediato. Elige manual y queda en «Pending Developer Release» —Apple ya la aprobó, pero nada es público hasta que pulses el botón (puede tardar hasta 24 horas en aparecer después de hacerlo). Elige programado y se publica automáticamente en la fecha y hora que definas. Eliges esto por cada versión, así que cada actualización es una decisión nueva.

Para un lanzamiento gradual, activa el lanzamiento por fases. Se aplica a actualizaciones automáticas para usuarios existentes y las distribuye a lo largo de 7 días con un porcentaje creciente, y puedes pausarlo si algo se ve mal en las métricas. No afecta a una app completamente nueva ni se aplica a lanzamientos manuales: es el equivalente de App Store al lanzamiento escalonado de Google, no una retención sobre el lanzamiento entero.

Cómo Google lanza a un track

Google divide el mismo trabajo en tracks. Un build empieza en un track de pruebas —interno, cerrado o abierto— y se promueve hacia producción cuando estás listo. Las pruebas internas son para un grupo pequeño y de confianza (hasta 100). Las pruebas cerradas se amplían a listas de invitados (hasta 2.000 por lista). Las pruebas abiertas son de inscripción pública sin límite. Producción es todos los usuarios en los países que elijas.

Cuando envías un release, la publicación gestionada equivale a la retención manual de Apple. Con esta activada, los cambios aprobados se acumulan en el resumen de publicación bajo «cambios listos para enviar» y se publican solo cuando tú lo indiques, ideal para alinear un lanzamiento con una fecha de marketing. Con esta desactivada, los cambios aprobados se publican en cuanto termina la revisión.

Para un lanzamiento gradual, usa un rollout escalonado: lanza a un porcentaje de usuarios y ve subiéndolo tú mismo con el tiempo, deteniéndolo si aumentan los fallos. Igual que el lanzamiento por fases de Apple, es para actualizaciones, no para primeros lanzamientos: un release de producción totalmente nuevo llega a todos a la vez.

La divergencia que confunde a la gente

Aquí está la diferencia que conviene interiorizar: Apple acopla los metadatos a la versión; Google mantiene la ficha de la tienda separada del release.

En Apple, tus capturas de pantalla, descripción y palabras clave forman parte de la versión en revisión. ¿Quieres renovar las capturas entre builds? Para la mayoría de los campos eso implica una nueva versión y otro paso por revisión. En Google, la ficha de la tienda es un objeto independiente: puedes actualizar texto e imágenes y enviar solo eso a revisión mientras el paquete de la app publicada permanece exactamente igual. Dos tiendas, dos respuestas muy distintas a «¿puedo cambiar esto sin un lanzamiento completo?».

Esto importa sobre todo cuando un lanzamiento tiene muchas piezas en movimiento: un build, un set de capturas, texto localizado en decenas de mercados. En Apple sueles agrupar todo en una sola versión para que se revise junta. En Google puedes preparar la ficha y el release de forma independiente y publicarlos en el orden que convenga al plan.

Tiempos de revisión y la trampa para cuentas nuevas

El App Review de Apple tarda entre 24 y 48 horas para una actualización típica en 2026, más si es el primer envío de un desarrollador nuevo o algo marcado para revisión más detallada. La revisión de Google suele ser más rápida —horas a pocos días para una cuenta consolidada—, pero hay una condición para los recién llegados.

Una cuenta de desarrollador personal de Google Play creada después de mediados de noviembre de 2023 tiene que ejecutar una prueba cerrada con al menos 12 testers inscritos durante 14 días consecutivos antes de poder solicitar acceso a producción. Si bajas de 12, la racha puede reiniciarse. Las cuentas de organización y las cuentas personales más antiguas se saltan esto. Apple no tiene un equivalente directo, así que si vas a lanzar una primera app en ambas tiendas, reserva tiempo por adelantado para la ventana de pruebas de Google: suele ser el trámite más largo.

Dónde encaja Mokbi

Ambas consolas quieren los mismos activos terminados: capturas de pantalla enmarcadas y texto limpio y localizado en cada tamaño requerido. Mokbi construye ese conjunto una sola vez. Diseñas las capturas y redactas el texto de la ficha en un solo proyecto, luego traduces ambos a 50 idiomas, y exportas un set que coincide con las dimensiones de App Store Connect y Google Play Console en una sola pasada, así el mismo trabajo alimenta dos fichas en lugar de dos esfuerzos por separado.

Mokbi también los publica. Envía la ficha y los activos directamente a Google Play mediante la Play Developer API, y deja preparada la versión en App Store Connect lista para que la envíes. Apple exige el Submit final y su revisión, así que ese último paso queda en tus manos (una regla de Apple, no una limitación de Mokbi). De cualquier forma, gestionas las actualizaciones de ficha de ambas consolas desde un solo lugar, con una sola suscripción: el editor es gratis con marca de agua, y Solo (€29.99/mes) o Studio (€49.99/mes) desbloquean exportación y publicación ilimitadas mientras mantengas la suscripción.

Publica ambas fichas desde Mokbi →