Apple introduce una propiedad CSS privada para añadir el efecto Liquid Glass al contenido web

• Apple añadió en iOS 26 una propiedad CSS privada llamada -apple-visual-effect
• Esta propiedad permite aplicar también al contenido web nuevos efectos de diseño como Liquid Glass y materiales estándar de blur
• Esta función no está activada por defecto en Safari ni en WKWebView
• Para usarla en WKWebView, hay que activar una configuración privada llamada useSystemAppearance, pero cambiarla dificulta la aprobación en la App Store
• Todo indica que esta función se usa principalmente de forma interna en Apple, y los desarrolladores comunes no pueden aprovecharla por ahora

---

Resumen

• El autor suele revisar por hobby el GitHub ChangeLog de WebKit para anticipar futuras actualizaciones de iOS
• Poco después de la WWDC reciente, encontró en WebKit un Pull Request titulado “[Materials] Rename 'hosted blur' materials to reference 'glass'”
• Liquid Glass, destacado en la WWDC 2025, es el mayor cambio en la interfaz de usuario (UI) desde iOS 7
• Hasta ahora era un cambio de diseño aplicado solo a la UI nativa, pero este PR sugiere una relación con las web views

La propiedad CSS privada de Apple

• El PR revela que Apple introdujo una propiedad CSS privada llamada -apple-visual-effect
• Con esta propiedad, en iOS 26 es posible aplicar el efecto Liquid Glass (por ejemplo, -apple-system-glass-material)
• También permite usar en todas las versiones materiales estándar de blur (-apple-system-blur-material-thin, etc.)
• Estos materiales también aparecen mencionados en la guía oficial de diseño

Posibilidades reales de uso

• Aunque se intente editar y aplicar el CSS en Safari, no funciona en la web
• En apps basadas en WKWebView, también está desactivado por defecto
• Solo funciona si se cambia a true el valor de useSystemAppearance en WKPreferences, pero como esa configuración también es privada, no puede usarse por vías oficiales
• Si se habilita ese valor de forma no oficial mediante hacks y luego se aplica un CSS como el siguiente, sí es posible ver el efecto

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

Ejemplo de CSS y aplicación condicional

• Apple convirtió este efecto en una propiedad CSS, lo que permite definir fácilmente distintas reglas según haya soporte o no

• Por ejemplo, usando una consulta @supports, se puede aplicar -apple-visual-effect solo en dispositivos compatibles

  .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 y limitaciones

• Es una función que los desarrolladores comunes no pueden usar, salvo dentro de Apple
• Aun así, esto da una pista de por qué los webviews dentro de apps a veces tienen mala reputación
• Cuando un webview está integrado de forma realmente fluida, el usuario ni siquiera nota que existe, por lo que es menos probable que los problemas se hagan visibles
• El hecho de que Apple haya desarrollado esto sugiere indirectamente que ya lo usa en sus propios servicios o apps
• Es posible que en la vida diaria ya estés interactuando con interfaces basadas en webview sin darte cuenta

[ahwjdekf]

Hay que ignorar este tipo de tonterías ridículas y nadie debería usarlo.

[coremaker]

Cuando Apple acabó con Flash, aplaudí porque los intereses coincidían,
pero resulta irónico que una decisión como esta ahora se sienta como ignorar el ecosistema existente.

¿Es el regreso de IE?

[spp00]

Desde la era de IE, desde la perspectiva de los desarrolladores frontend, el equivalente a IE no ha sido Chrome sino Safari. Por culpa de Safari, los desarrolladores frontend tienen que comprar Macs caras. Hay casos en los que Chrome y Firefox funcionan bien, pero solo en Safari no funciona o se ve raro.

[GN⁺]

Opiniones de Hacker News

• Ofrecer funciones del sistema operativo (OS) exclusivamente a sus propias apps es claramente una práctica anticompetitiva. Usar una posición dominante en el mercado de teléfonos y sistemas operativos para reservar en el mercado de apps funciones que no se permiten a la competencia es un caso evidente
  • Al principio quería enojarme con Apple, pero en realidad no me sale. Basta leer la documentación de WinAPI para ver que hay muchísimos parámetros marcados como "reserved". Los desarrolladores de sistemas operativos a menudo crean funciones para uso interno. En este caso, como es solo una mejora visual de la UI, no parece necesario mantenerla privada, pero probablemente Apple la dejó así porque no quiere hacerse cargo de mantenerla
  • ¿Entonces toda propiedad CSS no estándar es “anticompetitiva”? También habría que criticar la de Google, -webkit-tap-highlight-color, me pregunto. La lógica sería prohibir por completo la práctica de crear propiedades CSS propietarias, y esa postura me parece exagerada
  • No está claro que esto sea realmente una "conducta manifiestamente anticompetitiva" en el sentido legal. En Estados Unidos aplicarían la Sherman Act y la Clayton Act como leyes de competencia. Como esto no entra en la lista de "violaciones per se" enumeradas por esas leyes, lo más probable es que se aplique la "regla de la razón". En ese caso, solo se reconoce si la conducta perjudica directamente a la competencia y no tiene efectos positivos relevantes ni alternativas menos restrictivas. Sería difícil demostrar qué daño real causa a la competencia una propiedad CSS, y además nadie impide que quien quiera implemente por su cuenta un CSS de “liquid glass”, así que parece difícil que aplique
  • Me pregunto qué opinan de casos mucho más restrictivos, como el hardware de computadoras. Por ejemplo, en las consolas de videojuegos todo el código debe estar firmado y cifrado, y ningún tercero puede distribuir software sin autorización del fabricante
  • Si se considera que hacer que el texto de la UI sea difícil de leer es una ventaja competitiva, entonces supongo que podría verse así
• Me gusta la “gran teoría de Alastair sobre las webviews dentro de apps”: la principal razón por la que las webviews integradas en apps tienen tan mala fama es que, cuando están bien integradas, el usuario ni siquiera se da cuenta
  • Hay una gran diferencia entre alguien que realmente ha implementado una webview y alguien a quien le dijeron que basta con envolver una web app en una app nativa y publicarla. La mayoría pertenece al segundo grupo
  • Por eso probablemente introdujeron esta función. Normalmente, una manera barata de detectar si una app usa un toolkit de UI de terceros es cambiar el tema del sistema y ver si la app sigue bien los cambios de tema, color o escala. Como incluso algunas apps hechas por Apple no reflejan bien el tema, probablemente terminaron creando una propiedad CSS privada. En cambio, algunos otros proveedores de sistemas operativos directamente eliminan los controles de tema para evitar el problema de tener que lidiar con varios toolkits a medio terminar
  • Si alguien puede dar aunque sea un solo ejemplo de una app con webview perfectamente integrada, se lo concedo. Puede que el usuario promedio no lo note, pero si de verdad existiera, seguro ya habría sido mencionada al menos una vez en Hacker News. En cada discusión sobre webviews se usaría como contraejemplo: “pero la app Foo está hecha con webview y funciona perfecto”
  • Se siente como decir: “las pelucas siempre se ven falsas. Nunca he visto una que pareciera real”
• Dicen que “seguro esta función existe porque Apple la necesita”, pero nadie sabe dónde la usa. Si tuviera que adivinar, diría que en la configuración de iCloud dentro de la app Ajustes, o en las páginas de cuenta de App Store/Music/TV al tocar el ícono de perfil arriba a la derecha. Muchas de esas páginas son webviews ocultas que intentan parecer nativas. Una pista es que, si haces una pulsación larga, aparece la vista previa de página web de un enlace ``. La guía de usuario de la app Tips también podría ser candidata. Serían buenos lugares para revisar primero
• Es interesante que se especule con que “Apple la usará en algún lado”, pero en la práctica no hayamos podido notar dónde la usa. Resulta que convivimos con webviews en iOS todo el tiempo sin darnos cuenta
  • Especialmente en la app Ajustes, sobre todo en la parte de cuenta o iCloud, a veces sospecho que hay webviews. Se nota por pequeñas diferencias, como que algunos íconos parecen cargarse más tarde
  • La app App Store también parece usar muchísimas webviews
  • Según entiendo, Mail y Calendar también usan bastantes webviews
  • Yo creo que también piensan usarlo en Apple.com. Sería parecido a cuando usaron backdrop-filter para el efecto de desenfoque de fondo en iOS
  • Apple Music también parece usar muchas webviews
• Buen hallazgo. La nueva interfaz de vidrio de Apple ha recibido muchas críticas, pero a mí sí me gusta. Se siente como si el OS volviera a tener una personalidad real, y como si saliera de lo monótono y plano. También se distinguen mejor las áreas clicables y es más fácil diferenciar visualmente los botones del texto normal. Me parece un cambio bienvenido. No es solo por “nostalgia”; es un cambio realmente práctico. Instalé iOS 26 Beta antes para probar sitios web, y aunque hay algunos problemas menores, en general me parece positivo que el OS tenga más personalidad. Creo que a los usuarios comunes también les va a gustar
  • Me gusta el efecto de vidrio y la parte estética, pero en varias apps la funcionalidad se volvió peor que antes. Botones a los que era fácil acceder ahora quedaron escondidos dentro de menús y cuesta más encontrarlos
  • En mi opinión, el público general no va a disfrutar este cambio en términos amplios. La gente que cree que “un sistema operativo debe tener personalidad” es una minoría de entusiastas de la tecnología. La mayoría ve el OS simplemente como un medio para hacer algo, así que estos cambios visuales a menudo no significan mucho más que una curiosidad. En particular, lo que menos me gusta del diseño liquid glass es la nueva barra de pestañas inferior. En Apple Music es donde peor se nota. Ahora hay un clic extra para usar la interfaz de Search, y aun después de tocar la caja de Search hay que tocar otra vez para que aparezca el teclado. Además, agregaron animaciones complejas y lentas a todas las interacciones. Por ejemplo, al pasar de Home a Library, la pestaña se agranda como una burbuja sobre la barra y se desplaza brillando, lo cual solo distrae y no ayuda. Ajustes de accesibilidad como Reduce Transparency o Reduce Motion no se aplican a estas animaciones. De hecho, últimamente varias apps predeterminadas de Apple olvidan aplicar esas opciones de accesibilidad o lo hacen de forma deficiente. Por ejemplo, con Reduce Motion activado, algunas animaciones como tocar un álbum sí se simplifican, pero al deslizar a la izquierda u otras acciones siguen siendo excesivas. Lo mismo pasa en Apple Podcasts e iMessage. Reduce Transparency, en algunas apps, en vez de reducir la transparencia pone todos los fondos en negro (#000000). Hay muchísimos casos así en iOS. Y aun a pocos días del lanzamiento, hay lugares como dropdowns o botones inactivos del teclado donde esas opciones de accesibilidad siguen sin reflejarse
  • Eso de que “se puede ver el tamaño del objetivo clicable y los botones se distinguen claramente del texto” en realidad no pone la vara muy alta
  • Personalmente, yo estoy del lado de “este diseño es realmente horrible”. No sé qué estaba pensando Apple
• Tal vez Apple en realidad todavía no quiere que nadie use esta función. Como con el anuncio del nuevo OS muchos desarrolladores probablemente querrán adoptarla de inmediato, quizá Apple quiso asegurar primero su uso interno antes de hacerla pública. También es cierto que en este hilo hay algunas críticas sin fundamento en ambos sentidos. Todavía no sabemos cuál versión es la correcta
• La idea de que “si Apple la hizo, entonces es porque la usa” no siempre es cierta. En el software real hay muchísimas líneas de código y funciones que nunca se usan. A veces la dirección del desarrollo cambia varias veces, y una propiedad CSS añadida en la segunda etapa puede desaparecer por completo en la cuarta
• De verdad espero que liquid jelly no se vuelva tendencia
  • Te guste o no liquid glass, el cambio de paradigma de “el chrome de la UI envuelve el contenido de la app” a “la UI se superpone al contenido” sí apunta al futuro. Encaja bien con AR y permite separar UI y contenido según distintos tamaños de pantalla. Esta implementación concreta tiene pros y contras, pero este enfoque se va a usar más en adelante. El modelo de UI superpuesta tampoco tiene por qué ser transparente; también puede ser opaco y flotante
  • La generación joven está atrapada por la nostalgia estética de la era Aero/Glass. Como Apple lo adoptó, es muy probable que se vuelva tendencia. En toda la industria hay un ambiente de copiar lo que haga Apple sí o sí
  • Personalmente, me gustaría que al menos quitaran el efecto de rebote/temblor. Se sacude demasiado y, en vez de verse como vidrio, termina pareciendo una masa gelatinosa
  • Yo también espero que no se ponga de moda, pero sinceramente creo que si Apple lo hace, al final todos la van a seguir
  • Ya se está poniendo de moda
• Dicen que hay que activar un ajuste llamado useSystemAppearance en WKPreferences, pero que como es privado no se puede pasar la aprobación del App Store. Me da curiosidad si eso es cierto. No soy experto en desarrollo para iOS, pero recuerdo haber visto un video donde descompilan una app que hacía widgets animados en la pantalla de inicio usando varias APIs internas
  • Eso no pasaría la revisión del App Store
  • ¿Te refieres a este video?
• Es la moda más fea que he visto desde las esquinas redondeadas y el padding excesivo. Ojalá desaparezca lo antes posible

[addons]

Dejen de decir tonterías y mejor ocúpense de mantener bien la compatibilidad de Safari.