Conceptos básicos de actualizaciones OTA

10 ejemplos para que comiences con actualizaciones Over-The-Air (OTA) en Expo SDK 57 - qué puede cambiar EAS Update en minutos versus qué aún requiere un envío de App Store o Play Store.

Requisitos previos

Las actualizaciones OTA requieren expo-updates en un binario de release o preview - no en Expo Go.

npx create-expo-app@latest MyOtaApp --template blank-typescript
cd MyOtaApp
npx expo install expo-updates
npx eas init
npx eas update:configure

Herramientas: Estos ejemplos tienen como objetivo Expo SDK 57 (expo ~57.0.4), React Native 0.86.0 y React 19.2.3.

Ejemplos básicos

1. Dos rutas de entrega: OTA vs tienda

Cada decisión de lanzamiento móvil comienza con una pregunta: ¿este cambio toca código nativo?

Cambio solo en JavaScript / assets     ->  eas update (minutos)
Shell nativo / permisos / SDK          ->  eas build + envío a tienda (días)

• OTA reemplaza el bundle de JS y los assets descargables en dispositivos que ya tienen un binario compatible
• Compilación de tienda reemplaza el shell nativo - runtime Hermes, módulos nativos, entitlements, iconos
• Los usuarios en versiones antiguas de tienda permanecen en su línea de runtime hasta que actualicen el binario
• Consulta Release & OTA Rules para la lista de verificación de promoción completa

Relacionado: expo-updates (Client API) - comprobación y aplicación de actualizaciones desde código de la app

2. Corregir un bug de componente React (OTA-Safe)

Los errores de lógica pura en JavaScript son el caso de uso clásico de OTA - sin cruzar el límite nativo.

// src/screens/CheckoutScreen.tsx - corrección de typo se envía por OTA
export function CheckoutScreen() {
  const total = useCartTotal();
 
  return (
    <View>
      <Text>Total: {formatCurrency(total)}</Text>
      {/* Corregido: se estaba dividiendo por 100 dos veces */}
      <PrimaryButton label="Pagar ahora" onPress={submitPayment} />
    </View>
  );
}

# Después del soak de preview
eas update --channel production --environment production --message "Corregir display del total de checkout"

• Árboles de componentes, hooks, estilos y estructura de navegación son OTA-safe
• Envía a preview primero; soak antes de production en rutas de ingresos
• Empareja con monitoreo de crashes - OTA es rápido, no sin riesgos

Relacionado: Release Channels & Branches - promoción de staging a production

3. Intercambiar assets de imagen (OTA-Safe)

Las imágenes agrupadas, las fuentes referenciadas desde JS y JSON de Lottie se envían con el manifest de actualización.

// src/components/HeroBanner.tsx
import heroImage from "@/assets/hero-summer.png";
 
export function HeroBanner() {
  return <Image source={heroImage} style={{ width: "100%", height: 200 }} />;
}

• Los cambios de assets en el bundle de Metro son OTA-safe
• App icon y splash screen son nativos - requieren un nuevo binario
• Las adiciones de assets grandes afectan el tamaño del bundle y el TTI - monitorea presupuestos de rendimiento

4. Agregar un módulo nativo (Se requiere tienda)

Instalar un paquete con código nativo cambia la salida en ios/ y android/ - OTA no puede hacerlo.

# Esta secuencia requiere eas build + envío a tienda, NO eas update solo
npx expo install react-native-vision-camera

// app.config.ts - nuevo plugin = reconstrucción nativa
export default {
  expo: {
    plugins: [
      [
        "react-native-vision-camera",
        { cameraPermissionText: "Necesitamos acceso a la cámara para escanear códigos." },
      ],
    ],
  },
};

• El diff de npx expo prebuild es la señal - si hay cambios en el proyecto nativo, planea una compilación de tienda
• Nunca envíes JS que importe el nuevo módulo por OTA antes de que los binarios existan en tiendas
• Cierra pantallas dependientes de nativos detrás de flags de características hasta que la adopción en tienda cruce tu umbral

Relacionado: EAS Build Basics - binarios en la nube que reciben actualizaciones

5. Cambiar strings de permisos en Info.plist (Se requiere tienda)

El texto de permiso vive en manifests nativos - los usuarios ven texto antiguo si haces OTA sin reconstruir.

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSCameraUsageDescription": "Escanea códigos de barras para agregar artículos a tu carrito."
      }
    },
    "android": {
      "permissions": ["android.permission.CAMERA"]
    }
  }
}

• Cualquier cambio de infoPlist, permissions o entitlements necesita eas build
• App Review lee strings de permisos en el binario, no en el bundle de JS
• Documenta cambios de permisos en notas de lanzamiento de tienda, no solo en changelogs de OTA

6. Bump de Expo SDK (Se requiere tienda)

Las actualizaciones de SDK cambian el runtime nativo, la versión de Hermes y las dependencias nativas por defecto.

{
  "dependencies": {
    "expo": "~57.0.4",
    "react": "19.2.3",
    "react-native": "0.86.0"
  }
}

• Después de actualizar SDK: eas build para todos los perfiles, luego resume eas update en la nueva línea de runtime
• Los binarios antiguos en el runtime anterior dejan de recibir actualizaciones en la nueva línea
• Planifica mensajería de usuario cuando se requiere aplicación de versión nativa mínima

Relacionado: Runtime Version Policy - estrategias de appVersion, nativeVersion y fingerprint

7. runtimeVersion es la puerta de compatibilidad

runtimeVersion le dice a EAS Update qué bundles de JS puede descargar un binario. Desajuste = omisión silenciosa.

// app.config.ts
export default {
  expo: {
    version: "2.4.0",
    runtimeVersion: {
      policy: "appVersion",
    },
    updates: {
      url: "https://u.expo.dev/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    },
  },
};

# Build integra runtime 2.4.0
eas build --profile production --platform all
 
# Update debe apuntar al mismo runtime
eas update --channel production --environment production

• Los artefactos de eas build y los bundles de eas update deben compartir el mismo runtimeVersion resuelto
• Verifica con npx expo config --type public | jq '.runtimeVersion'
• La política incorrecta abandona a los usuarios en JS obsoleto sin un error obvio - prueba en dispositivos de preview

Relacionado: expo-updates Configuration - app.config cookbook completo

8. Tabla de decisión OTA vs tienda

Copia esta tabla en tu runbook de lanzamiento y requiere una casilla de verificación por cambio.

• Cuando una fila dice ⚠️, OTA es técnicamente posible pero necesita QA extra y planificación de rollback
• Las filas de ingresos, autenticación y pago por defecto van a soak de preview sin importar diffs "pequeños"

9. Cierra JS hasta que los binarios se pongan al día

OTA te deja enviar JS rápido; los flags de características te dejan controlar quién lo ejecuta.

// src/features/barcode/useBarcodeScanner.ts
import * as Application from "expo-application";
 
const MIN_NATIVE_FOR_SCANNER = "2.4.0";
 
export function useBarcodeScannerEnabled(remoteFlag: boolean) {
  const nativeVersion = Application.nativeApplicationVersion ?? "0.0.0";
  const nativeReady = compareSemver(nativeVersion, MIN_NATIVE_FOR_SCANNER) >= 0;
  return remoteFlag && nativeReady;
}

• Los flags remotos deshabilitan rutas malas inmediatamente - más rápido que republicar una OTA
• Application.nativeApplicationVersion refleja el binario de tienda, no el ID del bundle de OTA
• La autorización del servidor aún refuerza el acceso - los flags son UX, no seguridad

Relacionado: Feature Flags for Safe Rollout - kill switches junto con OTA

10. Sabe qué bundle se está ejecutando

El soporte y la respuesta a incidentes necesitan el ID de actualización - no solo la versión de marketing.

// app/_layout.tsx (solo diagnósticos de dev/preview)
import * as Updates from "expo-updates";
import { useEffect } from "react";
 
export default function RootLayout() {
  useEffect(() => {
    if (__DEV__) return;
    console.info("[updates]", {
      updateId: Updates.updateId,
      runtimeVersion: Updates.runtimeVersion,
      channel: Updates.channel,
      isEmbeddedLaunch: Updates.isEmbeddedLaunch,
    });
  }, []);
 
  return <Stack />;
}

• Updates.updateId identifica el bundle de OTA; Updates.isEmbeddedLaunch verdadero significa que aún no se ha aplicado OTA
• Registra en analytics en preview/production - redacta en pantallas públicas orientadas al usuario
• Mantén el ID de última actualización conocida como buena en tickets de lanzamiento para Rollback Runbook

Preguntas frecuentes

Relacionado

• expo-updates Configuration - runtimeVersion, URL, check-on-launch
• Release Channels & Branches - workflow de promoción de canales
• Runtime Version Policy - guía de selección de política
• expo-updates (Client API) - cliente check/fetch/reload
• EAS Build Basics - binarios que reciben cargas de OTA
• Release & OTA Rules - lista de verificación de aplicación de equipo

Versiones de stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).