Rechazo en App Store
La Directriz 2.5.2 prohíbe que las apps descarguen o ejecuten código que cambie lo que hace la app después de la revisión. Una app web cargada en WKWebView no es lo que persigue Apple, así que una app normal de WebViewGold está a salvo. Los problemas empiezan cuando tu app ejecuta código con el que no se publicó: mini apps generadas por IA, plugins de usuarios o SDKs de hot-patching.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
La Directriz 2.5.2 pide que las apps sean autocontenidas en su paquete. No pueden leer ni escribir datos fuera de su propio contenedor, y no pueden descargar, instalar ni ejecutar código que introduzca o cambie características o funcionalidades, ni las suyas ni las de otra app. Hay una excepción muy limitada: las apps educativas que enseñan programación pueden permitir que los alumnos descarguen y ejecuten código, siempre que ese código no se use para nada más y el usuario pueda ver y editar el código fuente por completo.
La directriz se apoya en el Apple Developer Program License Agreement, cuya regla sobre el código interpretado descargado (la sección 3.3.1(B) en las versiones recientes) Apple ha citado en estos casos. A grandes rasgos, el código interpretado descargado solo es aceptable si no cambia el propósito principal de la app, no crea una tienda de otro código o de otras apps y no esquiva la firma, el sandbox u otras funciones de seguridad. Lee el acuerdo vigente en tu cuenta de desarrollador para conocer la redacción exacta.
La Directriz 2.5.6 exige que las apps que navegan por la web usen WebKit, y WebViewGold hace exactamente eso: tu app web se ejecuta en WKWebView, el propio motor de Apple, dentro del sandbox de la app. Actualizar el sitio web tras la aprobación es como funciona cualquier app basada en web, y es lo que hacen las apps de WebViewGold desde 2014.
Lo que le importa a Apple es el propósito, no de dónde vienen los archivos. Un registro de hábitos que recibe un gráfico nuevo en su sitio web sigue siendo un registro de hábitos. Un registro de hábitos que se convierte en un casino mediante un interruptor remoto después de la aprobación incumple la 2.5.2 y la regla de funciones ocultas de la 2.3.1, sea cual sea la tecnología que trajo el cambio. Si una actualización web cambia lo que es la app, publícala como actualización en el App Store con notas de revisión honestas; la guía sobre actualizaciones web frente a nativas muestra qué cambios necesitan una compilación nueva.
La nota suele decir que la app, una extensión o un framework enlazado parece contener código que puede cambiar el comportamiento o la funcionalidad de la app después de la revisión, o que la app descarga o ejecuta código. A veces nombra un framework de tu proyecto; otras veces describe una función que usó el revisor, por ejemplo que la app permite a los usuarios crear y ejecutar apps o que carga plugins ejecutables. El revisor te pide que elimines esa capacidad y vuelvas a enviar la app.
¡Gran trabajo! Nunca tuve que usar código para nada, pero logré trabajar con esto y tener mi App lista. ¡Fácil y rápido! ¡También con gran ayuda de los creadores!
| Qué hace tu app | Veredicto | Por qué |
|---|---|---|
| Carga tu app web desde tu dominio en WKWebView; tú despliegas las actualizaciones | Bien | Contenido web en WebKit, con el mismo propósito que se revisó |
Incluye la app web en local-www (uselocalhtmlfolder) o guarda una copia sin conexión con zipfiledownloadfromserver | Bien | Tu propia app, renderizada por WebKit; el mismo razonamiento que para el sitio en vivo |
| Una IA devuelve texto, imágenes o datos estructurados que tu código muestra | Bien según la 2.5.2 | Contenido, no código; se aplican las reglas de moderación de la Directriz 1.2 |
| Una IA o tus usuarios generan mini apps HTML/JS que se ejecutan dentro de tu app | Riesgo alto | Software nuevo ejecutándose en tu app: como mínimo se aplican las obligaciones de la Directriz 4.7, y en 2026 se rechazaron creadores de apps por esto |
| Plugins o extensiones que los usuarios instalan desde un catálogo | Solo dentro de la 4.7 | Índice, moderación, In-App Purchase para bienes digitales, ninguna API nativa expuesta |
| Frameworks nativos o scripts que parchean la app en tiempo de ejecución (SDKs de hot-patching) | Rechazado | El caso clásico de la 2.5.2; Apple ya advirtió a los desarrolladores sobre estos frameworks hace años |
| Un indicador remoto que activa otra app distinta tras la aprobación | Rechazado, con riesgo de retirada | Funciones ocultas (2.3.1) y un propósito cambiado |
| Un curso de programación en el que los alumnos ejecutan el código que escriben | Posible | Excepción educativa: el código se puede ver y editar por completo y no se usa para nada más |
Reproduce en la compilación de TestFlight la función que menciona la nota. Si la nota nombra un framework, búscalo en el proyecto de Xcode (Podfile, Package Dependencies). El código nativo que Cursor o Claude Code añadieron al proyecto de WebViewGold es el primer sospechoso; los SDKs que trae el proyecto (OneSignal, Firebase, AdMob, RevenueCat) se usan muchísimo y no son a lo que apunta la 2.5.2.
Borra cualquier SDK que descargue scripts para cambiar el comportamiento nativo, que evalúe código descargado con acceso a las API nativas o que intercambie funciones mediante configuración remota. Mantén la configuración remota para textos, contenido y pruebas A/B de funciones existentes.
Si tu producto genera o ejecuta código, ejecútalo en tu servidor y muestra el resultado: la salida, una imagen renderizada, un informe de pruebas, una exportación. Puedes abrir las vistas previas en vivo en Safari añadiendo el dominio de la vista previa a safariwhitelist (documentación de URL Handling). Al parecer, derivar al navegador no bastó por sí solo para al menos un creador de apps en 2026, así que tómalo como una reducción del riesgo, no como una garantía.
Los esquemas de URL de WebViewGold (push, escáneres, contactos, NFC, etc.) se activan con navegaciones dentro del WebView. Si en tu documento principal se ejecuta código generado por usuarios o por IA, puede activarlos igual que tu propio código. Muestra el HTML generado en un iframe con sandbox en un origen separado, elimina de la salida generada los enlaces con esquemas personalizados y comprueba en la compilación que el contenido generado no puede abrir ninguna función nativa.
Un párrafo: la app muestra tu app web en tu dominio dentro de WKWebView; no se descarga código nativo; el contenido generado son datos que muestra tu propio código; cualquier ejecución de código ocurre en tu servidor. La Directriz 2.3.1 ya pide notas específicas sobre las funciones nuevas, y la plantilla de notas de revisión te da una estructura.
Eliminar un SDK o una función nativa requiere una compilación nueva con un número de compilación más alto. Si solo cambió tu app web, despliega, compruébalo en la compilación de TestFlight y responde en el Centro de resolución.
Si tu app muestra HTML producido por un modelo o por un usuario (respuestas con formato, informes, gráficos), mantenlo fuera de tu página principal. Un atributo sandbox vacío bloquea scripts, formularios y navegación; un origen separado lo mantiene lejos de tu sesión.
<!-- Página principal de la app: nunca inyectes HTML generado con innerHTML o dangerouslySetInnerHTML -->
<iframe
src="https://render.yourapp-content.com/view?id=abc123"
sandbox=""
referrerpolicy="no-referrer"
style="width:100%;height:70vh;border:0"></iframe>
<!-- sandbox="" = sin scripts, sin formularios, sin navegación de nivel superior.
Añadir allow-scripts significa que ejecutas código generado: planifica antes las obligaciones de la 4.7 y la 2.5.2.
En el dominio de renderizado, elimina también de la salida los enlaces con esquemas personalizados (registerpush://, qrcode:// ...). -->No todos los resultados son un problema; muchos son inofensivos. Buscas los lugares donde el texto de un modelo, de un usuario o de un servidor remoto se convierte en script ejecutable.
# Lugares donde una app web ejecuta código con el que no se publicó
grep -rnE "eval\(|new Function\(|srcdoc|dangerouslySetInnerHTML|insertAdjacentHTML|document\.write\(" \
--include=*.{ts,tsx,js,jsx,html,vue,svelte} \
--exclude-dir={node_modules,dist,build,.next} .Explica primero la arquitectura y después los cambios. Los revisores responden bien a una descripción precisa. La plantilla se queda en inglés porque App Review lee en inglés.
Hello App Review team, Thank you for your feedback on [App name] [version] ([build]). We would like to explain how the app works and what we changed. How the app works: [App name] displays our web app at [https://yourdomain.com] in WKWebView (WebKit). The app does not download or execute native code, and its purpose is the one described in the submission: [one sentence about what the app does]. What we changed: - [We removed the SDK [name], which could modify app behavior at runtime.] - [Users can no longer create and run mini apps inside the app. Generated content is now returned as text and images that our own code displays; code runs only on our servers.] - [Previews of user projects now open in Safari instead of inside the app.] Where to verify: [screen or steps]. [New build: [number].] If any part of the app still raises a concern under Guideline 2.5.2, we would be grateful if you could point us to the specific screen so we can address it directly. Best regards, [Name], [email], [phone]
eval ni new Function sobre la salida del modelo.Sí, siempre que la app mantenga el propósito y las funciones con las que se revisó. Las correcciones de errores, el contenido nuevo y las pantallas nuevas dentro del mismo propósito son lo normal en las apps basadas en web. Un cambio de propósito, o funciones que necesitan permisos o compras nuevas, corresponde a una actualización en el App Store con notas de revisión.
No. Un chatbot envía texto y recibe texto o imágenes que muestra tu código; eso es contenido. Los chatbots se mencionan en la Directriz 4.7, y la Directriz 1.2 pide filtrar el contenido generado y permitir denunciarlo.
Descarga una copia sin conexión de tu propia app web que WebKit muestra cuando el dispositivo no tiene conexión. Es la misma app con el mismo propósito que el sitio en vivo, así que se aplica el mismo razonamiento que para la URL. No la uses para entregar funciones que la app revisada no tiene.
Existen apps que ayudan a crear apps, pero ejecutar las apps generadas dentro de tu propia app es justo donde fallaron las revisiones en 2026. Genera y ejecuta en tu servidor, entrega los resultados como archivos, exportaciones o vistas previas web, y cuenta con una revisión minuciosa. Consulta la redacción actual de la 2.5.2 y la 4.7 antes de planificar la función.
Sí, si descarga o carga código ejecutable, cambia el comportamiento de la app según instrucciones remotas o llama a API privadas. Limita los cambios nativos a Config.swift y a las opciones documentadas de WebViewGold, y deja que el agente de IA trabaje en la app web.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.