Liquid Glass na prática: lições de UI e UX da Apple

Uma barra translúcida fica bonita sobre uma imagem escura. Ao rolar para uma fotografia clara, os mesmos ícones ficam difíceis de encontrar. Esse é um bom ponto de partida para estudar Liquid Glass na prática: o material precisa continuar funcionando quando o conteúdo por trás muda.

Para quem conecta design e front-end, o assunto vai além de reproduzir um blur. Ele envolve hierarquia, estados, legibilidade e a capacidade de um componente se adaptar sem perder sua função.

O que é Liquid Glass e o que mudou em 2026?

A Apple apresentou Liquid Glass em 2025 como parte de uma linguagem visual compartilhada entre suas plataformas, com adoção por SwiftUI, UIKit e AppKit. Não é apenas uma propriedade de transparência aplicada a qualquer superfície. Apresentação original da Apple.

Em junho de 2026, a empresa anunciou refinamentos de legibilidade, consistência e personalização, incluindo um controle de transparência em Ajustes. O anúncio também descreve adaptação às preferências de acessibilidade. Essas informações pertencem à evolução apresentada naquele evento; não devem ser atribuídas retroativamente a todas as versões anteriores. Atualização oficial de junho de 2026.

Minha leitura é que essa evolução evidencia um problema clássico de produto: identidade visual precisa conviver com diferenças de conteúdo, contexto e preferência pessoal.

Liquid Glass na prática começa pela hierarquia

A sessão de design da Apple apresenta o material como uma camada funcional de controles e navegação, preservando a importância do conteúdo. A percepção de profundidade e o comportamento do material fazem parte dessa relação. Meet Liquid Glass, WWDC25.

Eu levaria essa ideia para uma revisão de interface com três perguntas:

• O que é conteúdo e o que é controle?
• O efeito ajuda a distinguir essas camadas?
• A ação continua fácil de encontrar quando o fundo muda?

Se todo card, formulário e bloco de texto tiver o mesmo tratamento translúcido, a hierarquia tende a perder força. Minha recomendação é reservar o material para situações nas quais a sobreposição comunica uma relação útil: uma barra de ferramentas sobre uma área de trabalho, por exemplo.

Num texto longo, eu normalmente escolheria uma superfície estável. A leitura não deveria depender da fotografia que passa atrás do parágrafo.

Adoção nativa e inspiração na web são trabalhos diferentes

Para apps Apple, o ponto de partida é revisar controles e componentes do sistema antes de redesenhar tudo manualmente. A documentação de adoção orienta o uso das APIs e a revisão de personalizações que podem competir com o novo visual. Guia de adoção de Liquid Glass.

Na web, backdrop-filter pode aplicar efeitos à região atrás de um elemento. Isso permite uma superfície desfocada, mas não equivale ao material nativo nem reproduz automaticamente sua adaptação. Referência de backdrop-filter.

Essa diferença precisa aparecer no escopo. Eu chamaria um componente CSS de superfície translúcida inspirada no conceito, não de implementação oficial de Liquid Glass.

Um exemplo web com alternativa sólida

O componente abaixo usa uma superfície sólida por padrão. A translucidez é uma opção explícita; assim, a versão básica continua funcionando sem depender do filtro.

import type { ReactNode } from 'react';

type ActionBarProps = {
  label: string;
  children: ReactNode;
  translucent?: boolean;
};

export function ActionBar({
  label,
  children,
  translucent = false,
}: ActionBarProps) {
  return (
    <nav
      aria-label={label}
      className="action-bar"
      data-translucent={translucent ? 'true' : 'false'}
    >
      {children}
    </nav>
  );
}

.action-bar {
  display: flex;
  flex-wrap: wrap;
  gap: 0.75rem;
  padding: 1rem;
  color: #fff;
  background: #21182f;
  border: 1px solid #766687;
  border-radius: 1.25rem;
}

.action-bar a {
  color: inherit;
  padding: 0.5rem 0.75rem;
  border-radius: 0.5rem;
}

.action-bar a:focus-visible {
  outline: 3px solid #dcc9ff;
  outline-offset: 3px;
}

@supports (backdrop-filter: blur(12px)) {
  .action-bar[data-translucent='true'] {
    background: rgb(33 24 47 / 92%);
    backdrop-filter: blur(12px);
  }
}

@media (prefers-reduced-transparency: reduce), (prefers-contrast: more) {
  .action-bar[data-translucent='true'] {
    background: #21182f;
    backdrop-filter: none;
  }
}

@media (forced-colors: active) {
  .action-bar {
    color: CanvasText;
    background: Canvas;
    border-color: CanvasText;
    backdrop-filter: none;
  }
}

O exemplo foi pensado para links de navegação. Se o conteúdo for um conjunto de ações, eu escolheria a semântica correspondente e botões reais. Aparência não determina o elemento HTML.

A opacidade alta é uma escolha conservadora, não uma prova de conformidade. Teste os fundos reais, foco, zoom e estados de interação. A detecção de redução de transparência ainda tem suporte limitado; por isso, a alternativa sólida continua sendo parte do contrato do componente. Compatibilidade de prefers-reduced-transparency.

Contraste precisa ser avaliado na composição

O critério WCAG 2.2 de contraste mínimo pede, em geral, relação de 4,5:1 para texto comum e 3:1 para texto grande, com as exceções descritas na norma. Em uma superfície translúcida, a cor percebida do fundo varia com a composição. WCAG: Contrast Minimum.

Minha revisão incluiria fundo branco, preto, fotografia detalhada e conteúdo em movimento. Um token chamado text-primary não garante contraste em todas essas combinações.

Também separaria redução de movimento de redução de transparência. Uma pessoa pode preferir superfícies opacas sem pedir que todas as animações sejam removidas. São dimensões diferentes da experiência.

Como eu organizaria isso no design system

Eu documentaria o material pelo papel, não apenas pelos valores de blur:

Isso torna a conversa entre design e desenvolvimento mais concreta. O componente não é aprovado apenas por se parecer com uma referência; ele precisa cumprir condições observáveis.

Quando eu usaria isso em um projeto real?

Usaria em uma navegação compacta sobre uma galeria ou em controles de uma experiência visual. Evitaria em tabelas densas, conteúdo editorial longo e áreas nas quais transparência só introduz ruído.

Para performance, testaria o tamanho da superfície e o comportamento durante scroll no aparelho-alvo. Não prometeria que “usa GPU, então é barato”. Uma composição precisa ser medida, especialmente quando envolve grandes áreas e conteúdo se movendo atrás.

Erros comuns

Copiar o material e ignorar a hierarquia

Aplicar vidro em tudo enfraquece a distinção entre navegação e conteúdo. Eu começaria pelo mapa de camadas antes de ajustar o efeito.

Validar apenas uma captura de tela

O fundo muda, o texto cresce e o estado de foco aparece. Uma imagem estática não cobre esses cenários.

Remover bordas e foco em nome da limpeza

A pessoa precisa reconhecer o controle e localizar o foco. Eu preservaria esses sinais mesmo quando o efeito visual fosse reduzido.

Conclusão

Estudar Liquid Glass na prática é estudar como um material serve à interface. Minha recomendação é definir primeiro função, hierarquia e condições de legibilidade. A aparência vem depois, com uma alternativa estável para os contextos em que transparência não ajuda.