QA cross-browser para UIs generadas por IA: script de prueba Safari/iOS

Por qué Safari y iOS fallan cuando todo parecía bien en Chrome

Si tu UI generada por IA se ve perfecta en Chrome, aún puede no estar lista. Safari en macOS y, sobre todo, Safari en iPhone pueden comportarse de manera diferente en formas pequeñas pero dolorosas.

Las pruebas en Chrome a menudo pasan por alto rarezas específicas de Safari como la altura del viewport que cambia cuando la barra de direcciones aparece o desaparece, estilos por defecto distintos para controles de formulario y reglas más estrictas sobre almacenamiento y cookies. En iOS, todos los navegadores usan el mismo motor WebKit, así que esto no es solo un problema de Safari. Es un problema de iPhone.

Las UIs generadas por IA también tienden a fallar en los bordes. Pueden verse bien en una demo del camino feliz y luego romperse cuando se abre el teclado, entra el autocompletado o aparece un modal sobre una página con scroll. Las pantallas de autenticación son un punto débil común: un pequeño desplazamiento de diseño puede ocultar el botón de enviar y un problema sutil de cookies o almacenamiento puede convertir “logueado” en “deslogueado” tras un refresco.

Un guion de pruebas corto y repetible te ayuda a detectar los problemas que importan antes de invertir tiempo en pulir. Un buen pase de Safari/iOS debería confirmar:

• El diseño sigue siendo usable cuando el viewport cambia (rotación, barra de direcciones, teclado).
• Los taps, el scroll y el foco se comportan con normalidad (sin scroll atascado, sin botones inactivos).
• Los formularios funcionan con el teclado iOS, el autofill y los gestores de contraseñas.
• La autenticación y el estado sobreviven a refrescos, backgrounding y volver a la app.

Si vas a compartir un enlace de demo o incorporar usuarios reales, 15 minutos en un iPhone pueden ahorrar días de confusión.

Un ejemplo simple: una página de registro que “funciona” en escritorio puede fallar en iPhone porque el teclado cubre el botón de enviar y la página no permite desplazarse. Solo lo notas cuando el primer usuario real se queda atascado.

Antes de probar: elige los flujos y dispositivos que importan

Las pruebas en Safari y iOS se vuelven ruidosas rápido. Mantenlo útil decidiendo de antemano qué debe funcionar para usuarios reales. Para QA cross-browser de UIs generadas por IA, eso suele ser un pequeño conjunto de flujos de extremo a extremo probados en un pequeño conjunto de dispositivos reales.

Elige 2–3 flujos clave que hagan o deshagan el producto. Manténlos simples y completos: ¿puede alguien crear una cuenta, volver a entrar y completar la acción principal (comprar, reservar, enviar o guardar)? Si solo pruebas pantallas aisladas, te perderás fallos de Safari que ocurren durante la navegación, redirecciones y cambios de estado.

Escoge dispositivos que coincidan con cómo la gente usa realmente tu app. Prueba al menos un iPhone con muesca (ahí aparecen problemas de safe area y viewport). Añade también un Mac con Safari: Safari de escritorio tiene sus propias peculiaridades con layout, almacenamiento y inputs de archivos.

Anota reglas de pase/fallo antes de empezar. Si no, cada hallazgo se convierte en una discusión. Trata cualquier cosa que bloquee el flujo o ponga en riesgo datos/seguridad como bloqueante (no se puede enviar, no se puede iniciar sesión, precio incorrecto, secreto expuesto). Trata las cuestiones cosméticas como menores (ajuste de línea extraño, pequeña desalineación).

Mantén una nota de preparación corta para cada ejecución:

• Versión de build y entorno (prod, staging, preview)
• Dispositivos y versiones de OS usadas
• Cuentas de prueba y datos de ejemplo que reutilizarás
• Limitaciones conocidas (feature flags, rollout parcial, endpoints rotos)
• Un lugar para diferenciar bloqueadores vs problemas menores

El guion de prueba de 15 minutos para Safari/iOS (paso a paso)

Este guion es para QA cross-browser de UIs generadas por IA, donde un layout que parece perfecto en Chrome aún puede fallar en iPhone Safari. Ponte un temporizador de 15 minutos y céntrate en un flujo central (registro, checkout, crear proyecto).

El guion

Comienza con una sesión completamente fresca. En iOS, cierra la pestaña, vuelve a abrir Safari y carga la app de nuevo para no depender de un estado cacheado por suerte.

• Ejecuta el camino feliz una vez, despacio, como un usuario nuevo. Observa pantallas en blanco, botones que no hacen nada y texto solapado.
• Repite el mismo flujo con conexión lenta (o en una zona de Wi‑Fi débil). Busca spinners que no paran, skeletons mal dimensionados y envíos dobles.
• Rota de vertical a horizontal en la pantalla con más UI. Comprueba que encabezados, botones fijos y barras inferiores sigan visibles y no salten.
• Provoca una interrupción: bloquea la pantalla o cambia de app, luego vuelve. Confirma que mantienes el lugar y que no te han cerrado la sesión ni se ha reseteado el estado.
• Captura evidencia: una grabación corta de pantalla y el modelo exacto del dispositivo y la versión de iOS.

Cómo se ve un “fallo” en iOS

Los fallos comunes son predecibles una vez que los has visto: un formulario funciona hasta que se abre el teclado, entonces el botón de enviar se desliza bajo el teclado o la página deja de desplazarse. O un modal se cierra, pero la página de detrás queda congelada.

Cuando los problemas parecen “aleatorios”, suele ser un código de layout frágil o manejo de estado frágil, algo común en prototipos generados por IA.

Dimensionado del viewport y safe areas: las trampas habituales de Safari

Safari en iOS difiere de Chrome de escritorio en dos cosas grandes: la chrome del navegador (barra de direcciones y toolbars) cambia de altura al desplazarte, y la pantalla tiene zonas inseguras (muesca e indicador de inicio). Las UIs generadas por IA suelen fijar tamaños que se ven bien en un viewport estable de escritorio y luego se desmoronan en un iPhone real.

Haz este pase rápido en un iPhone con muesca y rota una vez a landscape.

Comienza con cualquier elemento fijado arriba o abajo. Si un header, barra de pestañas, toast o botón inferior queda cubierto por la muesca, el indicador de inicio o la barra de Safari, se están ignorando las safe areas.

Luego busca el clásico problema de 100vh: secciones dimensionadas a altura completa quedan demasiado altas, por lo que el contenido inferior queda oculto detrás de la barra de direcciones o un footer fijo. La pista es un botón principal “desaparecido” que solo aparece después de desplazar un poco.

Usa un modal o drawer como prueba de estrés. Ábrelo, desplázalo dentro y luego intenta desplazar la página de fondo. Si el fondo hace rubber‑banding, el bloqueo de scroll no funciona en iOS.

Checklist:

• Comprueba padding superior e inferior alrededor de la muesca y el indicador de inicio en páginas a pantalla completa.
• Desplázate arriba y abajo y observa si el contenido salta cuando la barra de direcciones se colapsa.
• Abre un modal y luego intenta desplazar la página de fondo.
• Desplázate por una página larga y observa jitter en headers/footers sticky.
• Cambia el tamaño del texto (ajuste iOS o zoom de página) y vuelve a comprobar texto recortado.

Controles de formulario: qué probar con el teclado iOS y el autofill

En iOS los formularios son donde “se ve bien en Chrome” se convierte en dolor real para el usuario. Trata cada campo como una interacción, no solo como un cuadro en la página.

Flujo de prueba rápido (5 minutos por formulario)

Usa datos reales, no solo texto de placeholder. Si puedes, prueba una vez con una sesión nueva de Safari y otra con contraseñas y direcciones guardadas habilitadas.

• Toca cada tipo de campo que uses (email, password, number, search, textarea). Confirma que el teclado coincide con el campo y que escribir no está bloqueado.
• Revisa el comportamiento del foco: el cursor aparece donde tocaste, la página se desplaza para revelar el campo y etiquetas/ayudas no saltan.
• Con el teclado abierto, verifica que la acción principal (Siguiente, Continuar, Enviar) siga visible y que los errores en línea sean legibles.
• Activa el autofill: contraseñas guardadas, sugerencias de códigos OTP y autocompletado de direcciones. Confirma que los valores caen en los campos correctos y no borran la entrada del usuario.
• Prueba inputs de fecha/hora y select. Asegúrate de que el selector nativo no atrape al usuario y que el valor elegido sea visible después.

Después haz una ejecución de tipeo rápido. iOS puede añadir espacios, cambiar mayúsculas y autocorregir de formas que rompen validaciones. Observa también gestores de contraseñas que rellenen un email en el campo equivocado y campos numéricos que rechacen caracteres que tu backend espera (como un + inicial en teléfonos).

Un fallo común: el botón “Crear cuenta” queda bajo el pliegue. En iPhone, se abre el teclado, la página se bloquea y el botón queda inalcanzable.

Tacto, gestos y scroll: donde las interacciones fallan

La mayoría de UIs generadas por IA se ven bien hasta que las usas con una mano en un iPhone. Los gestos de Safari pueden pelear con tu UI y los bugs de interacción son fáciles de pasar por alto si solo haces clic con un ratón.

Empieza por los targets de tap. Si un icono de cerrar, un menú kebab o una casilla pequeña requiere un tap perfecto, la gente fallará. En iOS un golpe cercano puede seleccionar texto, iniciar un scroll o golpear el elemento equivocado porque los ítems están demasiado juntos.

Pase de interacción:

• Toca cada botón principal y cada icono pequeño con el pulgar, no con el índice apuntador.
• Mantén pulsado enlaces, tarjetas y campos de entrada y confirma que nada bloquea el flujo.
• Abre un drawer, carrusel o modal, luego intenta un back swipe desde el borde izquierdo para ver si Safari roba el gesto.
• Doble toque cerca de textos e inputs para comprobar zoom inesperado y saltos de layout.
• Desplázate dentro de áreas anidadas (lista dropdown, hilo de chat, bottom sheet) y confirma que la página de fondo no se desplaza.

El long‑press sorprende mucho. iOS puede mostrar vistas previas de enlaces, manejadores de selección o un menú contextual. Eso está bien en enlaces reales, pero es un problema cuando un “botón” es en realidad un enlace estilizado o un div que solo parece interactivo.

Los conflictos con el back‑swipe son otro clásico. Si usas un swipe desde el borde izquierdo para cerrar un drawer o mover un carrusel, Safari puede interpretarlo como navegación. Prueba con el drawer abierto, con un formulario enfocado y con un scroller horizontal bajo el pulgar.

Un ejemplo concreto: un bottom sheet con una lista dentro desplaza bien en escritorio, pero en iOS desplaza unos ítems y luego la página completa empieza a moverse. Eso suele indicar que el contenedor interno no está atrapando el scroll y el gesto burbujea hacia la página.

Autenticación y estado en Safari: comprobaciones rápidas que atrapan fallos grandes

Los bugs de autenticación en Safari suelen parecer “cierres de sesión aleatorios”, pero normalmente son problemas de estado: cookies no puestas, almacenamiento bloqueado o redirecciones que pierden contexto. Trata la autenticación en Safari como una mini‑prueba aparte.

Empieza por la persistencia. Inicia sesión y luego refresca. Cierra la pestaña y vuélvela a abrir. En iOS, cambia de app y vuelve tras 10–20 segundos. Deberías seguir conectado y llegar al sitio donde estabas.

Luego prueba las partes que a Safari le molestan:

• Modo privado: ¿falla el login o “funciona” pero te olvida al instante?
• Almacenamiento: si localStorage/sessionStorage está bloqueado o se borra, ¿la app degrada de forma ordenada?
• Cookies: después del login, ¿existe una cookie de sesión que permanezca tras el refresco?
• Retorno de redirección: después de un paso de autenticación externo, ¿vuelves a la pantalla correcta?
• Sesión expirada: si el token es inválido, ¿muestras un mensaje claro y un camino seguro para re‑loguearse?

Un escenario que atrapa muchos casos: abre una página protegida en una pestaña nueva, te redirige al login, inicias sesión y luego pulsas Atrás una vez. En Safari/iOS muchas apps quedan atrapadas en un bucle de redirección o muestran una pantalla en blanco porque la app pierde el destino original.

Cuando algo falla, registra el síntoma, no solo “autenticación rota”. Etiquetas útiles son: desconectado al instante, atrapado en redirección, en blanco tras el login, botón de login sin respuesta, spinner infinito tras refrescar.

Errores comunes que cometen los equipos al hacer QA en Safari y iOS

La mayoría de problemas de Safari se filtran por una razón: los equipos prueban el camino feliz en un dispositivo y asumen que el resto está bien. Con UIs generadas por IA, esa suposición sale cara porque pequeñas diferencias de layout e input pueden romper flujos centrales.

Fallas comunes:

• Probar solo un modelo de iPhone y perder problemas de muesca/safe‑area en otros tamaños.
• Confiar en 100vh y position: fixed para páginas de altura completa y barras sticky, obteniendo saltos y solapamientos cuando la barra de direcciones cambia de altura.
• Fiabilidad en dropdowns personalizados construidos con divs. Pueden funcionar con ratón pero fallar en touch, foco y scroll.
• Ignorar autofill y gestores de contraseñas. iOS puede insertar valores sin disparar los mismos eventos que tipear, así que los scripts de validación pueden no ejecutarse.
• Enviar errores que el usuario no ve porque el estado con teclado abierto oculta textos de validación, ayudas o el botón de enviar.

Checklist de lanzamiento: cinco pases rápidos antes de dar por terminado

Antes de lanzar, haz una última pasada en un iPhone real con Safari (no solo un emulador). Es la forma más rápida de atrapar pequeños problemas iOS que se convierten en tickets de soporte.

Mantén estos pases consistentes en cada release para comparar resultados y detectar regresiones:

• Safe area y barras del navegador: visita cada pantalla clave y desplázate un poco. Comprueba que headers, botones inferiores y toasts no queden cubiertos.
• Formularios end‑to‑end: toca cada input, escribe, usa Siguiente/Hecho y envía. Asegúrate de que los errores permanezcan visibles sobre el teclado.
• Superposiciones (menús y modales): abre un modal, desplázalo internamente, ciérralo y confirma que la página no queda congelada y vuelves al mismo punto.
• Rota el dispositivo: rota en la pantalla más compleja. Observa contenido recortado y scroll atascado tras rotación.
• Autenticación y comportamiento al refrescar: inicia sesión, recarga, abre una pestaña nueva, vuelve y luego cierra sesión y recarga. Vigila bucles y estados UI desajustados.

Ejemplo: un formulario de registro que falla en iOS y cómo detectarlo rápido

Un patrón común: una página de registro generada por IA se ve perfecta en Chrome de escritorio y luego se rompe en iPhone. El equipo la lanza porque el camino feliz “funcionó una vez” en un portátil.

Fallo realista: en iPhone Safari tocas el campo de email y aparece el teclado iOS. La página no se redimensiona como esperabas, así que el botón “Crear cuenta” cae bajo el teclado y no se puede alcanzar. Luego el desplegable de “País” se abre, pero es un select personalizado que no responde bien a taps. Puedes desplazar la página detrás, pero no seleccionar una opción.

Esto se detecta rápido si ejecutas las mismas tres comprobaciones siempre: abre la página desde cero, rellena cada campo usando el teclado iOS (incluido autofill) y envía sin “ayudar” con zoom o rotación.

Captura suficiente detalle para que cualquiera lo reproduzca rápido:

• Modelo de dispositivo, versión de iOS y navegador (Safari vs navegador in‑app)
• Pasos exactos (tocar email, escribir, tocar siguiente, abrir desplegable, intentar enviar)
• Resultado esperado vs resultado real (una frase cada uno)
• Captura de pantalla o grabación corta mostrando teclado y barra de direcciones
• Si la rotación, zoom o cambio de app modifica el comportamiento

Arregla primero los bloqueos (no se puede seleccionar campos obligatorios, no se puede enviar, no se ven errores). Luego corrige los detalles (espaciado, alineación menor, renderizado de fuentes).

Siguientes pasos: arregla los fallos principales y mantiene tu QA repetible

Después del pase de Safari/iOS, no trates las notas como un montón de “bugs UI pequeños”. Conviértelas en una lista corta de correcciones que puedas terminar esta semana y vuelve a ejecutar las mismas comprobaciones para confirmar que las regresiones han desaparecido.

Mantén la lista pequeña (unas 3–7 tareas). Si tienes 20 hallazgos, agrúpalos (viewport, formularios, auth/estado) y elige los que bloquean usuarios reales.

Un buen ítem de corrección es lo bastante específico para reproducirse en minutos:

• Dispositivo + OS + navegador exacto
• Pasos claros (3–6 pasos), empezando desde una recarga fresca
• Resultado esperado vs resultado real
• Captura o grabación corta (incluye teclado/barra de direcciones cuando sea relevante)
• Una definición de “hecho” (qué vas a re‑probar)

Cuando empieces a arreglar, vuelve a probar primero las pantallas que tocaste. Una vez que esas se ven bien, vuelve a ejecutar el guion de 15 minutos de Safari/iOS end‑to‑end para atrapar efectos secundarios como nuevos bloqueos de scroll, foco roto o saltos de layout.

Si la UI fue generada por herramientas como Lovable, Bolt, v0, Cursor o Replit, planifica tiempo para limpieza. El código generado por IA suele esconder CSS frágil, manejo de estado mezclado y lógica de formularios que falla con el teclado iOS, el autofill o el cacheo de Safari.

Si los problemas se acumulan (bucles de auth, secretos expuestos, estructura espagueti, llamadas API extrañas), una auditoría suele ser más rápida que parchear a ciegas. FixMyMess (fixmymess.ai) ofrece diagnóstico y remediación de codebases para prototipos AI rotos, incluyendo reparaciones de layout, arreglos de auth/estado y endurecimiento de seguridad, para que la app sobreviva a usuarios reales de Safari en vez de solo a demos en escritorio.