Liquid Glass obriga redesenho dos apps iOS, segundo o HIG atualizado
A documentação de Materiais do Human Interface Guidelines, atualizada em 30 de setembro de 2026, detalha como o Liquid Glass separa camada de controles e camada de conteúdo, e por que times que não seguirem os novos tokens de contraste arriscam um app com cara de desatualizado.
Desde que a Apple apresentou o Liquid Glass, em 2025, junto com o iOS↳iOS38 conteúdosO X do Xamarin Forms – O guia das funcionalidades nativas – Parte 01: iOSDev (Back & Front) · abr 2019Desenvolvedores: Apple libera terceiro beta do iOS 12.4Dev (Back & Front) · mai 201910 bibliotecas que todo desenvolvedor iOS deve substituir ainda em 2024Dev (Back & Front) · out 2024Ver tudo em Dev (Back & Front) → 26, boa parte dos times de produto tratou o material como só mais um verniz visual: trocar uns fundos foscos por um vidro translúcido e seguir em frente. A página de Materiais do Human Interface Guidelines, atualizada em 30 de setembro de 2026, deixa claro que não é bem assim. O documento formaliza um modelo de camadas que redefine onde cada elemento de interface pode (e não pode) morar, além de um sistema de contraste que não aceita mais cor fixa em cima de material translúcido.
Para quem desenha ou mantém apps iOS, isso significa revisar tokens de profundidade, de contraste e até a lista de componentes que o design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → considera "padrão". Ignorar essa atualização não quebra o app, mas deixa visível a diferença entre quem seguiu o guideline e quem só trocou a cor de fundo.
Duas camadas, duas regras diferentes
O HIG separa a interface em duas camadas com funções distintas. A camada funcional, que inclui tab bars, sidebars e controles de navegação, usa Liquid Glass e flutua sobre o conteúdo, permitindo que ele role e apareça por trás dos controles. A camada de conteúdo, onde ficam o texto e as informações principais, usa os materiais padrão (ultraThin, thin, regular, thick).
A regra que mais gente vai esquecer de aplicar: o guideline diz explicitamente para não usar Liquid Glass na camada de conteúdo, porque isso cria hierarquia visual confusa. A única exceção prevista são controles transitórios e interativos, como sliders e toggles, que podem assumir a aparência de Liquid Glass só enquanto a pessoa interage com eles. Fora isso, se um elemento está competindo com o conteúdo por atenção, ele está na camada errada.
A orientação complementar é usar o efeito com parcimônia: componentes de sistema (como os de SwiftUI) já herdam o comportamento de Liquid Glass automaticamente, e aplicar o material em controles customizados deve ficar restrito aos elementos funcionais mais importantes da tela. Empilhar o efeito em vários controles próprios tende a distrair do conteúdo, que é exatamente o que o material deveria valorizar.
Regular ou clear: a escolha que depende do fundo
O Liquid Glass tem duas variantes, e escolher a errada é a forma mais rápida de perder legibilidade. A variante regular borra e ajusta a luminosidade do conteúdo de fundo para manter o texto legível; é a que a maioria dos componentes de sistema usa, e a recomendada para telas com bastante texto, como alertas, sidebars e popovers. A variante clear é altamente translúcida e prioriza a visibilidade do que está atrás, pensada para controles sobre fotos e vídeos.
O detalhe que frequentemente passa batido no redesenho: usar clear sobre um fundo claro exige uma camada de escurecimento. O HIG recomenda uma camada escura com 35% de opacidade quando o conteúdo por trás é brilhante; se o fundo já é escuro, ou se o app usa os controles de reprodução padrão do AVKit (que já trazem essa camada embutida), o escurecimento extra é dispensável.
| Variante | Quando usar | Cuidado principal |
|---|---|---|
regular | Alertas, sidebars, popovers, telas com texto | Pode ficar mais escura ou clara conforme o fundo e as configurações de acessibilidade |
clear | Controles sobre fotos e vídeos | Precisa de camada de escurecimento de 35% sobre fundo claro |
Vibrancy: o fim da cor fixa em cima de material
O ponto que mais afeta o trabalho de quem mantém tokens de cor é a recomendação contra escolher material ou efeito pela cor que ele parece dar à interface. Como configurações do sistema mudam a aparência do material em tempo real, cor fixa (tipo systemGray3 aplicada direto num ícone) tende a perder contraste dependendo do fundo. A solução indicada é usar cores vibrantes do sistema, que se ajustam automaticamente ao material por baixo.
Em iOS e iPadOS, o HIG define camadas de vibrancy com nomes que indicam o nível de contraste esperado:
UIVibrancyEffectStyle.label(contraste padrão, mais alto)UIVibrancyEffectStyle.secondaryLabelUIVibrancyEffectStyle.tertiaryLabelUIVibrancyEffectStyle.quaternaryLabel(contraste mais baixo; evitar sobrethineultraThin)
Para preenchimentos existe uma escala parecida (fill, secondaryFill, tertiaryFill), e separadores têm um único nível de vibrancy que funciona em qualquer material. Na prática, isso empurra o design system de "cor de texto = hex fixo" para "cor de texto = papel semântico", porque é o sistema, não o design token estático, quem decide o valor final renderizado.
O mesmo material, comportamentos diferentes por plataforma
O guideline não trata Liquid Glass como um componente único replicado em toda plataforma; cada sistema operacional usa o material de um jeito. Em tvOS, por exemplo, elementos como botões e views de imagem adotam Liquid Glass quando ganham foco, e o material aparece em experiências de sistema como o Centro de Controle. Em visionOS, as janelas usam por padrão um material chamado _glass_, que não é configurável e deixa luz, ambiente e objetos físicos aparecerem através da janela, com a recomendação explícita de preferir translucidez a cores opacas para não bloquear a percepção do espaço ao redor.
Em macOS, o sistema oferece materiais padrão com propósitos definidos e versões vibrantes de todas as cores de sistema, acessíveis via NSVisualEffectView.Material, além de dois modos de blend de fundo (atrás da janela e dentro da janela). Quem mantém app multiplataforma não pode copiar o mesmo conjunto de tokens de iOS para macOS ou visionOS: a API é parecida, mas a semântica de cada material muda conforme a plataforma.
O que quebra, e quando não vale a pena
Apps com chrome customizado em cor sólida, barras de navegação fixas ou paletas hardcoded são os que mais sofrem com a atualização: eles não herdam o comportamento automático de Liquid Glass e ficam visualmente destoantes ao lado de apps que seguiram o guideline, especialmente sob configurações de acessibilidade como redução de transparência ou aumento de contraste, que alteram a aparência das duas variantes do material.
Em resumo: nem todo app precisa correr para adotar Liquid Glass em tudo. Apps fortemente de marca, como jogos ou experiências com identidade visual própria muito distante do sistema, podem deliberadamente manter chrome customizado na camada de conteúdo, desde que ainda respeitem as configurações de acessibilidade do usuário. O problema não é recusar o material: é aplicá-lo pela metade, com a camada funcional em Liquid Glass e a de conteúdo ainda presa a cores e materiais antigos, porque aí a inconsistência fica mais visível do que a ausência total do efeito.
Fonte: Apple Human Interface Guidelines — Materials (Liquid Glass)
Este artigo foi escrito por Yara Uchôa, colunista de UX e product design. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Jev: o modelo de decisão que troca geração de texto por respostas instantâneas em produção
Em episódio do podcast How I AI, o educador John Lindquist mostra oito casos reais de uso do Jev, modelo de decisão da TypeSafe AI que troca geração de texto por respostas quase instantâneas e custo baixo o bastante para ideias antes impraticáveis.
