Devoria
Publicar una actualización iOS: lanzamiento por fases
Por Mehdi Azizi
Publicado el , 10 min
Publicar una actualización iOS: nueva versión, nuevo build, texto de novedades y lanzamiento manual, automático o por fases en 7 días.
Para publicar una actualización iOS, creas una nueva versión en App Store Connect, con un número más alto. Le adjuntas un nuevo build, escribes el texto de "Novedades" y luego la envías a App Review. Cada nueva versión vuelve a pasar por la revisión de Apple, incluso si es una simple corrección. Antes del envío, eliges cómo saldrá después de la aprobación: a mano, de inmediato, no antes de una fecha o en lanzamiento por fases durante 7 días.
El lanzamiento por fases solo afecta a las actualizaciones automáticas: 1 % de esos usuarios el primer día, todos el séptimo. Puedes pausarlo hasta 30 días en total, o terminarlo de golpe. Esta guía sigue las páginas de ayuda de Apple, revisadas el 3 de noviembre de 2026.
Publico las actualizaciones de mis apps iOS con Expo y EAS, entre ellas Solys, TradaZen y Nolera. Los casos que cito más abajo vienen de esos lanzamientos.
Publicar una actualización iOS: los pasos en orden
La ayuda de App Store Connect sobre nuevas versiones da este recorrido:
- En Apps, elige tu app y haz clic en el botón + junto a la plataforma.
- Escribe un número de versión más alto que el anterior y haz clic en Create.
- Revisa los metadatos: los de la versión publicada se copian automáticamente.
- Envía un nuevo build, con un número de build incrementado.
- Prueba ese build en TestFlight, agrégalo a la versión y envíala a App Review.
Dos condiciones antes de empezar. La versión publicada debe estar en el estado Ready for Distribution. Y necesitas uno de estos roles: Account Holder, Admin, App Manager o Marketing.
No hay vuelta atrás. Apple lo dice en la misma página: si una versión da problemas, no puedes volver a la anterior. Tienes que crear y enviar una nueva versión.
Número de versión y número de build
La versión es el número que tus clientes ven en tu ficha. El build identifica cada envío. La pareja versión y build debe ser única: las reglas y los errores asociados están en versión y número de build.
Mi convención, que no es una regla de Apple: el último dígito sube para una corrección, de 1.4.0 a 1.4.1. El del medio sube para una función nueva, de 1.4.1 a 1.5.0. El número de build, en cambio, solo sube, de una versión a otra. Con Expo, la versión vive en app.json y EAS puede incrementar el build en cada compilación de producción. La configuración está en publicar una app Expo con EAS.
El texto de "Novedades": lo que exige Apple
La página de información de la versión describe el campo What's New in This Version:
- 4.000 caracteres como máximo.
- No existe en la primera versión, es obligatorio en todas las siguientes.
- Se puede traducir a cada idioma de tu ficha.
La regla 2.3.12 de las App Review Guidelines añade una exigencia: describir con claridad las nuevas funciones y los cambios del producto. Una fórmula general basta para simples correcciones de errores, de seguridad o de rendimiento. Un cambio importante debe aparecer en la lista. "Corrección de errores y mejoras" no basta, entonces, para una versión que cambia tu suscripción o tu pantalla principal.
Apple también recomienda, en su página sobre las reseñas, mencionar en las notas los problemas corregidos que algunos clientes habían descrito en sus reseñas.
Aquí tienes tres plantillas para adaptar, una por tipo de versión.
Para una corrección:
Correcciones y estabilidad.
- [Función]: se corrigió [lo que no funcionaba].
- [Pantalla] carga más rápido.
Gracias a quienes lo reportaron.
Para una función nueva:
Nuevo: [la función, en cinco palabras].
[Lo que ahora puedes hacer, en una frase.]
Dónde encontrarla: [pestaña] > [botón].
También en esta versión:
- [Mejora visible].
- Corrección de errores.
Para un flujo que cambia:
[Pantalla o flujo] cambia.
- Lo que cambia para ti: [efecto concreto].
- Lo que conservas: [datos, ajustes, compra].
¿Alguna pregunta? [Ajustes] > [Ayuda].
La última línea de la plantilla de corrección solo vale si alguien realmente reportó el problema. Nunca escribas una novedad que no esté en el build: la regla 2.3 exige metadatos fieles a la app.
Lanzamiento manual, automático o en una fecha
La ayuda sobre las opciones de lanzamiento propone tres:
| Opción | Después de la aprobación de Apple |
|---|---|
| Manual | Estado Pending Developer Release, publicas cuando quieras |
| Automática | La versión sale en cuanto se aprueba |
| Automática, no antes del... | Espera la fecha elegida y luego sale sola |
En lanzamiento manual, abres la versión en estado Pending Developer Release, haces clic en Release This Version y confirmas. Apple advierte que puede tardar hasta 24 horas en aparecer en el App Store. Un mensaje en la página de la versión ofrece Cancel This Release para cancelar. Si la versión se queda más de 30 días en espera, Apple te envía un recordatorio por correo.
El lanzamiento manual sirve para elegir el momento, por ejemplo para publicar el día de un anuncio. Solys 2.0.0, que traía una nueva versión de la suscripción anual, entró en revisión a finales de septiembre de 2026 con lanzamiento manual.
Para una versión de rutina, dejo el lanzamiento automático. Nolera 1.0.2, aprobada el 12 de octubre de 2026, apareció en el App Store menos de un minuto después del correo de Apple, según la API pública de búsqueda de iTunes. Es una sola observación: calcula con margen.
El lanzamiento por fases en 7 días
La ayuda de Apple sobre el lanzamiento por fases da el calendario exacto:
| Día | Porcentaje de usuarios |
|---|---|
| 1 | 1 % |
| 2 | 2 % |
| 3 | 5 % |
| 4 | 10 % |
| 5 | 20 % |
| 6 | 50 % |
| 7 | 100 % |
La actualización llega a una muestra aleatoria de los usuarios que activaron las actualizaciones automáticas, en los dispositivos compatibles. No se les avisa que forman parte de ella.
El lanzamiento por fases solo frena las actualizaciones automáticas. Apple aclara que cualquiera puede descargar la nueva versión desde el App Store, en cualquier momento. Una persona que instala tu app, o que toca "Update" en tu ficha, puede tenerla desde el primer día. No es una prueba con el 1 % de tus usuarios: es un freno para los demás.
Para activarlo, abre la versión, baja hasta la sección Phased Release for Automatic Updates, marca "Release update over a 7-day period using phased release" y guarda. Necesitas el rol Account Holder, Admin o App Manager. La opción sigue disponible hasta el estado Pending Developer Release: todavía puedes activarla después de la aprobación de Apple, mientras la versión espere tu lanzamiento manual.
Una vez aprobada la versión, su estado Ready for Distribution lleva la mención "Phased Release". Al final de los 7 días, los Admin y App Manager de la app reciben una notificación.
Pausa, reanudación y lanzamiento para todos
- Pausa: hasta 30 días en total, en tantas veces como quieras. Una pausa de 10 días deja 20 días para las siguientes.
- Reanudación: el lanzamiento continúa desde el día en que lo detuviste.
- Lanzamiento para todos: el botón Release to All Users, arriba a la derecha de la versión, envía la actualización a todos los dispositivos con actualización automática.
- Retirada de la venta: detiene el lanzamiento de forma definitiva, incluso si vence tu membresía del programa de desarrolladores. Si la app vuelve a estar a la venta, la versión queda disponible para todos de golpe.
Después del lanzamiento para todos, ya no se puede ajustar nada, según la tabla de propiedades editables.
Nolera 1.0.2 salió sin lanzamiento por fases. Así es como lo usaría durante la semana:
| Lo que ves | Lo que haces | Lo que pasa |
|---|---|---|
| Cierres inesperados o reseñas preocupantes | Pausa | Las actualizaciones automáticas se detienen |
| La corrección está lista | Nueva versión | Vuelve a revisión, con su propio lanzamiento |
| Nada anormal después de 3 o 4 días | Release to All Users | Todo el mundo la recibe |
| Esperas una respuesta de Apple | Pausa, 30 días en total | Se reanuda desde el día en que te detuviste |
Durante una pausa, las descargas manuales continúan. Marca el lanzamiento por fases en toda versión que toque el pago o el primer inicio: ahí es donde un fallo sale más caro, y no podrás volver atrás.
Cuando la corrección es urgente: la revisión acelerada
Apple permite solicitar una revisión acelerada. Está reservada para urgencias reales: un error crítico que corregir, o un lanzamiento ligado a un evento.
- Primero envía tu versión. Describe el error en el campo Notes destinado al revisor.
- Llena el formulario de solicitud de revisión acelerada y elige tu app y su plataforma.
- Apple acelera la revisión según su disponibilidad. Nada está garantizado.
Para un evento, indica en las notas su fecha y tu relación con él. Los plazos habituales están en el plazo de validación del App Store.
Lo que vuelve a revisión y lo que no
| Cambio | Lo que necesitas |
|---|---|
| Código nativo, permisos, versión del SDK | Nuevo build, nueva versión, revisión completa |
| Capturas, descripción, palabras clave, novedades | Una nueva versión, revisada junto con ella |
| Texto promocional | Nada: cambia sin un nuevo envío |
| Pausa, reanudación, lanzamiento para todos | Nada: son ajustes de lanzamiento |
| Encabezado de ficha iOS 27 | Solo en Asset Library, o con una versión |
| Corrección JavaScript, con Expo | Es posible una actualización remota |
El texto promocional cambia sin un nuevo envío, según la página de información de la versión. Con Expo, una actualización remota cambia el JavaScript, los textos y las imágenes sin pasar por el App Store. La documentación de Expo pone dos límites: el código nativo, los permisos y la versión del SDK exigen un nuevo binario, y las actualizaciones deben respetar las reglas del App Store.
Mi caso: una corrección remota que el revisor nunca vio
En septiembre de 2026, un build de Nolera esperaba revisión. Había corregido un fallo de la pantalla de escaneo y publicado esa corrección como actualización remota durante la espera. Aun así, el build fue rechazado, por ese fallo ya corregido.
La explicación está en la documentación de expo-updates: por defecto, la app descarga la actualización al iniciarse y la aplica en el siguiente inicio. El revisor instala la app, la abre una vez y prueba el código incluido en el build. La misma regla vale para tus nuevos usuarios: su primera sesión corre con el código del build.
Desde entonces, todo cambio en la pantalla de inicio, el paywall o la función principal va en un nuevo build. La actualización remota solo sirve para quienes ya tienen la app.
Restablecer la calificación con una versión
Cada nueva versión ofrece la opción Reset rating when this version is released. Según la ayuda de Apple sobre el restablecimiento, aplica a todos los países, conserva las reseñas escritas y no se puede deshacer después del lanzamiento. Apple recomienda usarla con moderación, porque una ficha con pocas calificaciones puede desanimar.
La checklist antes de enviar tu actualización
- El número de versión es más alto y el build está incrementado.
- El build está probado en TestFlight, en un iPhone pequeño y en iPad si tu app funciona ahí.
- Las novedades están escritas en cada idioma y los cambios importantes están en la lista.
- Las capturas muestran la interfaz actual si cambió.
- Las notas para el revisor dicen qué cambió y dónde encontrarlo.
- La opción de lanzamiento está elegida: manual si tienes que cumplir una fecha.
- El lanzamiento por fases está marcado si la versión toca el pago o el primer inicio.
- Sabes si una posible corrección puede ir de forma remota o si requerirá un build.
Pasar la revisión en cada actualización
Cada actualización vuelve a pasar por App Review, y un rechazo bloquea tu corrección. El Review Kit reúne mi checklist antes del envío, mis rechazos corregidos y dos skills de Claude Code que revisan tu proyecto y tu ficha, y luego preparan tu respuesta si Apple rechaza. El recorrido completo está en la página publicar una aplicación en el App Store.
Si estás preparando tu primer lanzamiento, haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist contra rechazos de Apple.
Preguntas frecuentes
¿Cuánto dura el lanzamiento por fases en el App Store?
Siete días: 1 % de los usuarios con actualización automática el primer día, luego 2, 5, 10, 20 y 50 %, y 100 % el séptimo. Puedes pausarlo hasta 30 días en total, o terminarlo en cualquier momento con Release to All Users.
¿Una actualización de app iOS vuelve a pasar por la revisión de Apple?
Sí. Cada nueva versión, con su build y sus metadatos, pasa por App Review. El texto promocional y los ajustes de lanzamiento, en cambio, se modifican sin un nuevo envío.
¿Se puede volver a la versión anterior de una app en el App Store?
No. Tienes que crear una nueva versión, con la corrección, y enviarla a revisión. Por eso son útiles el lanzamiento por fases y su pausa.
¿Los nuevos usuarios reciben la actualización durante el lanzamiento por fases?
Sí, si descargan la app desde el App Store. El lanzamiento por fases solo regula las actualizaciones automáticas: cualquiera puede descargar la nueva versión en cualquier momento.
¿Se puede activar el lanzamiento por fases después de la aprobación de Apple?
Sí, mientras la versión esté en estado Pending Developer Release, es decir, con lanzamiento manual y todavía sin publicar. Una vez publicada, ya es tarde para esa versión.
¿Qué poner en las notas de versión de una actualización?
Las nuevas funciones y los cambios importantes, en una lista clara: es la regla 2.3.12. Para una simple corrección de errores, de seguridad o de rendimiento, basta una fórmula general. El campo acepta 4.000 caracteres y se traduce a cada idioma.
