Saltar al contenido principal
Tutorial

Reglas de Apple Remote Code y Capgo Live Updates

La Directriz 2.5.2 de App Review, la ADPLA 3.3.1(B) y la aclaración de 2025 sobre mini-apps en la Directriz 4.7 cubren el code nativo remoto, las excepciones de code interpretado y los catálogos de mini-apps. El JavaScript firmado en tu WebView de Capacitor aún puede calificarse como code interpretado si mantienes el propósito revisado de la app, respetas la seguridad del SO y te mantienes dentro de la ADPLA 3.3.1(C). Así es como encaja Capgo en ese modelo.

Reglas de ejecución remota de code de Apple y actualizaciones en vivo de Capgo Capgo ilustración del blog

Equipos que publican live updates de Capacitor siguen haciendo la misma pregunta después de que los correos de revisión de Apple mencionan ejecución remota de code: ¿eso bloquea Capgo?

Para la mayoría de las apps de Capacitor, no. Capgo reemplaza el web bundle que tu app ya ejecuta. No descarga Swift, frameworks ni bytecode, y no convierte tu producto en una mini app store. Las reglas que cita Apple son reales, pero apuntan a un tipo de comportamiento distinto al de JavaScript firmado entregado a WKWebView o JavaScriptCore.

Esto es orientación técnica, no asesoría legal. Lee el texto publicado por Apple y consulta a un abogado para tu app.

Los tres textos que citan los revisores

Directriz de revisión de apps 2.5.2

Directriz 2.5.2 dice que las apps no pueden “descargar, instalar o ejecutar code que introduzca o cambie funciones o funcionalidad de la app, incluidas otras apps”.

Los equipos de revisión usan esa frase cuando ven:

  • dlopen, dlsym, o carga dinámica similar,
  • performSelector: y otros hooks de runtime hacia APIs privadas, o
  • scripts remotos cuya función es cambiar el comportamiento nativo tras su aprobación.

Ese es el ejecución remota de code patrón en las cartas de rechazo. No es una prohibición de cada byte descargado tras la instalación.

sección 3.3.1(B) de la ADPLA (interpretación code)

El Acuerdo de licencia del Apple Developer Program sección 3.3.1(B) permite interpretación code descargarse cuando:

  1. no cambia el propósito principal de la app,
  2. no elude la firma, el sandbox ni otras funciones de seguridad del SO, y
  3. no crea una tienda o escaparate para otras aplicaciones.

La capa web de Capacitor es code interpretada por diseño. Capgo sustituye esa capa después de que tus usuarios instalen el binario revisado desde la App Store.

Sección 3.3.1(C) del ADPLA (funciones adicionales)

Sección 3.3.1(C) añade otra salvaguarda: sin la aprobación previa por escrito de Apple o un permiso 3.3.9(A) de In-App Purchase, una app no puede proporcionar, desbloquear ni habilitar funciones o funcionalidades adicionales a través de mecanismos de distribución distintos a App Store, Custom App Distribution o TestFlight.

Que un bundle OTA específico cruce esa línea es una decisión legal de tu equipo. Capgo no la toma por ti. La checklist de cumplimiento menciona la 3.3.1(C) para que puedas evaluar cada release.

La directriz 4.7 y la aclaración de noviembre de 2025

Apple’s November 13, 2025 guideline refresh aclaró la directriz 4.7 para apps que ofrecen HTML5 y JavaScript mini apps, mini juegos, chatbots, plugins y software similar que no estén embebidos en el binario.

Si los usuarios navegan o lanzan muchas experiencias de software distintas dentro de tu app, podrías necesitar los mecanismos de catálogo, indexación y clasificación por edad de la 4.7. La propiedad de los bundles no decide la cuestión. La experiencia que publicas hace.

Capgo es un canal de entrega para tus bundles en tus canales. Por sí solo, no es un marketplace 4.7. Si tu producto es un host white-label o una plataforma de mini apps, toma 4.7 en serio antes de depender de OTA.

Lo que Capgo realmente envía

Capa Comportamiento de Capgo
Binario nativo Sin cambios. Los nuevos plugins, permisos y entitlements requieren un build para la tienda.
Recursos web JavaScript, HTML, CSS, fuentes, imágenes y archivos estáticos firmados reemplazan el bundle de la app.
Ejecución Se ejecuta dentro del WebView o del motor JavaScriptCore que Apple ya aprobó con tu shell.
Cifrado El cifrado de extremo a extremo opcional mantiene el contenido del bundle ilegible para Capgo en tránsito y en almacenamiento.

Capgo te ayuda a publicar fixes de la capa web en minutos, revertir bundles defectuosos en un canal y mantener los releases nativos en la ruta de la App Store. Miles de apps en producción usan esa separación sin convertir las actualizaciones en vivo en un cargador nativo remoto.

Reglas prácticas para tu equipo

  • Usa OTA para bugs, UI, copy y mejoras dentro del producto que Apple revisó.
  • Envía un nuevo binario cuando cambien el code nativo, los SDKs, permisos o entitlements.
  • No uses actualizaciones en vivo para modificar modelos de precios, desbloquear funciones ocultas o cambiar el propósito de la app.
  • Document how updates work in App Review notes when asked.
  • Lee la sección completa de Apple remote code y Capgo antes de tu próximo release.

Para ver la vista de producto (channels, rollback, signing), empieza en live updates de Capacitor. Para profundizar en la política, usa el doc de compliance de arriba o el tutorial anterior en ¿Permite Apple los live updates?.

Live updates para apps Capacitor

Cuando un bug de la capa web está en producción, publica el fix a través de Capgo en lugar de esperar días a la aprobación de la app store. Los usuarios reciben la actualización en segundo plano mientras los cambios nativos siguen el flujo de revisión habitual.

Lo último de nuestro blog

Capgo te da la información clave que necesitas para crear una app móvil realmente profesional.