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

Claude Code + diseño

Una auditoría de UI móvil con Claude Code: áreas seguras, áreas de toque y los detalles que notan los revisores

Los revisores juzgan una app web envuelta en segundos: contenido debajo del notch, botones demasiado pequeños para acertarlos, una página que hace zoom al tocar un campo. Nada de esto es difícil de arreglar, y Claude Code lo encuentra bien en cuanto tiene una checklist y una forma de ver la pantalla. Esta guía configura un subagente de auditoría, un ciclo de capturas, el CSS al que deberían converger las correcciones y los ajustes de WebViewGold correspondientes.

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

Lo que ven los revisores en el primer minuto

La directriz 4.0 pide apps pulidas y fáciles de usar, y las apps basadas en web reciben un escrutinio extra por la 4.2 si parecen un sitio web. Los problemas que provocan esos comentarios son previsibles: una cabecera que se mete bajo la barra de estado o la Dynamic Island, una barra de pestañas encima del indicador de inicio, botones de icono más pequeños que los 44 x 44 puntos que recomienda Apple (Material Design de Android recomienda 48 x 48 dp), scroll horizontal en un iPhone pequeño, campos que hacen zoom al recibir el foco porque su fuente es menor de 16 px, un diseño a altura completa que da saltos por culpa de 100vh y menús que solo se abren con hover. Los revisores también ejecutan apps de iPhone en iPad, así que un diseño que se rompe con ancho de tablet también salta a la vista.

Cada problema vive en uno de dos sitios: tu CSS o los ajustes de WebViewGold alrededor del WebView. La guía de la directriz 4.0 explica el rechazo en sí; esta página trata de encontrar y corregir las causas con Claude Code antes de que lo haga un revisor.

Qué hace Claude Code y qué haces tú

Claude Code

Revisa cada página y cada componente con una checklist fija, hace capturas con anchos de teléfono y de tablet, corrige CSS y marcado en commits pequeños y te deja un slash command reutilizable.

Tú

Evalúas los hallazgos (algunos son falsos positivos), decides los compromisos de diseño y configuras la barra de estado, la barra inferior y las opciones de zoom en los proyectos de WebViewGold.

Un teléfono real

Demuestra lo que ninguna captura puede: el notch, el indicador de inicio, el teclado y el comportamiento del zoom dentro del WebView real.

Ajustes nativos frente a tu CSS

ProblemaAjuste de WebViewGoldEn tu app web
Zona de la barra de estadoiOS: statusBarBackgroundColor, statusBarTextColor y sus variantes para modo oscuro, o transparentStatusBar con autoAdjustSafeAreaInsets en false. Android: TRANSPARENT_STATUS_BAR, blackStatusBarTextSolo si el contenido se dibuja detrás de la barra: viewport-fit=cover y env(safe-area-inset-top)
Indicador de inicioiOS: bottombar, iPadBottombar, bottombarBackgroundColor (documentación del área segura)env(safe-area-inset-bottom) en las barras inferiores fijas
ZoomiOS: preventZoom. Android: ENABLE_ZOOM, MAX_TEXT_ZOOM para limitar el escalado de texto del sistemaFuente de 16 px en los campos, sin anchos fijos
Rebote y vistas previas de enlacesiOS: preventoverscroll (déjalo en false si usas pulltorefresh), disablecalloutNada
Teclado que tapa los camposAndroid: INPUT_SCROLL_HELPEREvita pies de página fijos sobre formularios; desplaza los campos con foco hasta que se vean
OrientacióniOS: orientationiphone, orientationipad. Android: PHONE_ORIENTATION, TABLET_ORIENTATIONPrueba cada orientación que permitas

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

El subagente de auditoría

Los subagentes son archivos Markdown con un frontmatter breve en .claude/agents/; también puedes crear uno de forma interactiva con /agents. Este solo lee e informa, así que nunca compite con tu sesión principal por las ediciones.

markdown
---
name: mobile-ui-auditor
description: Audits pages and components for problems in the native iOS and Android WebView apps (safe areas, tap targets, overflow, input zoom, viewport units). Use after UI changes and before every store submission.
tools: Read, Grep, Glob, Bash
---
You audit a web app that also ships as iOS and Android apps built with WebViewGold
(WKWebView / Android WebView). You report problems; you do not edit files.

Check every page and shared component for:
1. Safe areas: the viewport meta includes viewport-fit=cover if content draws behind
   the status bar; fixed or sticky top bars use env(safe-area-inset-top); bottom bars,
   tab bars, floating buttons and toasts use env(safe-area-inset-bottom).
2. Tap targets: interactive elements at least 44 x 44 CSS px (icon buttons, close
   buttons, checkboxes, links in dense lists) with at least 8 px between them.
3. Overflow: nothing wider than the viewport at 320 px; long words, tables, code
   blocks and images are constrained.
4. Inputs: font-size of at least 16 px on input, select and textarea; correct type,
   inputmode and autocomplete attributes on login and checkout forms.
5. Viewport units: 100vh on full-height layouts (use 100dvh with a 100vh fallback).
6. Hover-only UI: menus, tooltips or actions that need :hover to be reachable.
7. Desktop leftovers: sidebars without a mobile variant, Download our app banners,
   builder badges, cookie walls shown inside the app.
8. Dark mode: contrast of text and backgrounds if the app supports dark mode.

Output a table: file, line, issue, check number, suggested fix. Group by severity:
blocks review, looks broken, polish. End with the three fixes that matter most.

El ciclo de auditoría

Una tarde para una app típica; después, un slash command hace que repetirlo cueste poco.

  1. Dale ojos a Claude Code

    Añade el servidor MCP de Playwright con claude mcp add playwright npx @playwright/mcp@latest y compruébalo con /mcp. Así el agente puede abrir tu URL de preview, cambiar el tamaño del viewport y hacer capturas. Es un motor de navegador de escritorio, no el WebView de un teléfono, y no simula el notch, así que encuentra problemas de desbordamiento y de tamaño, pero no de áreas seguras.

  2. Guarda el subagente

    Pon el archivo de arriba en .claude/agents/mobile-ui-auditor.md y haz commit, para que todos los que usen Claude Code en el repositorio obtengan la misma auditoría.

  3. Ejecuta la auditoría y la pasada de capturas

    Usa el prompt de abajo. Lee el informe antes de que empiece cualquier corrección; detectarás los falsos positivos (un botón de 40 px dentro de un área de toque más grande está bien) más rápido que el agente.

  4. Corrige en commits pequeños

    Un commit por grupo de gravedad. Cuando el patrón esté claro, cambia al modo accept-edits con Shift+Tab y revisa el diff al final.

  5. Comprueba en dispositivos reales

    Compila para TestFlight y pruebas internas y recorre la checklist de abajo. Si no tienes Mac, el Cloud Builder genera ambas compilaciones de prueba desde el navegador.

El prompt de auditoría y corrección

Sustituye la lista de rutas por tus pantallas reales, incluidas las que están detrás del login. El último paso te deja un slash command para cada cambio futuro.

Pégalo en Claude Code
Usa el subagente mobile-ui-auditor para auditar src/app y src/components.

Después usa el servidor MCP de Playwright para abrir https://preview.example.com y hacer capturas de página completa de /, /login, /dashboard, /settings y el paywall con anchos de 320, 375, 390, 430, 768 y 1024 px (inicia sesión con nuestra cuenta de prueba; pídeme la contraseña cuando la necesites). Compara las capturas con el informe de la auditoría y añade todo lo que solo se ve en pantalla: elementos superpuestos, texto cortado, scroll horizontal, botones demasiado juntos.

Muéstrame el informe combinado y espera mi visto bueno. Después corrige en este orden: blocks review, looks broken, polish, un commit por grupo. Reglas para las correcciones:
- Áreas seguras con env(safe-area-inset-top) y env(safe-area-inset-bottom) mediante variables CSS en globals.css; viewport-fit=cover en el meta viewport.
- Áreas de toque de al menos 44 x 44 px; amplía la zona de toque con padding en lugar de agrandar los iconos.
- Inputs, selects y textareas con fuente de 16 px.
- min-height 100dvh con 100vh como alternativa para las pantallas a altura completa.
- Efectos hover solo dentro de @media (hover: hover).
- No desactives el zoom de forma global y no toques la configuración de WebViewGold.

Por último, crea .claude/commands/mobile-check.md: un slash command que ejecute el subagente mobile-ui-auditor solo sobre los archivos modificados en el git diff actual y muestre el informe.

El CSS al que deberían converger las correcciones

Elige un único responsable del área segura. O bien WebViewGold mantiene el contenido fuera de las zonas de la barra de estado y del indicador de inicio (el comportamiento predeterminado más bottombar), o bien lo hace tu CSS, con transparentStatusBar activado y autoAdjustSafeAreaInsets desactivado. Mezclar ambos produce huecos dobles en algunos dispositivos y ninguno en otros.

css
/* app/globals.css
   Meta viewport: <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
   Sin viewport-fit=cover, env(safe-area-inset-*) siempre vale 0. */
:root {
  --safe-top: env(safe-area-inset-top, 0px);
  --safe-bottom: env(safe-area-inset-bottom, 0px);
  --tabbar-height: 64px;
}

.app-header { position: sticky; top: 0; padding-top: var(--safe-top); }

.tab-bar {
  position: fixed; left: 0; right: 0; bottom: 0;
  height: calc(var(--tabbar-height) + var(--safe-bottom));
  padding-bottom: var(--safe-bottom);
}
main { padding-bottom: calc(var(--tabbar-height) + var(--safe-bottom) + 16px); }

.screen { min-height: 100vh; min-height: 100dvh; }

input, select, textarea { font-size: 16px; }

.icon-button { min-width: 44px; min-height: 44px; display: inline-grid; place-items: center; }

@media (hover: hover) {
  .card:hover { box-shadow: 0 4px 16px rgb(0 0 0 / 0.12); }
}

Checklist de verificación en dispositivos reales

  • iPhone con Dynamic Island: el texto y los botones de la cabecera quedan por debajo de la isla en todas las pantallas; la barra de pestañas queda por encima del indicador de inicio, en vertical y en cualquier modo horizontal que permitas.
  • iPhone pequeño (tamaño SE): ningún scroll horizontal en ninguna parte, incluidas las tablas y las direcciones de correo largas.
  • iPad: el diseño aprovecha el ancho con sentido, y la rotación no lo rompe si orientationipad permite rotar. Consulta compatibilidad con iPad.
  • Toca cada botón de icono con el pulgar, no con la yema del dedo: ningún fallo, ningún toque accidental en el vecino.
  • Pon el foco en cada campo: ningún zoom en iOS; el teclado no tapa el botón de envío en Android.
  • Android con el tamaño de fuente del sistema más grande: el diseño aguanta, o lo limitas con MAX_TEXT_ZOOM.
  • Con el modo oscuro activado: el texto de la barra de estado se lee bien (darkModeStatusBarTextColor en iOS).
  • Mantén pulsado un enlace: ninguna vista previa al estilo del navegador si disablecallout está activado.

Errores frecuentes

  • Falta viewport-fit=cover. Tu padding con env() vale 0 sin avisar y la auditoría sale en verde.
  • Fiarse de las capturas para las áreas seguras. Los motores de navegador de escritorio no emulan el notch ni el indicador de inicio. Solo un dispositivo lo demuestra.
  • Quitar el zoom en lugar de arreglar las fuentes. El zoom es una función de accesibilidad. Corrige primero el tamaño de 16 px en los campos; usa preventZoom o ENABLE_ZOOM solo si tu app de verdad lo necesita.
  • Estados hover que se quedan pegados. En pantallas táctiles, los estilos :hover siguen aplicados después de un toque. Envuélvelos en una media query de hover.
  • Arreglar la web y olvidarse del envoltorio. Una barra de estado blanca sobre una app oscura es un ajuste de color de WebViewGold, no un bug de CSS. Revisa la tabla de arriba antes de pedírselo al agente.

Preguntas frecuentes

¿Los 44 px son una regla estricta del App Store?

Es la recomendación de las Human Interface Guidelines de Apple, no una directriz de revisión numerada. Aun así, los revisores rechazan las apps difíciles de usar, y unas áreas de toque diminutas son la forma más rápida de llegar ahí.

¿Necesito un subagente o basta con un prompt?

Un prompt funciona una vez. El subagente mantiene la checklist en el repositorio, se ejecuta en su propio contexto para no saturar tu sesión principal, y el slash command lo convierte en un hábito después de cada cambio de interfaz.

¿Por qué no dejar que el agente lo corrija todo de una pasada?

Porque algunos hallazgos son falsos positivos y algunas correcciones chocan con tu diseño. Revisar antes el informe lleva minutos y te ahorra revertir un diff enorme.

¿Funciona env(safe-area-inset-*) en Android?

La compatibilidad dentro de un Android WebView depende de la versión del sistema y de cómo dibuje la app detrás de las barras del sistema. Pruébalo en un dispositivo y mantén un padding alternativo para la app si activas TRANSPARENT_STATUS_BAR.

¿Debo ocultar dentro de la app partes del sitio web como el pie de página?

Normalmente sí. Detecta la app mediante el token WebViewGoldApp del user agent y oculta la navegación de marketing, los muros de cookies y los banners de descarga de la app; la guía de CSS y JS personalizados muestra las opciones.

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.