Saltar al contenido
WebViewGold Del vibe coding a la App Store
Español
Consigue WebViewGold

Cursor

Background agents de Cursor para preparar la app para las tiendas: tareas en paralelo, revisadas como pull requests

Los background agents de Cursor, que ahora se llaman Cloud Agents, se ejecutan en máquinas aisladas en la nube, trabajan en su propia rama y te devuelven un pull request. Eso encaja muy bien con la preparación para el App Store: divide el trabajo en tareas independientes, lánzalas en paralelo y revisa cada resultado como el PR de un compañero antes de que nada llegue a la compilación nativa.

Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.

  • Garantía de aprobación – o te devolvemos el dinero en 14 días
  • Sin programar
  • Pago único, actualizaciones gratuitas
  • Soporte humano 24/7
  • Hecho en Alemania desde 2014 · ISO 27001

Por qué preparar la app para las tiendas es un buen trabajo para agentes en paralelo

Una pasada de preparación para la tienda es un checklist de correcciones casi siempre independientes: páginas legales, eliminación de cuenta, diseño móvil, estados de error, ocultar elementos exclusivos de la web, notas para la revisión. En una sola sesión local larga, estos cambios se acumulan en un único diff difícil de revisar. Repartidas entre agentes en la nube, cada tarea toca sus propios archivos, llega como su propio pull request y se puede aceptar, devolver o repetir por separado.

El objetivo es el mismo que en el flujo completo con Cursor: una app web que se comporte como una app cuando WebViewGold la carga en un WebView nativo. Esta página trata solo la parte en paralelo y lo que sigue siendo cosa tuya. Todo lo demás sobre publicar proyectos de Cursor está reunido en la página principal de Cursor.

Qué son los Cloud Agents, en seis datos

Máquinas aisladas

Cada agente se ejecuta en su propia VM en la nube con un entorno de desarrollo completo. Clona tu repositorio, trabaja en una rama aparte y sube el resultado para que lo revises.

Muchas formas de lanzarlos

Elige Cloud bajo el campo del agente en Cursor, usa cursor.com/agents desde cualquier dispositivo, menciona a @cursor en Slack o Linear, o comenta @cursor en un issue o pull request de GitHub.

Primero, el control de versiones

Un administrador de la cuenta de Cursor conecta el control de versiones (GitHub, GitLab, Bitbucket Cloud o Azure DevOps), y el agente necesita acceso de lectura y escritura al repositorio.

Secretos en el panel

Añade las claves de API y las credenciales de prueba como secretos en el panel de Cursor en lugar de hacer commit de un archivo .env. Se inyectan cuando arranca un agente, así que los agentes que ya están en marcha no ven los nuevos.

Leen AGENTS.md

La documentación de los cloud agents de Cursor lo dice claramente, así que pon el contexto de la app nativa y las invariantes de las tiendas en AGENTS.md, no solo en .cursor/rules.

Coste según uso

Las ejecuciones se facturan a la tarifa del modelo elegido, y no todos los planes las incluyen. La primera vez fijas un límite de gasto; mantenlo en un valor razonable antes de lanzar seis a la vez.

Dale a cada agente un entorno de trabajo

Los agentes pueden preparar el entorno ellos mismos (y guardarlo como snapshot), o puedes hacer commit de .cursor/environment.json. Para una app web típica de Node basta con esto: instalar dependencias, ejecutar el servidor de desarrollo en un terminal que el agente pueda ver y exponer el puerto. Los nombres de los campos vienen del esquema publicado por Cursor; la descripción del terminal se le muestra al agente.

json
{
  "install": "npm ci",
  "terminals": [
    {
      "name": "web",
      "command": "npm run dev -- --port 3000",
      "description": "Dev server. Check changed routes here at 390 px and 320 px width."
    }
  ],
  "ports": [
    { "name": "web app", "port": 3000 }
  ]
}

Con una buena versión optimizada de su aplicación web, puedes tener una impresionante aplicación móvil en un par de minutos. ¡Además del servicio al cliente es muy agradable y muy útil! ¡Puedo recomendar WebViewgold :-)

Julian Koch · Cofundador de Dueldonkey · CodeCanyon

Añade a AGENTS.md una sección para los agentes en la nube

Haz commit de esto en la rama principal antes de lanzar nada. El primer bloque es el contexto compartido de la app nativa; el segundo le dice a cada agente cómo comportarse como uno de varios trabajadores.

markdown
## Native app (WebViewGold)
This web app also ships as iOS and Android apps. WebViewGold loads
https://app.example.com in a native WebView; every deploy is live in both apps.
- Detect the app only with isNativeApp() (user agent contains "MyAppNative").
- Native features are URL schemes from https://www.webviewgold.com/llms-full.txt.
  Never invent one; always keep a web fallback.
- Store invariants: real /privacy and /terms; in-app account deletion (server-side);
  Sign in with Apple next to any social login; no external checkout for digital
  goods in the iOS app; loading, empty and error states; layout works at 320 px.

## Cloud agents
- One task per agent. Touch only the files the task needs. If you must edit a
  shared layout file, say so at the top of the PR description.
- Run npm run lint, npm test and npm run build before you push.
- Check every route you changed in the browser at 390 px and 320 px and describe
  what you saw in the PR.
- PR description: what changed, how you verified it, open questions, and what
  needs a test on a real iPhone and Android phone.
- You cannot run the native app. Never claim you tested on iOS or Android.

Divide la pasada en tareas paralelas

AgenteTareaArchivos típicosTerminada cuando
1. Páginas legales/privacy y /terms reales basadas en lo que recopila el código, enlazadas desde el pie de página y los ajustesRutas, pie de página, pantalla de ajustesAmbas URL cargan directamente y nombran cada SDK que recopila datos
2. Eliminación de cuentaEliminar cuenta en los ajustes más una página pública /delete-account; el servidor borra datos, archivos y el usuario de autenticaciónAjustes, ruta de API, helpers de autenticaciónUn usuario de prueba desaparece de la base de datos y del proveedor de autenticación (requisitos de eliminación)
3. Estados y callejones sin salidaEstados de carga, vacío y error con reintento; una página 404; quitar los botones de "próximamente"Componentes de datos, routerLos clics sin conexión muestran un estado de error, nunca una pantalla en blanco
4. Modo appHelper isNativeApp(); ocultar dentro de la app las insignias de las tiendas, los avisos de instalación y las insignias del builderHelper de plataforma, bannersAl falsear el user agent se oculta todo elemento exclusivo de la web
5. Borradores para las tiendasdocs/store/: notas para la revisión, descripción, palabras clave y un inventario de datos para App Privacy y Data safetySolo documentaciónCada tipo de dato del inventario remite a código del repositorio
6. Diseño móvil (al final)Desbordamiento, áreas de toque, relleno de área segura, campos de 16 px, ningún control que solo funcione con hoverCSS, componentes de layoutSin scroll horizontal a 320 px en ninguna ruta principal

Una plantilla de prompt para los seis agentes

Mantén idéntica la parte común para que todos los pull requests tengan el mismo aspecto; solo cambia el bloque de la tarea. El ejemplo muestra el agente 2.

Pégalo en cada Cloud Agent, cambiando el bloque TAREA
Contexto: esta app web también se publica como apps nativas de iOS y Android mediante WebViewGold, que carga nuestra URL de producción en un WKWebView y un Android WebView. Lee primero AGENTS.md y sigue sus secciones "Native app" y "Cloud agents".

Reglas para esta ejecución:
- Trabaja solo en la tarea de abajo. No refactorices código no relacionado ni añadas dependencias salvo que la tarea las necesite.
- Ejecuta lint, tests y la compilación de producción antes de hacer push.
- Abre un pull request titulado "store-readiness: <nombre de la tarea>". En la descripción, enumera qué cambió, cómo lo verificaste (rutas y anchos), las preguntas abiertas y lo que debo probar en un iPhone y un teléfono Android reales.
- Si algo es ambiguo, por ejemplo qué tablas contienen datos de usuarios, detente y pregunta en el pull request en lugar de adivinar.

TAREA: Eliminación de cuenta
- Añade en los ajustes una acción "Eliminar cuenta" con un paso de confirmación.
- Al confirmar, llama a un endpoint del servidor que borre las filas del usuario en todas las tablas que lo referencian, borre los archivos almacenados del usuario y elimine el usuario de autenticación. Después cierra la sesión y muestra una pantalla de confirmación.
- Añade una página pública /delete-account que explique los pasos dentro de la app y ofrezca una forma de solicitar la eliminación sin la app (formulario o dirección de correo).
- Añade un test que cree un usuario, lo elimine y compruebe que no quedan filas ni archivos.

Ejecuta la pasada

Alrededor de una hora de preparación; después, sobre todo tiempo de revisión.

  1. Conecta el control de versiones y prepara el entorno

    Un administrador conecta el proveedor del repositorio en Cursor. Haz commit de environment.json, o deja que el primer agente prepare el entorno y lo guarde como snapshot para que los siguientes arranquen más rápido.

  2. Haz commit de AGENTS.md y .cursor/BUGBOT.md

    Los agentes leen AGENTS.md; Bugbot lee .cursor/BUGBOT.md (ejemplo más abajo). Ambos tienen que estar en la rama principal antes del primer lanzamiento.

  3. Añade secretos y una cuenta de prueba

    Guarda la URL de la base de datos de staging, las credenciales de prueba y las claves de API como secretos del panel. Sin un login de prueba, los agentes no pueden comprobar las pantallas con sesión iniciada y te dirán que "deberían funcionar".

  4. Lanza a la vez los agentes 1 a 5

    Lánzalos desde el campo del agente (Cloud), desde cursor.com/agents, o crea un issue de GitHub por tarea y comenta @cursor con el prompt. Lanza el agente 6 cuando se hayan fusionado los demás, porque el trabajo de layout toca los mismos componentes.

  5. Revisa cada pull request

    Lee el diff y la descripción, deja que Bugbot comente y abre el despliegue de vista previa en el navegador de tu teléfono. Para pedir cambios, comenta @cursor en el pull request con lo que hay que corregir.

  6. Fusiona, despliega y prueba en la app real

    Fusiona en un orden lógico, despliega producción y luego prueba la compilación de WebViewGold en dispositivos reales. Los agentes en la nube no pueden ejecutar la app nativa, así que este paso sigue siendo tuyo.

.cursor/BUGBOT.md: un checklist de revisión de las tiendas para cada pull request

Bugbot no usa tus archivos .cursor/rules; lee .cursor/BUGBOT.md (siempre el de la raíz, y los anidados cerca de los archivos modificados). Se ejecuta con cada actualización de un pull request, y comentar cursor review o bugbot run lo lanza a mano.

markdown
# Store review rules
This app ships as iOS and Android apps via WebViewGold (native WebView around our URL).

Flag as a bug:
- New fixed or sticky UI without env(safe-area-inset-*) padding.
- Tap targets smaller than 44 x 44 px, or hover-only interactions.
- OAuth opened via window.open, target="_blank" or a popup.
- A native URL scheme (registerpush://, shareapp://, bioauth:// ...) called without
  an isNativeApp() check or without a web fallback.
- Purchase or upgrade buttons for digital goods that link to an external checkout
  inside the native app.
- Removing or breaking /privacy, /terms, /delete-account or the Delete account action.
- Data fetching without loading, empty and error states.
- Secrets or service-role keys in client-side code.

Ignore: styling preferences, naming, and refactors that do not change behavior.

Qué revisar en cada pull request

  • El diff solo toca archivos que corresponden a la tarea; los cambios no relacionados son motivo para devolverlo.
  • Se ejecutaron lint, tests y la compilación, y la descripción lo indica.
  • Las pantallas con sesión iniciada se comprobaron de verdad: la descripción nombra la cuenta de prueba, no dice "debería funcionar".
  • No se ha colado ningún SDK o tracker nuevo que tendrías que declarar en App Privacy y Data safety.
  • Los textos son reales: nada de Lorem ipsum ni de "Your Company Inc." en la política de privacidad.
  • Todo lo nativo (push, compartir, biometría) está detrás de isNativeApp() con una alternativa web.

Errores típicos

  • Varios agentes con los mismos archivos: los conflictos de fusión se comen el tiempo que ahorraste. Divide por zona de archivos, no por idea.
  • Agentes que dicen "probado en iOS". Se ejecutan en VMs en la nube sin tu app nativa; las pruebas en dispositivos reales siguen siendo cosa tuya.
  • Una URL de despliegue de vista previa copiada en la configuración de WebViewGold. En Config.swift y Config.java solo va el dominio de producción.
  • Secretos en un commit porque un agente los "necesitaba". Usa los secretos del panel y rota todo lo que haya llegado al repositorio.
  • Seis agentes con un modelo grande suman mucho. Empieza con dos o tres, comprueba la calidad de los pull requests y luego amplía.
  • AGENTS.md y .cursor/rules que se contradicen. Los agentes siguen el que leen; mantén idénticas las invariantes (cómo mantener una sola fuente).

Preguntas frecuentes

¿Background agents y Cloud Agents son lo mismo?

Sí. Cursor cambió el nombre de Background Agents a Cloud Agents. Los tutoriales antiguos siguen usando el nombre anterior; la idea es la misma: un agente en una VM aislada en la nube que trabaja en su propia rama y te devuelve el resultado.

¿Los Cloud Agents siguen mis .cursor/rules?

La documentación de los cloud agents de Cursor dice explícitamente que leen AGENTS.md, así que ese es el lugar seguro para todo lo que cada agente debe cumplir. Mantén tus reglas de proyecto para el trabajo local, con las mismas invariantes.

¿Puede un Cloud Agent compilar la app de iOS?

No. Compilar y firmar una app de iOS requiere Xcode en macOS, y los agentes trabajan en entornos de desarrollo en la nube. Compila con Xcode en un Mac o con el Cloud Builder de WebViewGold, que compila y sube ambas apps desde el navegador.

¿Puedo lanzar un agente desde un issue de GitHub?

Sí. Una vez conectado el control de versiones, comenta @cursor en un issue o un pull request con tus instrucciones. Un issue por tarea de preparación te deja además un registro ordenado de lo que se hizo.

¿Un agente fusionará en main por su cuenta?

Los agentes en la nube trabajan en una rama aparte y la suben para que la revises. Protege de todos modos tu rama principal, para que nada llegue a producción sin una revisión humana.

¿Cuántos agentes debo ejecutar a la vez?

Tantos como tareas independientes tengas. Para esta pasada encajan seis, pero empieza con dos o tres hasta que confíes en el resultado, y deja el trabajo de layout para el final.

Tres formas de llevar tu app a las tiendas

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.

Hazlo tú mismo

$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

Full Service

$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 WeSetupYourWebViewApp

Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.

¿Listo para lanzar tu app?

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.