TL;DR. No existe un botón “revertir a la versión anterior” en App Store Connect. Los números de versión solo avanzan, y no puedes hacer que un build antiguo vuelva a ser el listado en vivo. Lo más parecido, los Last-Compatible Version Settings en Precios y disponibilidad, solo controla qué builds antiguos pueden seguir instalando los usuarios con versiones de iOS viejas — no revierte lo que ven los usuarios nuevos o los que ya actualizaron. Si sale una mala actualización, tus palancas reales son pausar un lanzamiento por fases en curso y enviar una versión corregida, opcionalmente con una solicitud de Expedited Review.
Sale una mala actualización, empiezan los reportes de crash, y el instinto es buscar un botón de rollback. App Store Connect no tiene uno. Saberlo antes de que pase te ahorra diez minutos buscando en Precios y disponibilidad mientras los usuarios ya están afectados.
¿Se puede volver a una versión anterior en el App Store?
No. La propia ayuda de App Store Connect de Apple es explícita: si una versión en vivo tiene un problema legal o de usabilidad, “debes enviar una actualización de la app” — no hay ningún mecanismo para volver a publicar un build antiguo como el listado actual. Los números de versión siempre deben aumentar; no puedes seleccionar un build anterior y volver a ponerlo en vivo.
Esto significa que la solución para una mala actualización siempre es una versión nueva, con número más alto, no un paso atrás. Esa nueva versión sí hereda tus metadatos existentes (keywords, subtítulo, descripción) como punto de partida al crearla, así que no estás reconstruyendo tu listado desde cero — solo el build tiene que avanzar.
¿Qué hace realmente la configuración Last-Compatible Version Settings?
No es un rollback. Los Last-Compatible Version Settings, al final de la página Precios y disponibilidad, controlan qué builds antiguos aprobados siguen siendo instalables para usuarios con versiones de iOS demasiado viejas para tu versión actual — no cambia lo que ven los usuarios con iOS actual o los que ya actualizaron.
En concreto: ve a Precios y disponibilidad → Last-Compatible Version Settings → selecciona una versión, y puedes deseleccionar builds antiguos específicos para que dejen de ofrecerse por completo, o dejar uno disponible para que un usuario con un iOS antiguo reciba ese build compatible más antiguo en vez de no poder instalar tu app. Solo las versiones que realmente se enviaron al App Store aparecen en esa lista. El rol requerido es Account Holder, Admin o App Manager — Marketing no tiene acceso a esta página, la misma restricción que en el keyword field y el subtítulo (mira nuestra guía de roles de App Store Connect).
Dos cosas que esta configuración no hace: no fuerza una actualización o un downgrade en un dispositivo que ya tiene tu versión actual instalada, y no afecta lo que reciben los usuarios nuevos con iOS actual — ellos siempre reciben lo que sea tu última versión en vivo.
Qué hacer realmente cuando sale una mala actualización
- Si lanzaste con un lanzamiento por fases todavía en curso, pausa primero. El lanzamiento por fases despliega al 1 % de los usuarios el primer día y sube según un calendario fijo de 7 días; pausarlo detiene que el porcentaje siga subiendo mientras preparas un fix. No deshace la actualización para los usuarios que ya la recibieron. La mecánica completa — el calendario de porcentajes y el límite acumulado de pausa de 30 días — está en nuestra guía de lanzamiento por fases.
- Prepara el build corregido como una versión nueva. Incrementa el número de versión, arregla el problema y vuelve a enviar. Tu keyword field, subtítulo y descripción se trasladan automáticamente — no empiezas el listado desde cero, solo el binario.
- Solicita una Expedited Review si el bug es crítico. La página de App Review de Apple permite solicitar una revisión acelerada por circunstancias atenuantes, como un fix de bug crítico, enviada con los pasos para reproducir el problema en la versión actual en vivo. No está garantizada — Apple aprueba o rechaza la solicitud —, pero para un bug de crash al abrir la app es la vía más rápida de vuelta a una posición normal en la cola de revisión. Esto solo acelera la revisión; no cambia cuándo sale en vivo el fix una vez aprobado, lo cual sigue dependiendo de tu opción de lanzamiento (automática, manual o programada).
- Si es tan grave que ninguna de las dos opciones es lo bastante rápida, retira la app de la venta. Esto detiene por completo las descargas nuevas hasta que estés listo para volver a enviar — un último recurso, no un primer movimiento, ya que también detiene las instalaciones nuevas legítimas.
Nada de esto toca tu keyword field, tu subtítulo o tu ranking — un build defectuoso y un listado defectuoso son dos problemas distintos con dos soluciones distintas, y confundirlos desperdicia el tiempo que no tienes durante un incidente.