ChatGPT & Codex
Con una app de WebViewGold, cada merge a main es una publicación: la app nativa carga tu URL de producción, así que un despliegue defectuoso llega a los usuarios del App Store y de Google Play en cuestión de minutos. Codex puede revisar cada pull request en GitHub antes de que se integre. Enséñale tus reglas de las tiendas en AGENTS.md y señalará los problemas que provocan rechazos y filtraciones, no solo los bugs.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
En una app totalmente nativa, el código llega a los usuarios solo después de compilar, enviar y superar la revisión. Una app de WebViewGold carga tu URL de producción, así que un merge a main está activo en la versión de la tienda en cuanto se despliega. Esa es la gran ventaja del enfoque (no hay que volver a enviar la app por cambios web, consulta actualizaciones web frente a nativas) y también la razón por la que un pull request descuidado puede romper la app en todos los móviles, o poner un Stripe Checkout para créditos delante de los usuarios de iOS entre dos revisiones. Apple y Google vuelven a mirar con cada actualización nativa que envías, y una regla incumplida entretanto sale a la luz en ese momento.
La revisión de código de Codex cierra ese hueco. Una vez conectado el repositorio a Codex, revisa los pull requests en GitHub automáticamente o cuando alguien comenta @codex review, y publica una revisión normal de GitHub con hallazgos en líneas concretas. Hay dos detalles que condicionan la configuración: en GitHub solo informa de los hallazgos de alta prioridad (P0 y P1), y lee las reglas de revisión de una sección ## Code Review Rules en tus archivos AGENTS.md, aplicando el archivo raíz más el archivo anidado más específico para cada ruta modificada. Así que las reglas de las tiendas tienen que estar escritas, y tienen que estar marcadas como P1.
En Codex, conecta GitHub y da acceso al repositorio al conector de Codex. Las revisiones en GitHub no necesitan un entorno en la nube; Codex lee el propio pull request.
Abre los ajustes de revisión de código en Codex, elige el repositorio y activa la revisión automática. Para configurarla necesitas permisos de push o de administrador en el repositorio de GitHub. Sin revisiones automáticas, un comentario con @codex review en un pull request solicita una.
Añade la sección ## Code Review Rules de abajo al AGENTS.md raíz (o al AGENTS.md de nuestra plantilla). Empieza con poco: OpenAI recomienda unas pocas reglas concisas y dejar el formato y el lint a la CI. Los AGENTS.md anidados pueden añadir reglas por carpeta, por ejemplo reglas más estrictas para tus funciones de servidor.
Exige pull requests y checks en verde para la rama main en los ajustes del repositorio de GitHub. Codex comenta, pero no bloquea los merges. Eso lo hace la protección de ramas.
Abre un pull request desechable que incumpla una regla a propósito, por ejemplo un enlace de pago de Stripe que se muestra cuando isNativeApp() es true. Si Codex no lo señala, haz la regla más concreta y vuelve a probar; después cierra el pull request sin hacer merge.
Pégalo en AGENTS.md y ajusta los nombres a tu código. La línea "Treat as P1" es importante: las revisiones de GitHub solo muestran hallazgos P0 y P1, así que sin ella una regla de las tiendas podría considerarse menor y no aparecer nunca. Puedes dejar las reglas en inglés: Codex las entiende igual de bien.
## Code Review Rules
These rules protect the App Store and Google Play releases of our WebViewGold
apps, which load this web app in a native WebView. Treat every violation below
as P1.
### Secrets
- No API keys, service-role keys, private keys or tokens in client code, in
public env variables (NEXT_PUBLIC_*, VITE_*) or in committed .env files.
- Server-only keys (database service role, OpenAI, Stripe secret) are read in
server code only.
### Store rules
- Digital goods, subscriptions and credits: when isNativeApp() is true, buy
buttons use the in-app purchase path (revenuecat://purchase?...). No Stripe
checkout, card form or external payment link for digital goods in the app.
- Account deletion (settings screen and /delete-account) keeps working and
deletes server-side.
- A new Google, Facebook or other third-party login requires Sign in with
Apple with equal prominence.
- /privacy and /terms stay reachable from settings and the footer.
- No placeholder text, lorem ipsum, "coming soon" screens or dead links in
routes reachable from the app.
- No "Download our app" banners or App Store / Google Play links when
isNativeApp() is true.
### Mobile layout inside the WebView
- Fixed headers, footers and bottom sheets pad with env(safe-area-inset-*).
- Tap targets 44x44px or larger; inputs use font-size 16px or more.
- No hover-only controls; no horizontal scrolling at 320px width.
- Login and payment flows do not depend on window.open popups.
### WebViewGold bridge
- Bridge calls run only behind isNativeApp() and keep a web fallback.
- Only URL schemes documented in https://www.webviewgold.com/llms-full.txt.
Flag any scheme that is not in that file.
¡Estoy muy feliz de haber comprado esta aplicación! Documentación extremadamente fácil y excelente. Estaba en contacto con el servicio al cliente, respondieron muy rápido y de forma muy amigable. Resolvieron mi pregunta en un día. 10/10 lo recomendaría".
| Regla | Por qué importa | Un hallazgo P1 típico |
|---|---|---|
| Ningún secreto en el código del cliente | Todo lo que va en el bundle lo puede leer cualquiera que abra la app o la web; una service-role key de la base de datos o una clave de OpenAI supone una filtración de datos o una factura enorme | VITE_OPENAI_API_KEY usada directamente en un componente de React |
| Bienes digitales mediante compras dentro de la app | La Directriz 3.1.1 de Apple y la política de pagos de Google Play (con excepciones regionales); el rechazo más habitual en apps de IA y SaaS, consulta la Directriz 3.1.1 | Un botón de paquete de créditos abre Stripe Checkout sin una rama isNativeApp() |
| La eliminación de cuentas sigue funcionando | La 5.1.1(v) de Apple y Google Play exigen la eliminación dentro de la app en las apps con registro | Un refactor eliminó la llamada a la función de borrado del servidor |
| Paridad con Sign in with Apple | La 4.8 de Apple se aplica cuando existe un inicio de sesión de terceros | Un nuevo botón "Continuar con Google" sin opción de Apple |
| Área segura, áreas táctiles de 44 px, campos de 16 px | Rechazos de diseño por la 4.0 de Apple; iOS hace zoom en los campos de menos de 16 px, consulta área segura y áreas táctiles | Una nueva navegación inferior con position: fixed; bottom: 0 y sin inset |
| Ningún resto de la web en la app | Los revisores interpretan los banners de descarga y los enlaces a las tiendas como "esto es una web" (Directrices 4.2 y 2.3) | Un banner "Descarga la app" que se muestra con cualquier user agent |
| Solo esquemas del puente documentados | Un esquema inventado falla en silencio dentro de la app | window.location.href = "share://..." en lugar de shareapp:// |
Las revisiones automáticas ya aplican tus reglas. Antes de un envío a las tiendas, pide una pasada centrada en el pull request de la versión; el texto después de @codex review acota esa revisión concreta sin cambiar AGENTS.md.
@codex review centrado en los bloqueos para publicar en el App Store y en Google Play. Aplica las Code Review Rules de AGENTS.md y céntrate en: secretos o claves exclusivas del servidor accesibles desde el código del cliente; bienes digitales, suscripciones o créditos vendidos sin pasar por las compras dentro de la app cuando isNativeApp() es true; cualquier cambio que debilite la eliminación de cuentas, las páginas de privacidad y términos o la paridad con Sign in with Apple; cabeceras, pies o paneles fijos sin insets de área segura, áreas táctiles de menos de 44px y campos de menos de 16px; banners de descarga o enlaces a las tiendas visibles dentro de la app; esquemas de URL del puente que no estén documentados en https://www.webviewgold.com/llms-full.txt.
La revisión de un pull request ve un solo cambio. Antes de enviar una nueva build nativa, revisa todo el tramo desde el último envío: etiqueta cada estado enviado y después abre un pull request solo para revisión desde main contra una rama creada a partir de esa etiqueta. Comenta la solicitud de arriba, resuelve los hallazgos y cierra el pull request sin hacer merge.
# when you submit a build to the stores, tag the state of main
git tag store-1.2.0
git push origin store-1.2.0
# before the next submission: a base branch at the old state
git branch review/store-1.2.0 store-1.2.0
git push origin review/store-1.2.0
# review-only pull request: base = the old state, head = main
gh pr create --base review/store-1.2.0 --head main \
--title "Release review: changes since store 1.2.0" \
--body "Review only. Do not merge."En la Codex CLI, /review inicia un revisor aparte que lee un diff (contra una rama base, contra los cambios sin confirmar o contra un commit) e informa de hallazgos priorizados sin cambiar tus archivos. Elige las instrucciones de revisión personalizadas y pega esto:
Revisa los cambios respecto a main como control de publicación para nuestras apps WebViewGold de iOS y Android, que cargan esta app web en un WebView nativo. Informa de cada incumplimiento de las Code Review Rules de AGENTS.md con el archivo, la línea, la regla, por qué bloquearía una publicación en el App Store o en Google Play y el arreglo más pequeño. Después enumera lo que necesita una comprobación en un móvil real (el layout bajo el notch y el indicador de inicio, el teclado tapando los campos, los flujos de inicio de sesión y de compra). No informes de problemas de formato ni de nombres.
@codex fix the P1 finding (cualquier mención que no sea review) inicia una tarea en la nube que puede hacer push a la rama, así que revisa también ese commit.La revisión de código es una función de Codex, y Codex viene con los planes de pago de ChatGPT, que tienen límites de uso según el plan. Consulta las condiciones actuales de tu plan antes de activar las revisiones automáticas en un repositorio con mucha actividad.
En GitHub no: allí solo informa de hallazgos P0 y P1. Por eso mismo las reglas de las tiendas necesitan un "treat as P1" explícito. Deja el formato en manos de tu linter y de la CI.
Sí. Comenta @codex con una petición que no sea review, por ejemplo "@codex arregla el hallazgo P1 sobre el botón de Stripe". Eso inicia una tarea con el pull request como contexto, que puede hacer push de un arreglo a la rama si tiene permiso. Revisa ese commit como cualquier otro.
Sí, en cuanto des acceso al repositorio al conector de GitHub de Codex. Para configurar las revisiones automáticas necesitas permisos de push o de administrador en él.
La documentación actual de OpenAI llama a la sección ## Code Review Rules. Cambia el encabezado para que coincida, deja las reglas debajo y prueba con un pull request que incumpla una regla a propósito.
Puede estarlo, y entonces las revisiones también ven los cambios en Config.swift y Config.java. Muchos equipos lo mantienen aparte porque los cambios nativos son poco frecuentes. En cualquier caso, no hagas nunca commit de certificados, perfiles de aprovisionamiento ni keystores.
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.