Has publicado una versión, algo va mal en ella y necesitas que la gente vuelva a la versión que funcionaba. El instinto es volver a poner en circulación el Build anterior — pero eso no basta por sí solo, porque quién acepta una versión más antigua lo decide el sistema operativo, no Applivery.
La forma fiable de revertir una versión es avanzar (roll-forward): toma el código de la última versión que funcionó, recompílalo con un identificador de versión superior al del Build problemático y distribúyelo. El código va hacia atrás; el número de versión va hacia delante. Para el dispositivo es una actualización normal, y por eso precisamente se instala.
Este enfoque funciona en todas las plataformas a las que Applivery distribuye. Algunas plataformas también aceptarían una bajada de versión directa, pero el roll-forward es el único procedimiento que es seguro en todas partes — así que es el que merece la pena estandarizar.
Por qué no puedes simplemente volver a servir el Build antiguo
En Android, el gestor de paquetes del sistema se niega a instalar un paquete cuyo versionCode es inferior al ya instalado. La instalación falla con INSTALL_FAILED_VERSION_DOWNGRADE. La documentación del manifiesto de Android expone la regla con claridad: cada versión sucesiva debe llevar un número más alto.
Así que si reetiquetas el Build antiguo, cualquiera que ya instaló la versión problemática se queda atascado en ella. Las personas a las que más necesitas arreglar son precisamente aquellas a las que el Build antiguo no puede llegar.
Recompilar con un identificador de versión superior evita esto por completo.
El identificador de versión en cada plataforma
Applivery lee la información de versión del paquete que subes — no es algo que puedas definir en el Dashboard ni pasar a la API. Tiene que definirse en tiempo de compilación.
| Plataforma | Qué incrementar | Formato |
|---|---|---|
| Android | versionCode en tu configuración de compilación |
Entero — 201 |
| iOS / macOS | CFBundleVersion en el Info.plist de la app |
De uno a tres enteros separados por puntos — 2.0.1 |
| Windows (MSIX / APPX) | Versión en AppxManifest.xml |
Versión de cuatro partes |
| Plataformas personalizadas | packageVersion al subir |
Manual |
El CFBundleVersion de Apple no es un entero simple como el versionCode de Android. Es una cadena de hasta tres enteros separados por puntos, así que "sumar uno" no tiene sentido por sí solo. Si el Build problemático es 2.0.0, tu Build de reversión debería ser 2.0.1 o superior. Consulta la referencia de CFBundleVersion de Apple.
La versión visible para el usuario — versionName en Android, CFBundleShortVersionString en Apple — no tiene reglas técnicas. Úsala para que la situación sea legible: mantener 1.9 deja claro qué código se está ejecutando, mientras que 2.0.1 deja claro que es más nueva que la versión que reemplaza. Elige la que a tus usuarios les resulte menos confusa.
El procedimiento
Localiza el código fuente de la versión a la que vas a revertir y confirma el identificador de versión del Build problemático para saber qué tienes que superar.
Mismo código, nuevo identificador de versión — superior al del Build problemático. Esto ocurre en la configuración de tu proyecto o en tu pipeline de CI, no en Applivery.
Dale un versionName que deje claro su propósito, como v1.9 (rollback). Espera a que termine el procesamiento antes de continuar.
Abre el Build problemático y quita la tag de la Publicación afectada. Deja de servirse de inmediato.
La Publicación ahora sirve el Build de reversión, y los dispositivos lo ven como una actualización disponible.
Consulta Cuidado con las actualizaciones forzadas más abajo. Saltarte este paso puede dejar a los usuarios completamente bloqueados fuera de la app.
Ejemplo práctico
Problema:
Build v2.0 · versionCode 200 · activo en producción · defecto detectado
Reversión:
Recompila el código v1.9 · versionCode 201 (superior a 200)
Sube, y luego mueve la tag de producción del Build 200 al Build 201
Un dispositivo que está en 200 recibe 201, lo trata como una actualización y lo instala — pero el código que acaba ejecutando es la lógica estable de la 1.9.
Desde la API
Ambos cambios de tag usan PUT – Actualizar un Build.
El campo tags reemplaza el array completo. Envía todas las tags que el Build deba conservar, no solo la que estás cambiando.
# 1. Deja de servir el Build problemático
curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID_PROBLEM' \
-X PUT \
-H 'Authorization: Bearer YOUR_APP_TOKEN' \
-H 'Content-Type: application/json' \
-d '{ "tags": [] }'
# 2. Apunta el anillo al Build de reversión
curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID_ROLLBACK' \
-X PUT \
-H 'Authorization: Bearer YOUR_APP_TOKEN' \
-H 'Content-Type: application/json' \
-d '{ "tags": ["ring-production"] }'
El equivalente en la Workspace API es PUT https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID con un token de Service Account.
Si usas despliegue progresivo, revierte un anillo cada vez, empezando por el anillo donde apareció el problema.
Los dispositivos Apple se comportan de forma distinta según cómo se instaló la app
Apple no documenta qué ocurre cuando instalas una app cuyo CFBundleVersion es inferior al que ya está en el dispositivo, así que lo probamos nosotros mismos. En iOS 26.5, la misma app en el mismo dispositivo se comportó de dos formas opuestas según la vía de entrega:
| Cómo llega la app al dispositivo | Instalar un Build más antiguo |
|---|---|
| App Distribution — el usuario instala desde la Enterprise Store | El Build más antiguo se instala con normalidad |
| Device Management — Build asignado mediante MDM | El dispositivo mantiene la versión más nueva |
Cuando se asigna un Build más antiguo mediante Device Management, el dispositivo no baja de versión — y tampoco informa de ningún error. El comando se acepta, nada falla y la versión más nueva simplemente permanece instalada. Si estás revirtiendo por esta vía, el Dashboard no te avisará de que no ha pasado nada. Verifica la versión instalada antes de dar por hecho que los dispositivos están arreglados.
La consecuencia práctica:
Si distribuyes mediante la Enterprise Store, puedes revertir simplemente moviendo la tag de vuelta al Build anterior. Sin necesidad de recompilar.
Si despliegas mediante Device Management, mover la tag no basta. Tienes que recompilar con un identificador de versión superior, exactamente como se describe arriba.
Este comportamiento no está documentado por Apple, lo que significa que no está garantizado que se mantenga igual en futuras versiones de iOS. Nuestra prueba cubrió un dispositivo supervisado inscrito mediante Apple Business. Trata el atajo de la Enterprise Store como una comodidad, no como algo sobre lo que construir automatización — el procedimiento de roll-forward es el que sigue funcionando en cualquier caso.
Cuidado con las actualizaciones forzadas
Si tu App integra el SDK de Applivery con las actualizaciones forzadas activadas, aquí hay una trampa que conviene conocer.
Las actualizaciones forzadas bloquean el uso de la app cuando la versión instalada queda por debajo de un umbral de versión mínima que configuras en el Dashboard. Si ese umbral sigue apuntando a la versión problemática, tu Build de reversión queda por debajo de él — y cada usuario que lo instale queda bloqueado fuera de la app por el mismísimo arreglo que publicaste.
Reduce el umbral como parte de la reversión, no después de ella.
Una cosa juega a tu favor: el SDK siempre actualiza al Build más reciente disponible para la App, que coincida solo con el bundle ID o el package name. Se guía por la recencia, no por el número de versión, así que un Build de reversión recién subido se recoge como la actualización independientemente de dónde se sitúe su versión.
El SDK no respeta los filtros, grupos ni audiencias de las Publicaciones. Si necesitas que la reversión se limite a un anillo, ten en cuenta que las actualizaciones impulsadas por el SDK no respetan ese límite.
Después de la reversión
Conserva el Build problemático. No lo elimines — lo querrás para reproducir el defecto. Quitarle la tag basta para sacarlo de circulación.
Cuida los números de versión de ahí en adelante. Tu siguiente versión real tiene que superar al Build de reversión, no al problemático. Si la reversión fue
201, la versión corregida empieza en202.Avisa a la gente. Si la Publicación notifica a su audiencia, un mensaje explícito acelera las cosas — los usuarios que pospusieron la actualización anterior podrían ignorar también esta.
La forma más limpia de no necesitar esto nunca es detectar el defecto antes en un anillo pequeño. Consulta Despliegue progresivo con tags.