Liquid Glass de iOS 26 en Flutter: qué funciona hoy y qué hacer mientras llega el soporte oficial
Si mantienes una app Flutter en producción, probablemente ya lo has notado: sobre iOS 26 tus pantallas Cupertino se ven correctas, pero no "de iOS 26". No tienen el material translúcido, la refracción ni los reflejos del nuevo lenguaje de Apple. La respuesta corta: Flutter todavía no implementa Liquid Glass en la librería Cupertino actual, y el equipo de Flutter ha pausado ese trabajo hasta terminar de sacar Cupertino a un paquete independiente. No hay fecha comprometida. Eso no significa que tu app tenga que verse anticuada: hay tres vías realistas para adaptarte hoy, cada una con su coste. Este artículo explica cuál elegir según tu caso.
Es una decisión que estamos tomando estas semanas con clientes que envían apps iOS con Flutter, así que vamos al grano con lo que sabemos y lo que no.
Qué es Liquid Glass (en una frase)
Liquid Glass es el material de interfaz que Apple introdujo con iOS 26: superficies translúcidas que difuminan y realzan el contenido que tienen detrás, añaden un tinte sutil y simulan refracción y reflejos especulares en los bordes, con animaciones que reaccionan al movimiento. Aplica a barras de navegación, pestañas, hojas modales, diálogos y menús contextuales. No es solo un blur: la parte cara de imitar es la refracción y el reflejo en los bordes.
¿Flutter soporta Liquid Glass en iOS 26?
Hoy, no de forma nativa. La documentación oficial de Flutter confirma que Flutter es compatible con iOS 26, pero marca Liquid Glass como una característica "aún no implementada" y remite al issue de seguimiento #170310.
La postura del equipo de Flutter es explícita: no están desarrollando las nuevas características de diseño de Apple '26 en la librería Cupertino actual, y no aceptan contribuciones para ello por ahora. El motivo es arquitectónico: Flutter está desacoplando Material y Cupertino del núcleo del framework hacia paquetes independientes (issue #101479) para poder evolucionarlos más rápido. Todo el trabajo de iOS 26 —reconstruir NavigationBar, TabBar, Sheet, Dialog y ContextMenu contra la especificación de Liquid Glass— ocurrirá en ese paquete Cupertino independiente, una vez exista.
Esto conecta con un cambio de fondo que ya cubrimos en Material y Cupertino fuera del core de Flutter: el diseño deja de vivir en el framework para moverse a su propio ritmo.
¿Cuándo llegará? Flutter no ha comprometido una fecha. La estimación de la comunidad apunta a un paquete Cupertino utilizable hacia finales de 2026, pero conviene planificar sin darlo por hecho. Si tu roadmap depende de "cuando Flutter lo saque", no tienes un plan; tienes una espera.
Las tres vías realistas hoy
Vía 1 — Widgets nativos vía platform views
Renderizas controles UIKit reales (los que ya traen Liquid Glass en iOS 26) dentro de tu app Flutter usando un UiKitView. Es lo que hacen paquetes de la comunidad como cupertino_native, cupertino_native_plus o native_liquid_glass, que exponen botones, TabBar, sliders o switches nativos con fidelidad de píxel.
La ventaja es obvia: es el material auténtico de Apple, incluidas las animaciones, y se actualiza solo cuando Apple actualiza iOS. El coste también: las platform views son considerablemente más caras que los widgets Flutter normales, la comunicación cruza el puente de plataforma, y meterlas dentro de listas largas con scroll degrada el rendimiento de forma visible.
Cuándo NO usarla: dentro de ListView/GridView con muchos elementos, en superficies que animas a 60/120 fps, o si necesitas exactamente el mismo aspecto en Android (estos widgets solo aportan en iOS). También añade una dependencia sobre paquetes de terceros jóvenes: revisa mantenimiento antes de casarte con uno.
Vía 2 — Reproducir el material en Flutter
Aproximas el aspecto con las primitivas de dibujo del propio Flutter: BackdropFilter con ImageFilter.blur para el difuminado, una capa de tinte translúcido encima, y —para acercarte de verdad— un fragment shader que simule refracción y reflejo especular. Paquetes como cupertino_liquid_glass siguen este camino: multicapa con CustomPainter, física de muelle para las interacciones y cero código nativo.
La ventaja: funciona en iOS y Android por igual, no cruza el puente de plataforma y controlas cada detalle. La desventaja: es una imitación. Un blur con tinte se consigue en cinco líneas; la refracción y el reflejo de los bordes que hacen que Liquid Glass parezca líquido requieren shaders y ajuste fino, y aun así no serán idénticos a los de Apple. Cuando Apple retoque el material en iOS 26.x, tu versión se quedará atrás.
Un contenedor base, solo con blur y tinte (lo barato del efecto), se ve así:
import 'dart:ui';
import 'package:flutter/widgets.dart';
/// Aproximación ligera al material translúcido: difumina el fondo,
/// añade un tinte y un borde luminoso sutil. La refracción y el
/// reflejo especular reales requieren un fragment shader aparte.
class LiquidGlass extends StatelessWidget {
const LiquidGlass({super.key, required this.child, this.radius = 24});
final Widget child;
final double radius;
@override
Widget build(BuildContext context) {
return ClipRRect(
borderRadius: BorderRadius.circular(radius),
child: BackdropFilter(
filter: ImageFilter.blur(sigmaX: 24, sigmaY: 24),
child: DecoratedBox(
decoration: BoxDecoration(
borderRadius: BorderRadius.circular(radius),
gradient: const LinearGradient(
begin: Alignment.topLeft,
end: Alignment.bottomRight,
colors: [Color(0x33FFFFFF), Color(0x0DFFFFFF)],
),
border: Border.all(color: const Color(0x40FFFFFF), width: 0.8),
),
child: Padding(
padding: const EdgeInsets.all(16),
child: child,
),
),
),
);
}
}
Cuándo NO usarla: si tu objetivo es indistinguibilidad total del nativo (no la conseguirás), o si el equipo no tiene margen para mantener shaders a medida a lo largo de las revisiones de iOS.
Vía 3 — No perseguir el efecto (todavía)
La opción que casi nadie propone y que a menudo es la correcta: mantener un Cupertino limpio y coherente, sin imitar Liquid Glass, y esperar al paquete oficial. Una app con jerarquía visual clara y buen contraste no se percibe como "rota" en iOS 26; se percibe como sobria. El riesgo real no es no tener translucidez, es tener una imitación a medias que envejece peor que un diseño neutro.
Cuándo NO usarla: si tu marca compite directamente en percepción de "app premium iOS" o si tienes usuarios que van a comparar lado a lado con apps nativas de referencia. Ahí sí merece la pena invertir en la Vía 1 en las superficies clave.
Tabla de decisión
| Criterio | Vía 1 · Platform views nativos | Vía 2 · Reproducir en Flutter | Vía 3 · Esperar |
|---|---|---|---|
| Fidelidad al nativo | Máxima (es UIKit real) | Aproximada | N/A |
| Coste de rendimiento | Alto en listas/scroll | Bajo–medio | Nulo |
| Multiplataforma (Android) | No aporta | Sí | Sí |
| Mantenimiento a futuro | Lo lleva Apple | A tu cargo (shaders) | Nulo |
| Riesgo de envejecer mal | Bajo | Medio–alto | Bajo |
| Cuándo encaja | Superficies clave en iOS | Look propio uniforme | Producto sobrio o roadmap sin presión |
Cómo lo decidimos en la práctica
Nuestra recomendación por defecto para la mayoría de productos es híbrida y quirúrgica: Vía 3 como base (Cupertino limpio, sin imitaciones) y Vía 1 solo en las dos o tres superficies donde el usuario realmente percibe la diferencia —normalmente la barra de navegación y la tab bar—, aislándolas de listas con scroll para no pagar el coste de las platform views donde no aporta. La Vía 2 la reservamos para cuando el cliente quiere un lenguaje visual propio y uniforme en iOS y Android, no cuando busca clonar a Apple.
Lo importante es tratar esto como una decisión de producto con fecha de caducidad, no como una feature permanente: sea cual sea la vía, el objetivo es minimizar el trabajo que habrá que tirar cuando llegue el paquete Cupertino oficial. Si usas platform views hoy, encapsúlalas detrás de tu propia abstracción de widget; el día que exista el equivalente oficial, cambias la implementación en un sitio. Esta lógica de aislar lo nativo detrás de una frontera limpia es la misma que aplicamos al interop nativo con FFI, ffigen y jnigen, y encaja con cómo abordamos la UI adaptativa en Flutter.
Conclusión
Flutter no soporta Liquid Glass de iOS 26 de forma nativa hoy, y el trabajo oficial no llegará hasta que Cupertino viva en su propio paquete —sin fecha comprometida—. Mientras tanto tienes tres vías: platform views nativos (fidelidad máxima, coste de rendimiento), reproducción en Flutter (multiplataforma, mantenimiento propio) o esperar con un diseño sobrio (riesgo mínimo). La peor decisión es una imitación a medias en toda la app; la mejor suele ser aislar lo nativo en las pocas superficies que importan y no atarte a "cuando Flutter lo saque".
En Dribba somos Partner oficial de Flutter de Google desde 2017 —la única agencia española en su directorio— y llevamos más de 300 proyectos enviando apps iOS y Android en producción para clientes como Rastreator, TravelPerk, CityXerpa e ISDIN. Si estás decidiendo cómo adaptar tu app a iOS 26 sin acumular trabajo que habrá que rehacer, hablemos.
