Busca en todas las páginas de la documentación
Nomenclatura de canales EAS Update, política de versiones de runtime, flujo de promoción y triggers de reversión para Expo SDK 57. Las actualizaciones OTA son poderosas y peligrosas - JavaScript puede llegar a producción en minutos sin revisión de tienda. Estas reglas separan cambios OTA seguros de versiones que rompen nativas y definen cuándo hacer rollback.
eas update - una runtimeVersion incorrecta deja a usuarios atrapados en bundles obsoletos silenciosamente.eas update con monitoreo de bloqueos y feature flags - OTA sin observabilidad es vuelo a ciegas.Establece política explícita de runtimeVersion en app.config: Usa policy: "appVersion", "sdkVersion" o "fingerprint" consistentemente - documenta qué política usa tu equipo en README.
runtimeVersion en artefactos de eas build debe coincidir con lo que eas update apunta.runtimeVersion esperando que EAS adivine correctamente entre sabores.Incrementa runtime cuando cambien las dependencias nativas: Nuevo módulo nativo, actualización de SDK o cambio de plugin de configuración - nueva compilación de tienda y nuevo runtime. OTA solo no puede agregar código nativo.
Configura updates.url y project ID para EAS Update: extra.eas.projectId y updates.url en app.config - verifica con npx expo config --type public.
projectId y canales distintos por bundle ID.eas update:list muestra bundles recientes después de una publicación de prueba.Usa eas update --environment <name> en SDK 55+: Los corredores de actualización cargan variables del entorno EAS nombrado - los archivos .env locales se ignoran, manteniendo OTA alineado con el entorno de compilación.
eas update --channel production --environment production..env.local obsoleto.Revisa las actualizaciones al lanzar con una política sensata: expo-updates checkAutomatically y fallbackToCacheTimeout - equilibra la frescura con el inicio sin conexión.
Firma de código para actualizaciones cuando sea requerido: Habilita la firma de código de EAS Update para aplicaciones de alta seguridad - verifica la rotación de certificados de firma en el runbook.
Los nombres de canales se asignan a entornos, no a personas: development, preview, staging, production - no jane-test o hotfix-tuesday.
eas.json asignan channel por perfil.El flujo de promoción es lineal: development - preview (QA) - production - no saltes vista previa para cambios JS "pequeños" que tocan pagos o autenticación.
production directa desde una rama de feature sin soak de vista previa.Las compilaciones de vista previa se emparejan con el canal de vista previa: QA instala el binario del perfil de preview de EAS y recibe OTA en el canal preview - coincide con el comportamiento de producción sin riesgo de tienda.
Las actualizaciones del canal de producción requieren regla de dos personas o publicación solo en CI: eas update --channel production manual desde laptops es propenso a errores - prefiere GitHub Action en versión etiquetada.
eas update:list revisado en ticket de versión.Versionea version de app.config y números de compilación de tienda independientemente: Versión de marketing vs ios.buildNumber / android.versionCode - incrementa números de compilación en cada presentación de tienda.
runtimeVersion: { policy: "appVersion" }, los cambios de versión de aplicación afectan al targeting de OTA.Los feature flags bloquean cargas útiles OTA arriesgadas: Los flags remotos pueden desactivar rutas JS defectuosas sin una segunda OTA - los flags no son un sustituto para pruebas de vista previa.
Seguro para OTA: JS, TS, activos, copia, estilos, estructura de navegación: Cambios puros de JavaScript que no llaman nuevos símbolos nativos.
Requerido en tienda: módulos nativos, plugins, permisos, scheme, entitlements: Cualquier cosa que cambie la salida de ios/ o android/ desde prebuild.
Bytecode de Hermes y regresiones de tamaño de bundle pueden enviar OTA - trata como eventos de versión: Los bundles grandes ralentizan el inicio - observa presupuestos de rendimiento (ver Performance Budget Rules).
Los cambios de esquema de base de datos y contrato de API necesitan compatibilidad hacia atrás: Los usuarios móviles saltan actualizaciones - JS debe tolerar respuestas de API antiguas hasta que la adopción de tienda sea alta.
No hagas OTA de cambios que rompen la forma del almacenamiento local persistente sin migración: Los cambios de esquema MMKV/SQLite necesitan migración elegante o compuerta de versión - una mala migración rompe instalaciones.
OTA de emergencia todavía pasa a través de vista previa cuando es posible: Un sev-1 verdadero puede saltarse soak - documenta excepción y requiere postmortem más verificación de rollback dentro de una hora.
Define triggers de reversión antes del lanzamiento:
| Trigger | Propietario | Acción |
|---|---|---|
| La tasa libre de bloqueos cae > X% vs baseline | Mobile on-call | Republica bundle anterior o redirección de canal |
| Pico en tasa de fallo de autenticación/login | Backend + mobile | Rollback OTA + flag off |
| Caída en tasa de éxito de pagos | Revenue + mobile | Rollback de producción inmediato |
| Problema de seguridad P0 en JS | Security + mobile | Corrección OTA o rollback dentro del SLA |
Sabe cómo hacer rollback de una Actualización EAS: Republica bundle ID anterior a canal, o usa rollback de dashboard EAS - practica en vista previa trimestralmente.
El rollback de tienda es más lento - planifica fallback binario: Mantén la versión anterior de tienda disponible; rollout en fases en App Store y rollout staged en Play Store cuando sea posible.
Monitorea después de cada OTA de producción durante 24 horas: Dashboards de Sentry, analytics y error de API - on-call vigila sin asumir éxito en tiempo de publicación.
Alertas de desajuste de runtime: Usuarios en binarios antiguos que nunca reciben actualizaciones - rastrea fallos de expo-updates check y versiones de runtime obsoletas en analytics.
La checklist de versión tiene dos pistas: Checklist de presentación de tienda (nativa, capturas, revisión) y checklist de OTA (soak de vista previa, flags, ID de rollback) - adjunta ambas a tickets de versión.
Retrospectiva posterior a la versión para cualquier rollback: Actualiza triggers, duración de vista previa o compuertas de CI - los rollbacks son lecciones gratis si están documentadas.
appVersion vincula runtime a la versión de marketing - simple para muchas aplicaciones. fingerprint hashea el estado del proyecto nativo - mejor cuando el código nativo cambia sin cambios de versión. Elige una política, documéntala y nunca mezcles inconsistentemente entre sabores.
No - los bloqueos nativos necesitan una nueva compilación de tienda. OTA arregla solo errores de JavaScript y bugs de lógica.
Mínimo: desarrollo, vista previa, producción. Organizaciones más grandes agregan staging. Evita canales por desarrollador - usa compilaciones de vista previa con actualizaciones basadas en rama en su lugar.
En SDK 55+, eas update --environment usa solo variables de entorno EAS - .env local se ignora en corredores. Alinea con cómo eas build resuelve env.
Obligatorio para correcciones de seguridad y cambios de contrato de API que rompen. Banner opcional para ajustes de UI. Documenta UX en estrategia de recarga de expo-updates.
Los flags desactivan rutas de código en bundles ya enviados - más rápido que rollback de OTA para errores de lógica. Los flags no reemplazan pruebas de vista previa o autorización de servidor.
Mínimo 24 horas para rutas de autenticación y pago; más corto solo con fuerte cobertura automatizada y cobertura on-call. Excepciones Sev-1 documentadas post-hoc.
No - cada bundle ID y proyecto EAS necesita canales y líneas de runtime distintos. El monorepo JS compartido puede publicar por aplicación con comandos eas update separados.
Usa compilaciones de cliente de vista previa/dev apuntando al canal development. Las configuraciones de dev de expo-updates pueden anular la URL de actualización en staging controlado - no en aplicaciones de producción.
Versión de tienda, números de compilación, bundle ID de OTA, canal, último ID de rollback conocido como bueno, feature flags tocados, ventana de soak de vista previa y enlaces a dashboards.
Fuertemente recomendado - las etiquetas disparan eas update con environment producción. La publicación de laptop break-glass requiere aprobador segundo y postmortem.
La actualización de SDK cambia binarios nativos - nueva compilación de tienda, nueva línea runtimeVersion. Los runtimes antiguos dejan de recibir actualizaciones en la nueva línea nativa; planifica mensajería de actualización de usuario.
Esperado - los usuarios en compilaciones de tienda antiguas permanecen en su canal de runtime hasta que actualicen el binario. Rastrea distribución de runtime y aplica versión nativa mínima cuando sea necesario.
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).
Revisado por Chris St. John·Última actualización: 9 jul 2026