Respuesta corta: sí, Apple permite los Live Updates, con ciertos límites. Puedes enviar nuevo JavaScript, HTML y CSS a una app de iOS sin una nueva revisión de la App Store, siempre que la actualización no cambie la función de la app. No puedes descargar code nativo.
La confusión suele venir de mezclar dos cosas: Live Updates de code interpretado (permitido) y la descarga de nuevo code ejecutable (no permitido). Esta página cita las reglas, marca el límite y explica cómo Apple lo aplica.
Esto no es asesoría legal. Es cómo se leen las reglas hoy y cómo miles de apps las usan en producción.
Lo que realmente dicen las reglas de Apple
Dos textos son clave. El primero es Directriz 2.5.2 de revisión de la App Store:
Las apps deben ser autónomas en sus bundles, y no pueden leer ni escribir datos fuera del área del contenedor designado, ni pueden descargar, instalar o ejecutar code que introduzca o cambie funciones o la funcionalidad de la app, incluyendo otras apps.
Leído por sí solo, parece una prohibición. La excepción está en el segundo texto, la sección 3.3.1(B) del Acuerdo de licencia del Apple Developer Program, que todo desarrollador firma:
Se puede descargar code interpretado en una Aplicación, pero solo siempre que dicho code: (a) no cambie el propósito principal de la Aplicación mediante funciones o funcionalidades que sean inconsistentes con el propósito previsto y anunciado de la Aplicación tal como se envió a la App Store, (b) no cree una tienda o escaparate para otros code o aplicaciones, y (c) no eluda el firmado, el sandbox u otras funciones de seguridad del SO.
Así que la regla no es “no descargar code”. Es “no descargar native code, y solo code interpretado bajo tres condiciones”.
La capa web de una app Capacitor es JavaScript, HTML y CSS que se ejecutan en WKWebView, que es el propio motor WebKit de Apple. Eso se interpreta como code, así que entra en la excepción. La directriz 4.7 va en la misma línea: Apple permite explícitamente que las apps ejecuten contenido HTML5 y JavaScript que no esté incrustado en el binario.
Dónde está el límite
| Permitido con un live update | No permitido con un live update |
|---|---|
| Correcciones de bugs en tu JavaScript, HTML o CSS | Descargar Swift, Objective-C o cualquier binario compilado |
| Cambios de UI, de copy o nuevas pantallas en tu stack web actual | Transformar la app en un producto distinto (de una app de notas a un casino) |
| A/B tests y rollouts graduales de web code | Desbloquear funciones ocultas a App Review |
| Actualizar imágenes, traducciones o config | Crear una tienda que instale otras apps o code |
| Revertir un release fallido | Evadir el sandbox, la firma o permisos de iOS |
Capgo solo envía la columna izquierda. Reemplaza el web bundle dentro de tu app. Cualquier cambio nativo, como un nuevo plugin Capacitor, un nuevo permiso o una actualización de SDK, requiere un release normal en la App Store. Los Capgo de segmentación de versiones aseguran que un bundle que requiere nuevos code nativos nunca llegue a un binario antiguo.
Cómo lo aplica Apple
Apple evalúa el fondo, no la tecnología. Nadie será sancionado por corregir un typo vía OTA. El patrón que Apple persigue es una app que pasa la revisión como una cosa y se convierte en otra después. Eso infringe la guía 2.3.1 (sin funciones ocultas) tanto como la 2.5.2.
En la práctica:
- Envía lo que habrías subido, solo que más rápido.
- Mantén cada update dentro del propósito descrito en tu ficha de la App Store.
- Lanza grandes features vía App Review, y usa live updates para fixes e iteraciones entre releases.
- Nunca uses un live update para activar comportamientos que los reviewers no vieron.
Si sigues eso, los Live Updates son una parte normal al lanzar una app de iOS. Los equipos de React Native lo han hecho por años con CodePush y Expo Updates, y los equipos de Capacitor lo hacen con Capgo.
¿Qué stacks pueden hacerlo en iOS?
Si tu app puede enviar actualizaciones over-the-air en iOS depende de una pregunta: ¿la lógica de tu app se interpreta en runtime? JavaScript y otros code interpretados, sí. Swift, Objective-C y C++ compilados a code de máquina, no. Los frameworks con compilación AOT como Flutter solo califican mediante un intérprete.
Compatibilidad de live update en iOS por stack
| Stack | Cómo se ejecuta el code en iOS | ¿Permite Live Updates? | Herramientas |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS en WKWebView (WebKit) | Sí | Capgo |
| Ionic (en Capacitor) | Igual que Capacitor | Sí | Capgo |
| Cordova | JavaScript en WKWebView | Sí | Capgo tras migrar a Capacitor, plugins de Cordova antiguos |
| React Native / Expo | bundle de JavaScript en Hermes o JavaScriptCore | Sí, solo JavaScript | Expo Updates, alternativas self-hosted a CodePush |
| NativeScript | JavaScript en un motor embebido | Sí, solo JavaScript | Limitado, mayormente self-built |
| Flutter | Dart compilado AOT a código máquina code | Solo mediante un intérprete | Shorebird (intérprete de Dart para parches) |
| Swift / Objective-C nativo | Código máquina code | No para code nativo; sí para JavaScript en WebKit o JavaScriptCore | Configuración remota y UI server-driven |
| .NET MAUI / Xamarin | C# compilado AOT a code de máquina | No | Solo configuración remota |
| Kotlin / Compose Multiplatform | Kotlin/Native compilado a code de máquina | No | Solo configuración remota |
| Unity / Unreal | C# vía IL2CPP o C++, compilado | No para code, sí para contenido | Asset bundles, contenido con scripts (Lua) |
| Web wrapper (URL remota) | Sitio web cargado en un WebView | Siempre en vivo, pero con riesgo de revisión | Ninguna necesaria, ver nota abajo |
Capacitor, Ionic y Cordova: totalmente cubiertos
La UI web y la lógica de negocio en JS de tu app corren en WKWebView, mientras que el shell nativo y los plugins siguen siendo nativos. La sección 3.3.1(B) del Apple Developer Program License Agreement permite code interpretado descargado solo si mantiene el propósito principal de la app, no crea una code storefront y no evade la seguridad del OS. La Guideline 4.7 regula por separado las apps que ofrecen mini apps en HTML5 y JavaScript y añade requisitos adicionales.
Un live update reemplaza el web bundle. El shell nativo, los plugins y los permisos siguen siendo los que Apple revisó. Por eso Capgo es compliant por diseño: no puede cambiar los code nativos aunque lo intentes. Los nuevos plugins o permisos nativos aún requieren un release en la App Store.
React Native y Expo: JavaScript sí, módulos nativos no
React Native ejecuta tu JavaScript bundle en Hermes o JavaScriptCore. Ese bundle es code interpretado y puede actualizarse over the air, que es para lo que fueron creados Expo Updates y Microsoft CodePush (retirado en 2025). Equipos dejando CodePush buscan un reemplazo.
Cualquier cambio en módulos nativos, la versión de React Native o Info.plist requiere un nuevo binario.
Flutter: solo mediante un intérprete
En iOS, Flutter compila Dart de forma anticipada a código máquina ARM code. Descargar nuevo code está prohibido, por lo que el Flutter estándar no puede usar live updates. Shorebird lo resuelve ejecutando code de Dart parcheado en un intérprete, lo que entra en la excepción de code interpretado. Lee más en live updates para apps Flutter.
Swift nativo, .NET MAUI, Kotlin Multiplatform: sin actualizaciones de code nativo
Estos stacks generan code de máquina nativa. No pueden descargar code nativo de reemplazo. Una app nativa aún puede descargar y ejecutar code interpretado, como JavaScript vía JavaScriptCore, si cumple las condiciones de Apple. Lo que también puedes hacer OTA es cambiar datos: remote config, feature flags de funciones ya revisadas, server-driven UI, imágenes y copy.
Unity y motores de juegos: contenido sí, code no
El code del juego está compilado. Los asset bundles (niveles, arte, datos de balanceo) son contenido y se pueden descargar. Lenguajes de scripting embebidos como Lua son code interpretados y siguen las mismas reglas que JavaScript.
Wrappers de URL remotos: funcionales, pero riesgosos para review
Una app que solo carga tu web en un WebView se "actualiza" cada vez que despliegas el sitio. El problema no es la directriz 2.5.2, sino la 4.2 (funcionalidad mínima): Apple rechaza apps que son solo un sitio web en un frame. Empaquetar la web app con Capacitor, añadir funciones nativas y usar live updates evita esto.
Lo que ningún stack puede hacer en iOS
Sea cual sea tu framework, un live update no puede:
- Descargar code nativos, frameworks o librerías dinámicas
- Añadir nuevos permisos o entitlements
- Convertir la app en algo que no describa su ficha en la App Store
- Activar funciones que se ocultaron durante el App Review
Próximos pasos
- La respuesta de Android: ¿Permite Google los live updates sin revisión de la Play Store?
- Detalles sobre la aplicación de reglas: Cómo Apple aplica las restricciones de actualizaciones OTA
- Flujo de aprobación: Capacitor OTA updates: guía de aprobación de App Store
- Historias de rechazos reales: Historias de terror con rechazos en App Store
Lanza fixes hoy, no tras la revisión
actualizaciones Live Update de Capgo envía cambios de JavaScript, HTML y CSS a tu app Capacitor en minutos, con channels, rollbacks, delta updates y cifrado de extremo a extremo. Es open source y puedes self-hostearlo.
bunx @capgo/cli@latest initSigue la guía rápida para enviar tu primer update.
