Apple introduz propriedade CSS privada para adicionar efeitos Liquid Glass ao conteúdo web

• A Apple adicionou no iOS 26 a propriedade CSS privada -apple-visual-effect
• Essa propriedade permite aplicar também ao conteúdo web novos efeitos de design, como Liquid Glass e materiais de blur padrão
• Esse recurso não fica ativado por padrão no navegador Safari nem no WKWebView
• Para usá-lo no WKWebView, é preciso ativar a configuração privada useSystemAppearance, e alterar isso dificulta a aprovação na App Store
• O recurso parece ser usado principalmente internamente pela Apple, e desenvolvedores em geral não podem aproveitá-lo por enquanto

---

Visão geral

• O autor costuma vasculhar por hobby o ChangeLog do WebKit no GitHub para prever as próximas atualizações do iOS
• Logo após a WWDC recente, ele encontrou no WebKit um Pull Request chamado “[Materials] Rename 'hosted blur' materials to reference 'glass'”
• O Liquid Glass, destacado na WWDC 2025, é a maior mudança de interface do usuário (UI) desde o iOS 7
• Antes, essa mudança de design parecia restrita à UI nativa, mas esse PR sugere uma relação também com webviews

A propriedade CSS privada da Apple

• O PR revelou que a Apple introduziu a propriedade CSS privada -apple-visual-effect
• Com ela, no iOS 26 passa a ser possível aplicar o efeito Liquid Glass (por exemplo, -apple-system-glass-material)
• Também é possível usar em todas as versões materiais de blur padrão (-apple-system-blur-material-thin etc.)
• Esses materiais também são citados no guia oficial de design

Possibilidade de uso na prática

• Mesmo tentando editar e aplicar o CSS no Safari, isso não funciona na web
• Em apps baseados em WKWebView, o recurso também vem desativado por padrão
• Ele só funciona ao definir useSystemAppearance de WKPreferences como true, mas essa configuração também é privada, então não pode ser usada por vias oficiais
• De forma não oficial, ao hackear a ativação desse valor e aplicar o CSS abaixo, é possível ver o efeito

  .toolbar {  
    border-radius: 50%;  
    -apple-visual-effect: -apple-system-glass-material;  
    height: 75px;  
    width: 450px;  
  }  
  

Exemplo de CSS e aplicação condicional

• A Apple transformou esse efeito em uma propriedade CSS, permitindo definir regras diferentes de forma simples conforme o suporte

• Por exemplo, usando uma query @supports, é possível aplicar -apple-visual-effect apenas em dispositivos compatíveis

  .toolbar {  
    border-radius: 50%;  
    height: 75px;  
    width: 450px;  
    background: rgba(204, 204, 204, 0.7);  
  }  
  
  @supports (-apple-visual-effect: -apple-system-glass-material) {  
    background: transparent;  
    -apple-visual-effect: -apple-system-glass-material  
  }  
  

Significado e limitações

• É um recurso que desenvolvedores comuns não podem usar, exceto dentro da Apple
• Ainda assim, isso ajuda a entender “por que webviews dentro de apps às vezes ganham má reputação”
• Quando um webview é bem integrado de forma seamless, o usuário nem percebe que ele existe, então há menos chances de os problemas ficarem visíveis
• O fato de a Apple ter desenvolvido isso sugere indiretamente que ela o usa de fato em seus próprios serviços ou apps
• É possível que, no dia a dia, você já esteja encontrando interfaces baseadas em webview sem perceber

[ahwjdekf]

Uma coisa absurda dessas deve ser ignorada e ninguém deveria usar isso

[coremaker]

Eu comemorei quando a Apple matou o Flash porque os interesses coincidiam,
mas é irônico que uma escolha como a de agora pareça uma decisão que ignora o ecossistema existente.

É o retorno do IE?

[spp00]

Desde a era do IE, do ponto de vista dos desenvolvedores frontend, quem ocupava o papel do IE não era o Chrome, e sim o Safari. Por causa do Safari, desenvolvedores frontend precisam comprar Macs caros. Chrome e Firefox funcionam, mas há casos em que só o Safari não funciona ou exibe tudo de forma estranha.

[GN⁺]

Comentários do Hacker News

• Fornecer funcionalidades do sistema operacional (OS) apenas para os próprios apps é claramente uma prática anticompetitiva. É um caso evidente de usar a posição dominante no mercado de celulares e sistemas operacionais para dar aos próprios apps recursos que não são permitidos aos concorrentes no mercado de apps
  • No começo eu queria ficar com raiva da Apple, mas não consigo. Basta ler a documentação da WinAPI para ver uma enorme quantidade de parâmetros marcados como "reserved". Desenvolvedores de sistemas operacionais frequentemente criam recursos para uso interno. Neste caso, como é só uma melhoria de UI, não vejo por que precisaria ser privado, mas provavelmente a Apple deixou assim porque não quer continuar mantendo isso
  • Todo atributo CSS não padronizado seria então “anticompetitivo”? Fico na dúvida se -webkit-tap-highlight-color do Google também deveria ser criticado da mesma forma. A lógica seria proibir a própria prática de criar propriedades CSS proprietárias, e isso me parece um exagero
  • Não tenho certeza se isso é realmente uma "conduta claramente anticompetitiva" no sentido jurídico. Nos EUA, valeriam o Sherman Act e o Clayton Act. Como isso não entra na lista de "infrações per se" prevista nessas leis, seria aplicado o "rule of reason". Nesse caso, só seria reconhecido se a prática prejudicasse diretamente a concorrência, sem efeitos positivos relevantes e sem alternativas menos restritivas. Seria difícil provar que uma propriedade CSS causa dano real à concorrência, e ninguém impede quem quiser de implementar seu próprio CSS de “liquid glass”, então acho difícil enquadrar
  • Fico curioso sobre o que acham de casos bem mais restritivos, como hardware de computador. Por exemplo, consoles de videogame exigem que todo código tenha assinatura criptográfica, e terceiros não podem distribuir software algum sem autorização do fabricante
  • Se tornar o texto da UI mais difícil de ler for visto como vantagem competitiva, então talvez dê para argumentar isso mesmo
• Gosto da “grande teoria do webview embutido em apps do Alastair”: a principal razão de webviews embutidos em apps terem má fama é que os bem integrados nem são percebidos pelos usuários
  • Existe uma grande diferença entre quem já implementou um webview de verdade e quem ouviu dizer que basta empacotar um webapp dentro de um app nativo. A maioria está no segundo grupo
  • Então talvez seja por isso que esse recurso foi introduzido. Um jeito barato de verificar se um app usa toolkit de UI de terceiros é mudar o tema do sistema e ver se o app acompanha bem mudanças de tema, cor ou escala. Até alguns apps da própria Apple parecem não refletir o tema corretamente, então provavelmente acabaram criando uma propriedade CSS privada. Já alguns outros fornecedores de SO evitam esse problema eliminando os próprios controles de tema, para não ter de lidar com vários toolkits inacabados
  • Se alguém conseguir citar um único app com webview perfeitamente integrado, eu aceito. O usuário médio talvez não perceba, mas se isso realmente existisse, com certeza já teria sido citado ao menos uma vez no Hacker News. Em toda discussão sobre webviews alguém teria usado isso como contraexemplo: “mas o app Foo foi feito com webview e funciona perfeitamente”
  • É meio como dizer: “perucas sempre parecem falsas. Nunca vi uma que parecesse de verdade”
• Dizem que “esse recurso deve ter sido criado porque a Apple precisa dele”, mas ninguém sabe onde ele é usado. Chutando, talvez seja nas configurações do iCloud (dentro do app Ajustes) ou nas páginas de conta dos apps App Store/Music/TV (ao tocar no ícone de perfil no canto superior direito). Essas páginas muitas vezes são webviews escondidos tentando parecer nativos. O indício é que, ao pressionar por mais tempo, aparece a prévia de página web em links ``. O guia do usuário no app Tips também é um candidato. É um bom lugar para eu verificar primeiro
• É interessante especular que “a Apple vai usar isso em algum lugar”, quando na prática não conseguimos perceber onde isso é usado. Estamos lidando com webviews no iOS o tempo todo e mesmo assim sem perceber
  • Especialmente no app Ajustes, principalmente na parte de conta ou iCloud, às vezes suspeito que seja webview. Dá para desconfiar por pequenas diferenças, como ícones demorando um pouco para aparecer durante o carregamento
  • O app App Store também parece usar webviews com bastante frequência
  • Pelo que sei, Mail e Calendar também usam bastante webview
  • Acho que a Apple também pretende usar isso no Apple.com. Seria semelhante ao jeito como no passado usaram backdrop-filter para o efeito de desfoque de fundo no iOS
  • O Apple Music também parece usar webviews em muitos lugares
• Boa descoberta. A nova UI de vidro da Apple recebe muitas críticas, mas eu gosto. Parece que o OS voltou a ter uma personalidade de verdade, saindo daquela sensação monótona e sem graça. As áreas clicáveis também ficam mais fáceis de perceber, e dá para distinguir visualmente botões de texto comum. Acho uma mudança bem-vinda. Não é só por “nostalgia”; é uma mudança realmente prática. Instalei antes o iOS 26 Beta para testar sites, e embora haja alguns probleminhas, no geral parece um bom caminho para dar mais personalidade ao OS. Usuários comuns também devem gostar
  • Gosto do efeito de vidro e dos elementos estéticos, mas em vários apps a funcionalidade ficou pior do que antes. Botões antes fáceis de acessar agora ficam escondidos sob menus e mais difíceis de encontrar
  • Na minha opinião, o público em geral não vai gostar dessa mudança no sentido mais amplo. Quem acha que “o sistema operacional precisa ter personalidade” é uma minoria de entusiastas de tecnologia. A maioria vê o OS apenas como um meio para realizar tarefas, então esse tipo de mudança visual muitas vezes não significa mais do que uma curiosidade. O ponto de que mais desgosto no design liquid glass é a nova barra de abas inferior. No Apple Music isso é especialmente ruim. Agora são necessários mais cliques para usar a interface de busca, e mesmo depois de tocar na caixa de busca ainda é preciso tocar de novo para o teclado aparecer. Além disso, todas as interações ganharam animações complexas e lentas. Por exemplo, ao ir de Home para Library, a aba cresce como uma bolha acima da barra e se move brilhando, o que só distrai e não ajuda em nada. Ajustes de acessibilidade como Reduce Transparency ou Reduce Motion não se aplicam a essas animações. Na prática, vários apps padrão recentes da Apple esquecem de aplicar opções de acessibilidade ou o fazem de forma incompleta. Por exemplo, com Reduce Motion ativado, algumas animações, como tocar em um álbum, são simplificadas, mas ao deslizar para a esquerda ou em outras ações ainda continuam exageradas. Apple Podcasts e iMessage também são assim. Já o Reduce Transparency, em alguns apps, em vez de só diminuir a transparência, transforma todos os fundos em preto (#000000). Há inúmeros casos assim em todo o iOS. Faltando poucos dias para o lançamento, ainda existem lugares como dropdowns e botões inativos do teclado onde as opções de acessibilidade não são respeitadas
  • Dizer que “dá para perceber visualmente o tamanho da área clicável e que os botões se distinguem claramente do texto” não estabelece exatamente um padrão muito alto
  • Pessoalmente, estou mais no campo do “esse design é realmente horrível”. Não faço ideia do que a Apple estava pensando
• Talvez a Apple ainda queira que ninguém use esse recurso. Com o anúncio do novo OS, é provável que muitos desenvolvedores tentem adotá-lo imediatamente, então talvez a empresa quisesse primeiro definir internamente como vai usá-lo antes de torná-lo público. Também é verdade que há algumas críticas sem fundamento neste tópico. Ainda não dá para saber qual lado está certo
• A proposição “é porque a Apple vai usar” nem sempre está correta. Softwares reais têm uma enorme quantidade de código e recursos que nunca são usados. A direção do desenvolvimento muda várias vezes, e uma propriedade CSS adicionada na segunda etapa pode simplesmente desaparecer na quarta
• Espero sinceramente que liquid jelly não vire tendência
  • Independentemente de gostar ou não de liquid glass, a mudança de paradigma de “o chrome da UI envolve o conteúdo do app” para “a UI cobre o conteúdo” é voltada para o futuro. Combina bem com AR e permite separar UI e conteúdo de acordo com diferentes tamanhos de tela. Esta implementação tem prós e contras, mas essa abordagem tende a se espalhar. O modelo de UI em overlay também não precisa ser transparente; pode ser opaco e ainda assim parecer flutuante
  • A geração mais jovem tem nostalgia da estética da era Aero/Glass. Como a Apple adotou isso, há uma boa chance de virar tendência. Existe um clima na indústria de copiar tudo o que a Apple faz
  • Pessoalmente, eu só queria que removessem o efeito de bounce/jiggle. Tremula e balança demais, então em vez de parecer vidro passa uma impressão de gelatina, como uma massa mole
  • Também espero que isso não vire moda, mas sinceramente acho que, se a Apple fizer, todo mundo vai acabar copiando
  • Já está virando moda
• Estão dizendo que é preciso ativar a configuração useSystemAppearance em WKPreferences, mas que isso é privado e por isso o app não conseguiria aprovação na App Store. Queria saber se isso é verdade. Não entendo profundamente de desenvolvimento para iOS, mas lembro de ter visto um vídeo decompilando um app que criava widgets animados na tela inicial usando várias APIs internas
  • Isso não passaria pela revisão da App Store
  • Está falando deste vídeo?
• É a moda mais feia que já vi desde cantos arredondados e padding largo. Espero que desapareça o quanto antes

[addons]

Para de besteira e cuida direito da compatibilidade do Safari.