# Revertir una versión

> Revierte un Build problemático en Applivery App Distribution recompilando tu versión estable con un identificador de versión superior y moviendo la tag de la Publicación hacia él.

Source: https://docs.applivery.com/es/app-distribution/distribute/rolling-back-a-release/  •  Last updated: 2026-07-30

**Answers:** ¿Cómo revierto una versión en Applivery? · ¿Puedo simplemente reetiquetar el Build anterior en lugar de recompilar? · ¿Por qué se llama roll forward? · ¿Necesito cambiar la versión que ven los usuarios? · ¿Qué pasa si olvido reducir el umbral de actualización forzada?

**Key topics:** Procedimiento de reversión, Identificadores de versión, Tags de Build, Actualizaciones forzadas, Applivery, Builds, Publicaciones, SDK de Applivery

---

**TL;DR:** Recompila tu última versión estable con un identificador de versión superior, súbela y mueve la tag del anillo al nuevo Build. Recuerda reducir el umbral de actualización forzada del SDK si usas uno.

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.

:::info
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](https://developer.android.com/guide/topics/manifest/manifest-element) 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 |

:::warning
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](https://developer.apple.com/documentation/bundleresources/information-property-list/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

**Identifica la última versión estable conocida**

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.

**Recompílala con un identificador de versión superior**

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.

**Sube el Build recompilado**

Dale un `versionName` que deje claro su propósito, como `v1.9 (rollback)`. Espera a que termine el procesamiento antes de continuar.

**Quita la tag del Build problemático**

Abre el Build problemático y quita la tag de la Publicación afectada. Deja de servirse de inmediato.

**Añade la tag al Build de reversión**

La Publicación ahora sirve el Build de reversión, y los dispositivos lo ven como una actualización disponible.

**Reduce el umbral de actualización forzada, si usas uno**

Consulta [Cuidado con las actualizaciones forzadas](#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

```text
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](https://docs.applivery.com/es/app-distribution/api/builds/update-build/).

:::warning
El campo `tags` **reemplaza el array completo**. Envía todas las tags que el Build deba conservar, no solo la que estás cambiando.
:::

```bash
# 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](https://docs.applivery.com/es/app-distribution/distribute/progressive-deployment/), 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 |

:::warning
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.

:::info
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](https://docs.applivery.com/es/app-distribution/sdk/) 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.

:::info
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 en `202`.

-   **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.

:::tip
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](https://docs.applivery.com/es/app-distribution/distribute/progressive-deployment/).
:::