QA cross-browser para UIs geradas por IA: roteiro de testes para Safari/iOS

Por que o Safari e o iOS quebram quando tudo parecia certo no Chrome

Se sua UI gerada por IA parece perfeita no Chrome, ainda assim ela pode não estar pronta. O Safari no macOS e, especialmente, o Safari no iPhone podem se comportar de forma diferente em maneiras pequenas, porém dolorosas.

Os testes no Chrome costumam não pegar peculiaridades específicas do Safari, como a altura do viewport mudando quando a barra de endereço aparece ou desaparece, estilos padrão diferentes para controles de formulário e regras mais estritas sobre armazenamento e cookies. No iOS, todos os navegadores usam o mesmo motor WebKit, então não é só um problema do Safari — é um problema do iPhone.

UIs geradas por IA também tendem a falhar nas bordas. Podem funcionar bem em uma demo do caminho feliz, mas quebrar quando o teclado abre, quando o autofill entra em ação ou quando um modal aparece sobre uma página rolável. Telas de autenticação são um ponto fraco comum: um pequeno deslocamento de layout pode esconder o botão de enviar, e um problema sutil de cookies ou armazenamento pode transformar “logado” em “deslogado” após um refresh.

Um roteiro de testes curto e repetível ajuda a encontrar os problemas importantes antes de você gastar tempo fazendo polimento. Uma boa passagem Safari/iOS deve confirmar:

• O layout permanece utilizável quando o viewport muda (rotação, barra de endereço, teclado).
• Toques, scroll e foco se comportam normalmente (sem scroll travado, sem botões mortos).
• Formulários funcionam com o teclado iOS, autofill e gerenciadores de senha.
• Autenticação e estado sobrevivem a refresh, backgrounding e retorno ao app.

Se você vai compartilhar um link de demo ou colocar usuários reais, 15 minutos em um iPhone podem economizar dias de confusão.

Um exemplo simples: uma página de cadastro que “funciona” no desktop pode falhar no iPhone porque o teclado cobre o botão de enviar e a página não rola. Você só percebe quando o primeiro usuário real fica preso.

Antes de testar: escolha os fluxos e dispositivos que importam

Testes em Safari e iOS ficam ruidosos rapidamente. Mantenha a utilidade decidindo desde o começo o que precisa funcionar para usuários reais. Para QA cross-browser de UIs geradas por IA, isso geralmente significa um pequeno conjunto de fluxos end-to-end testados em um pequeno conjunto de dispositivos reais.

Escolha 2–3 fluxos chave que definem o produto. Mantenha-os simples e completos: alguém consegue criar uma conta, entrar novamente e finalizar a ação principal (comprar, reservar, submeter ou salvar)? Se você testar apenas telas isoladas, perderá falhas do Safari que acontecem durante navegação, redirecionamentos e mudanças de estado.

Escolha dispositivos que correspondam ao uso real do seu app. Teste pelo menos um iPhone com notch (problemas de safe area e viewport aparecem aí). Adicione um Mac rodando Safari também, porque o Safari desktop tem suas próprias esquisitices com layout, armazenamento e inputs de arquivo.

Escreva regras de passa/falha antes de começar. Caso contrário, todo achado vira discussão. Considere bloqueadores tudo que impeça o fluxo ou arrisque dados/segurança (não é possível submeter, não é possível logar, preço errado, segredo exposto). Questões cosméticas são menores (quebra de linha estranha, desalinhamento pequeno).

Mantenha uma nota curta de preparação para cada execução:

• Versão de build e ambiente (prod, staging, preview)
• Dispositivos e versões de SO usados
• Contas de teste e dados de exemplo que você vai reutilizar
• Limitações conhecidas (feature flags, rollout parcial, endpoints quebrados)
• Um lugar para rastrear bloqueadores vs problemas menores

O roteiro de 15 minutos para Safari/iOS (passo a passo)

Este roteiro é para QA cross-browser de UIs geradas por IA, onde um layout que parece perfeito no Chrome pode ainda falhar no iPhone Safari. Ajuste o tempo para 15 minutos e foque em um fluxo principal (cadastro, checkout, criar projeto).

O roteiro

Comece com uma sessão totalmente limpa. No iOS, feche a aba, reabra o Safari e carregue o app novamente para não depender de um estado em cache por sorte.

• Execute o caminho feliz uma vez, devagar, como um usuário de primeira viagem. Procure telas em branco, botões que não fazem nada e textos sobrepostos.
• Repita o mesmo fluxo em uma conexão mais lenta (ou em um ponto de Wi‑Fi fraco). Procure spinners que não param, skeletons com tamanho errado e envios duplos.
• Rode em modo retrato e paisagem na tela com mais UI. Verifique se cabeçalhos, botões fixos e barras inferiores continuam visíveis e não saltam.
• Provoque uma interrupção: bloqueie a tela ou troque de app e volte. Confirme que você continua no mesmo lugar e que não foi deslogado ou resetado.
• Capture evidências: uma curta gravação de tela e o modelo exato do dispositivo e versão do iOS.

Como é uma falha no iOS

Falhas comuns são previsíveis depois que você as viu: um formulário funciona até o teclado abrir, então o botão de enviar desliza para baixo do teclado ou a página para de rolar. Ou um modal fecha, mas a página por trás permanece congelada.

Quando problemas parecem “aleatórios”, geralmente é código de layout frágil ou tratamento de estado, comum em protótipos gerados por IA.

Dimensionamento de viewport e safe areas: as armadilhas comuns do Safari

O Safari no iOS difere do Chrome desktop em dois pontos principais: o chrome do navegador (barra de endereço e toolbars) muda de altura ao rolar, e a tela tem áreas inseguras (notch e home indicator). UIs geradas por IA frequentemente fixam tamanhos que ficam ok em um viewport estável de desktop e depois desmoronam em um iPhone real.

Faça essa checagem rápida em um iPhone com notch e gire uma vez para paisagem.

Comece por qualquer coisa presa ao topo ou fundo. Se um header, tab bar, toast ou botão inferior fica coberto pela notch, home indicator ou toolbar do Safari, as safe areas estão sendo ignoradas.

Depois procure o clássico problema do 100vh: seções dimensionadas para altura total acabam maiores do que deveriam, então o conteúdo inferior fica escondido atrás da barra de endereço ou de um footer fixo. O sinal é um botão principal “sumido” que aparece só depois de um leve scroll.

Use um modal ou drawer como teste de estresse. Abra-o, role dentro dele e tente rolar a página por trás. Se o fundo der rubber-band, o bloqueio de scroll não está funcionando no iOS.

Checklist:

• Verifique padding superior e inferior ao redor da notch e do home indicator em páginas de tela cheia.
• Role para cima e para baixo e observe conteúdo pulando quando a barra de endereço colapsa.
• Abra um modal e depois tente rolar a página por trás.
• Role uma página longa e observe jitter em headers/footers sticky.
• Mude o tamanho do texto (ajuste do iOS ou zoom da página) e cheque texto cortado.

Controles de formulário: o que testar com o teclado iOS e o autofill

No iOS, formulários são onde “parece certo no Chrome” vira dor real para o usuário. Trate cada campo como uma interação, não apenas uma caixa na página.

Fluxo de teste rápido (5 minutos por formulário)

Use dados reais, não textos de placeholder. Se possível, teste uma vez com uma sessão nova do Safari e outra com senhas/endereço salvos ativados.

• Toque em cada tipo de campo que você usa (email, senha, número, busca, textarea). Confirme que o teclado corresponde ao campo e que a digitação não é bloqueada.
• Verifique comportamento de foco: o cursor aparece onde você tocou, a página rola para revelar o campo e labels/dicas não saltam.
• Com o teclado aberto, verifique se a ação primária (Próximo, Continuar, Enviar) permanece visível e se erros inline são legíveis.
• Acione o autofill: senhas salvas, sugestões de código OTP e preenchimento de endereço. Confirme que os valores vão para os campos corretos e não apagam entrada do usuário.
• Teste inputs de data/hora e selects. Garanta que o seletor nativo não prenda o usuário e que o valor escolhido fique visível depois.

Depois, faça uma passada digitando rápido. O iOS pode inserir espaços, alterar maiúsculas e corrigir automaticamente de formas que quebram validação. Também observe gerenciadores de senha que colocam um email no campo errado e inputs numéricos que rejeitam caracteres que o backend espera (como um + inicial em telefones).

Uma falha comum: o botão “Criar conta” fica abaixo da dobra. No iPhone, o teclado abre, a página trava e o botão fica inacessível.

Toque, gestos e rolagem: onde interações de UI se desintegram

A maioria das UIs geradas por IA parece ok até você tentar usar com uma mão no iPhone. Gestos do Safari podem brigar com sua UI, e bugs de interação são fáceis de perder se você apenas clicar com o mouse.

Comece pelos alvos de toque. Se um ícone de fechar, menu kebab ou checkbox minúsculo exige um toque perfeito, as pessoas vão errar. No iOS, um toque perto pode selecionar texto, iniciar um scroll ou atingir o elemento errado porque os itens estão muito próximos.

Passada de interação:

• Toque em cada botão primário e ícone pequeno com o polegar, não com o dedo indicador.
• Faça long-press em links, cards e campos e confirme que nada bloqueia o fluxo.
• Abra uma gaveta, carrossel ou modal e tente um swipe de volta da borda esquerda para ver se o Safari rouba o gesto.
• Dê um duplo-toque perto de texto e inputs para checar zoom inesperado e saltos de layout.
• Role dentro de áreas aninhadas (dropdown, thread de chat, bottom sheet) e confirme que a página por trás não rola.

Long-press é uma surpresa comum. O iOS pode mostrar previews de link, handles de seleção ou um menu de contexto. Isso é aceitável em links reais, mas problemático quando um “botão” é na verdade um link estilizado ou uma div que só parece clicável.

Conflitos de swipe para trás também são clássicos. Se você usa um swipe da borda esquerda para fechar uma gaveta ou mover um carrossel, o Safari pode interpretar como navegação. Teste com a gaveta aberta, com um formulário focado e com um scroller horizontal sob o polegar.

Um exemplo concreto: um bottom sheet com uma lista interna rola bem no desktop, mas no iOS rola alguns itens e então a página inteira começa a se mover. Isso normalmente significa que o container interno não está prendendo o scroll e o gesto borbulha para a página.

Autenticação e estado no Safari: checagens rápidas que pegam grandes quebras

Bugs de autenticação no Safari geralmente parecem “deslogamentos aleatórios”, mas normalmente são problemas de estado: cookies não configurados, armazenamento bloqueado ou redirecionamentos perdendo contexto. Trate a autenticação no Safari como um mini-teste à parte.

Comece pela persistência. Faça login e atualize. Feche a aba e reabra. No iOS, também troque de app e volte depois de 10–20 segundos. Você deve continuar logado e voltar ao ponto onde estava.

Depois verifique as partes que o Safari é mais exigente:

• Modo privado: o login falha ou “funciona” mas esquece você instantaneamente?
• Armazenamento: se localStorage/sessionStorage for bloqueado ou limpo, o app degrada de forma aceitável?
• Cookies: após o login existe um cookie de sessão e ele permanece após refresh?
• Retorno de redirecionamento: após um passo de auth externo, você retorna à tela correta?
• Sessão expirada: se o token for inválido, há uma mensagem clara e um caminho seguro para relogar?

Um cenário que pega muitos casos: abra uma página protegida em uma nova aba, seja redirecionado para login, autentique, então aperte Voltar uma vez. No Safari/iOS muitas apps ficam presas em um loop de redirecionamento ou mostram uma tela em branco porque o app perdeu o destino original.

Quando algo quebra, registre o sintoma, não apenas “auth quebrada”. Rótulos úteis são: deslogado instantaneamente, preso em redirect, branco após login, botão de login não faz nada, spinner infinito após refresh.

Erros comuns que equipes cometem ao testar Safari e iOS

A maioria dos problemas do Safari passa despercebida por uma razão: equipes testam o caminho feliz em um dispositivo e assumem que o resto está ok. Com UIs geradas por IA, essa suposição fica cara porque pequenas diferenças de layout e input podem quebrar fluxos centrais.

Erros comuns:

• Testar apenas um modelo de iPhone e perder problemas de notch/safe-area em outros tamanhos.
• Confiar em 100vh e position: fixed para páginas de altura total e barras sticky, e depois ter pulos e sobreposições quando a barra de endereço muda de altura.
• Confiar em dropdowns customizados montados com divs. Funcionam com mouse, mas falham em toque, foco e rolagem.
• Ignorar autofill e gerenciadores de senha. O iOS pode inserir valores sem disparar os mesmos eventos que a digitação, então scripts de validação podem não rodar.
• Liberar erros que o usuário não vê porque estados com teclado aberto escondem textos de validação, dicas ou o botão de enviar.

Checklist de release: cinco passadas rápidas antes de chamar de pronto

Antes de lançar, faça uma última varredura em um iPhone real no Safari (não apenas em emulador). É a forma mais rápida de pegar pequenos problemas iOS que viram tickets de suporte.

Mantenha essas passadas consistentes a cada release para comparar resultados e detectar regressões:

• Safe area e barras do navegador: visite cada tela chave e role um pouco. Verifique headers, botões inferiores e toasts para não estarem cobertos.
• Formulários end-to-end: toque em cada input, digite, use Próximo/Concluído e submeta. Certifique-se de que erros fiquem visíveis acima do teclado.
• Overlays (menus e modais): abra um modal, role dentro, feche e confirme que a página não ficou congelada e que você retorna ao mesmo ponto.
• Rode o dispositivo: gire na sua tela mais complexa. Procure conteúdo cortado e scroll preso após a rotação.
• Autenticação e comportamento ao atualizar: faça login, recarregue, abra nova aba, retorne, então saia e recarregue. Observe loops e estados UI dessíncronizados.

Exemplo: um formulário de cadastro que quebra no iOS e como identificar rápido

Um padrão comum: uma página de cadastro gerada por IA parece perfeita no Chrome desktop, mas desaba no iPhone. A equipe envia assim porque o caminho feliz “funcionou uma vez” no laptop.

Falha realista: no iPhone Safari você toca no campo de email e o teclado do iOS sobe. A página não redimensiona como esperado, então o botão “Criar conta” cai sob o teclado e fica inacessível. Em seguida, o dropdown de “País” abre, mas é um select customizado que não responde a toques de forma confiável. Você pode rolar a página por trás, mas não consegue escolher uma opção.

Isso aparece rápido se você rodar três checagens sempre: abra a página limpa, preencha cada campo usando o teclado do iOS (incluindo autofill) e submeta sem “ajudar” com zoom ou rotação.

Capture detalhes suficientes para que qualquer pessoa reproduza rápido:

• Modelo do dispositivo, versão do iOS e navegador (Safari vs navegador in-app)
• Passos exatos (tocar email, digitar, tocar próximo, abrir dropdown, tentar submeter)
• Resultado esperado vs real (uma frase cada)
• Screenshot ou curta gravação de tela mostrando teclado e barra de endereço
• Se rotação, zoom ou troca de app muda o comportamento

Priorize correções bloqueadoras primeiro (não é possível selecionar campos obrigatórios, não é possível submeter, não é possível ver erros). Depois trate cortes menores (espaçamento, alinhamento, renderização de fonte).

Próximos passos: corrija as maiores quebras e mantenha seu QA repetível

Após a passagem Safari/iOS, não trate as notas como um monte de “bugs pequenos”. Transforme-as em uma lista curta de correções que você consegue terminar esta semana e então rode os mesmos testes para confirmar que as regressões sumiram.

Mantenha a lista pequena (cerca de 3–7 itens). Se houver 20 achados, agrupe-os (viewport, formulários, auth/estado) e escolha os que bloqueiam usuários reais.

Um bom item de correção é específico o suficiente para reproduzir em minutos:

• Dispositivo + SO + navegador exatos
• Passos claros (3–6 passos), começando por um reload limpo
• Resultado esperado vs real
• Screenshot ou curta gravação de tela (inclua teclado/barra de endereço quando relevante)
• Uma definição de “feito” (o que você vai re-testar)

Ao começar a consertar, re-teste primeiro as telas que você alterou. Depois que elas estiverem ok, rode novamente o roteiro de 15 minutos fim-a-fim para pegar efeitos colaterais como novos bloqueios de scroll, foco quebrado ou deslocamentos de layout.

Se a UI foi gerada por ferramentas como Lovable, Bolt, v0, Cursor ou Replit, planeje tempo para limpeza. Código gerado por IA frequentemente esconde CSS frágil, tratamento de estado misturado e lógica de formulário que quebra com teclado iOS, autofill ou cache do Safari.

Se os problemas se acumularem (loops de auth, segredos expostos, estrutura emaranhada, chamadas de API estranhas), uma auditoria muitas vezes é mais rápida que tentar consertar peça por peça. FixMyMess (fixmymess.ai) faz diagnóstico e remediação de codebase para protótipos gerados por IA, incluindo reparos de layout, correções de auth/estado e endurecimento de segurança, para que o app sobreviva a usuários reais do Safari em vez de apenas demos de desktop.