Lanzamiento por fases en App Store: el despliegue de 7 días, cuándo pausar y cómo lanzar un arreglo (2026)

Un lanzamiento por fases en App Store envía una actualización de versión a una proporción creciente de usuarios con las actualizaciones automáticas activadas durante siete días, empezando por el 1% el primer día y llegando al 100% el séptimo. Si revisas los crashes y el correo de soporte cada día y pausas en cuanto algo no cuadra, una build defectuosa llega a un grupo pequeño de personas en lugar de a toda tu base de usuarios. Pero el lanzamiento por fases tiene una gran limitación: solo controla las actualizaciones automáticas. Cualquiera puede seguir descargando la nueva versión manualmente.

¿Qué controla el lanzamiento por fases de App Store y qué no?

El lanzamiento por fases solo controla qué usuarios con actualizaciones automáticas activadas reciben tu actualización de versión, y cuándo. No oculta la nueva versión a las descargas manuales ni revierte a quienes ya la tienen.

Según la Ayuda de App Store Connect de Apple, "una muestra aleatoria de usuarios con actualizaciones automáticas en dispositivos compatibles recibirá la actualización, sin ninguna notificación de su participación en el lanzamiento por fases". Funciona para actualizaciones de versión de iOS, macOS y tvOS, así que no puedes usarlo en el primer lanzamiento de una app. Configurarlo requiere el rol de Account Holder, Admin o App Manager. Apple también indica: "Cualquiera puede descargar manualmente desde el App Store, en cualquier momento, las apps y actualizaciones de apps que estén en lanzamiento por fases".

¿Cuál es el calendario del lanzamiento por fases de App Store?

A noviembre de 2026, el calendario es fijo: 1%, 2%, 5%, 10%, 20%, 50% y 100% a lo largo de siete días, y no se puede editar. Lo que sí controlas es cuándo pausar y cuándo saltar directamente al 100%.

Trata cada día como un punto de control que termina con una sola decisión: seguir o pausar.

¿Cómo se activa el lanzamiento por fases en App Store Connect?

El lanzamiento por fases se activa desde la página de la versión, en Phased Release for Automatic Updates, en cualquier momento antes de que la actualización se publique. No tienes que decidirlo antes de enviarla.

Apple lo permite mientras la versión está en Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected o Metadata Rejected.

1. En Apps, selecciona tu app y luego haz clic en la versión que vas a enviar en la barra lateral.
2. Desplázate hasta Phased Release for Automatic Updates.
3. Selecciona Release update over a 7-day period using phased release.
4. Haz clic en Save. Tras la aprobación, el estado mostrará Ready for Distribution con Phased Release al lado.

También puedes gestionar los lanzamientos por fases mediante la API de App Store Connect, algo útil si tu pipeline de publicación ya está automatizado con scripts.

¿Cuándo conviene pausar un lanzamiento por fases y cómo funciona el límite de 30 días?

Pausa en cuanto se active uno de los disparadores que acordaste de antemano. Las pausas pueden sumar hasta 30 días en total y, al reanudar, el despliegue continúa desde el día en que se detuvo.

Deja por escrito tus disparadores antes del día del lanzamiento, para que nadie esté discutiéndolos mientras los usuarios se topan con el bug. Los buenos disparadores son concretos: las sesiones sin crashes caen por debajo de la referencia de la versión anterior, el checkout o el inicio de sesión fallan en una proporción medible de intentos, o varios usuarios reportan el mismo bug.

Para pausar, abre la versión en Ready for Distribution, selecciona Pause Phased Release y haz clic en Save. Para reanudar, selecciona Use Phased Release. El ejemplo de Apple: si pausas 10 días y luego reanudas, te quedan 20 días de pausa. Puedes pausar tantas veces como quieras dentro de ese total. Para saltarte las fases restantes, haz clic en Release to All Users en la esquina superior derecha de la página de la versión.

¿Cómo se ve un lanzamiento por fases cuando aparece un bug?

Cuando aparece un bug, pausas, lo arreglas y publicas una nueva versión, de nuevo con el lanzamiento por fases activado. Los usuarios que aún esperan la actualización automática se quedan en la versión anterior mientras trabajas.

Supón que la versión 3.4 sustituye tu motor de sincronización. El primer día la recibe el 1% de los usuarios con actualización automática, y revisas dos veces tu herramienta de crash reporting y los logs de errores de sincronización. El tercer día, al 5%, aparece un grupo de fallos de sincronización en una versión antigua de iOS. Pausas de inmediato. Hay muchos menos usuarios afectados que si todos la hubieran recibido, y los usuarios con actualización automática a los que aún no había llegado siguen en la 3.3.

Después, arregla el bug y envía la 3.4.1 con el lanzamiento por fases activado. Prueba el arreglo en una build de release, no solo en debug; nuestro plan de pruebas con build de release cubre ese paso. Indica claramente en las notas de la versión 3.4.1 que la sincronización está arreglada; nuestros ejemplos de notas de versión muestran cómo hacerlo. Si el arreglo es urgente y confías en él, usa Release to All Users tras la aprobación en lugar de esperar otra semana.

Una salvaguarda más: pon el nuevo motor de sincronización detrás de un flag del lado del servidor. Pausar impide que la actualización se siga extendiendo, pero un flag te permite desactivar el código arriesgado para quienes ya instalaron la 3.4. Ambos se complementan bien.

¿Con qué se han encontrado otros desarrolladores al pausar un lanzamiento por fases?

Los hilos públicos muestran el mismo patrón: los desarrolladores pausan una versión con bugs y luego no tienen claro qué hace un lanzamiento por fases posterior con los usuarios que ya la recibieron. La documentación de Apple no lo aclara, así que planifica como si el arreglo necesitara su propio despliegue.

• Un desarrollador en los Apple Developer Forums contó que "detectó un crash, pausó el despliegue de la actualización, parcheó la app, la subió e inició otro despliegue por fases" con menos del 10% de los usuarios en la build defectuosa. Preguntó si los mismos usuarios recibirían el nuevo despliegue. El hilo nunca obtuvo una respuesta oficial; una respuesta decía que los usuarios de la 8.0 "deberían recibir un aviso de que hay una actualización 8.1 disponible en cuanto salga".
• En otro hilo del foro, un desarrollador explicó que se había "detenido en el 1%" con la versión 15.0.1 por un bug crítico y quería escalonar también la 15.0.2, con la esperanza de que la 15.0.1 fuera "prácticamente omitida para la mayoría de los usuarios". Una respuesta anterior en ese hilo sugería solicitar una revisión acelerada mientras la versión con bugs estaba en pausa y, posiblemente, retirar la app de la venta "para que ningún usuario nuevo se descargue la versión defectuosa". Antes de hacerlo, recuerda la regla sobre la retirada de la venta del aviso anterior.
• El equipo de herramientas de publicación detrás de las notas store-quirks de Tramline documenta que iniciar una nueva versión "simplemente cancelará el despliegue existente", y la versión anterior pasa a REPLACED_WITH_NEW_VERSION con su lanzamiento por fases marcado como COMPLETE. Las mismas notas indican que una pausa "no podrá hacer nada respecto a los usuarios que ya recibieron la actualización".

En los tres casos, pausar solo sirvió para ganar tiempo. La solución siempre fue una nueva versión, y nadie podía contar con que el mismo grupo se actualizara primero. Por eso los flags del lado del servidor y una rama de hotfix que puedas publicar rápido importan más que el botón de pausa.

¿Cómo se compara con el lanzamiento gradual de Google Play?

El lanzamiento gradual de Google Play usa un porcentaje que tú eliges y subes manualmente. Tras detenerlo, al reanudarlo llega al mismo grupo de usuarios. Planifica los despliegues de ambas tiendas por separado.

Según la Ayuda de Play Console, "el porcentaje del lanzamiento gradual de tu app no aumentará automáticamente", y los lanzamientos graduales "solo pueden usarse para actualizaciones de apps, no al publicar una app por primera vez". Tras detener un lanzamiento, los usuarios que ya recibieron la versión se quedan en ella, y Google aconseja publicar una nueva versión con un bundle corregido en lugar de reanudar una defectuosa. Los lanzamientos en producción pueden limitarse a países concretos, pero una vez iniciado uno, no puedes quitar países. Si tu próxima actualización de Android también tiene que cumplir el nuevo target SDK, consulta nuestra guía sobre el nivel de API objetivo 36 en Google Play.

¿Qué deberías revisar antes de iniciar un lanzamiento por fases?

Antes de que empiece el despliegue, asegúrate de que el lanzamiento por fases está guardado en la versión, de que tus referencias y disparadores de pausa están por escrito y de que un arreglo puede publicarse rápido. Usa esta checklist:

• Lanzamiento por fases seleccionado y guardado en la página de la versión
• Dashboards de crash reporting y de errores del backend en marcadores, con referencias de la versión anterior
• Disparadores de pausa por escrito y acordados por todos los que pueden pulsar el botón
• Funciones arriesgadas detrás de flags del lado del servidor
• Una persona designada que revise las métricas cada uno de los 7 días
• Una rama de hotfix lista, además de nuestra checklist de envío al App Store para la build de seguimiento
• Cambios en la ficha de la tienda en espera hasta que el despliegue llegue a todos

Si prefieres delegar la publicación en sí, nuestro servicio de envío al App Store cubre la configuración de App Store Connect y Play Console, la preparación para la revisión y las publicaciones en ambas tiendas por $599 (las cuotas de las cuentas de desarrollador van aparte). Si quieres una segunda opinión sobre una actualización arriesgada, escribe a yagyeshsrbobde@gmail.com indicando tu app y qué cambia.