Material y Cupertino salen del core de Flutter: qué cambia para tu app y cómo planificar la migración

Desde Flutter 3.47 (canal estable, 12 de agosto de 2026), Material y Cupertino ya no viven dentro del SDK: son dos paquetes independientes en pub.dev —material_ui y cupertino_ui, ambos en versión 1.0— con su propio ciclo de releases semanal. Las librerías de diseño que aún quedan dentro del core se marcarán como deprecadas en la release estable de otoño (noviembre de 2026). Traducido a decisiones: tu equipo tiene una migración que planificar y una ventana concreta para hacerla sin prisas.

Este artículo explica qué ha cambiado exactamente, por qué el equipo de Flutter lo ha hecho, cómo migrar con el menor riesgo posible y —tan importante como lo anterior— cuándo conviene no correr.

Qué ha cambiado, en concreto

Hasta ahora, package:flutter/material.dart y package:flutter/cupertino.dart formaban parte del propio SDK. Actualizar los widgets de Material implicaba actualizar todo Flutter, y viceversa. Con el desacople:

  • material_ui y cupertino_ui son paquetes en pub.dev, versionados de forma independiente (1.0 en el momento del corte).
  • Cadencia semanal, frente a las releases trimestrales del SDK. Los arreglos de bugs y los nuevos componentes de diseño dejan de estar atados al calendario del framework.
  • El código de Material y Cupertino dentro de flutter/flutter está congelado desde el 7 de abril de 2026. El desarrollo continúa ahora en flutter/packages.
  • Deprecación formal de las librerías in-SDK en la estable de noviembre de 2026. "Deprecado" no es "eliminado": el código seguirá funcionando un tiempo, pero es una cuenta atrás explícita.

La idea de fondo: poder usar los últimos estilos de widgets de Material y Cupertino sin verte obligado a subir toda la versión del SDK. Es un cambio de empaquetado y de gobernanza, no una reescritura de tu UI.

Por qué lo han hecho (y por qué tiene sentido)

El acoplamiento entre framework y sistema de diseño tenía un coste real. Cada mejora en un botón de Material tenía que esperar al tren trimestral del SDK, y cada equipo que quería ese botón cargaba con todo lo demás que venía en esa versión —incluidos cambios de renderizado, de tooling o de plataforma que quizá no querías todavía.

Separarlos permite tres cosas sanas:

  1. Iterar el diseño más rápido sin tocar el motor del framework.
  2. Desacoplar riesgos: subir Material no te obliga a asumir un salto de SDK, que suele ser el cambio con más superficie de rotura.
  3. Abrir la puerta a sistemas de diseño alternativos tratados como ciudadanos de primera, en igualdad de condiciones que Material y Cupertino.

Es la misma lógica que aplicamos cuando diseñamos la arquitectura de dependencias de un proyecto: lo que cambia a ritmos distintos debería poder versionarse por separado. Aquí Flutter está haciendo, a nivel de framework, algo que ya recomendábamos a nivel de app.

Cómo migrar sin sustos

La buena noticia es que hay una migración asistida. El comando:

dart fix --apply --code=migrate_design_widgets

añade los paquetes a tu pubspec.yaml y reescribe los imports —por ejemplo, de package:flutter/cupertino.dart a package:cupertino_ui/cupertino_ui.dart—. Es una data-driven fix, es decir, un cambio mecánico y determinista, no una heurística que "adivina".

Nuestro flujo recomendado para hacerlo con red de seguridad:

  1. Rama aislada y árbol limpio. Nada de mezclar esta migración con features en curso.
  2. Fija el SDK en 3.47 antes de tocar los imports, para no perseguir dos cambios a la vez.
  3. Ejecuta el dart fix en modo dry-run primero (--dry-run) para revisar el alcance del diff antes de aplicarlo.
  4. Aplica, compila y pasa la suite completa —incluidos los golden tests de UI, que son los que detectan regresiones visuales sutiles.
  5. Revisa los imports manuales y las dependencias transitivas: paquetes de terceros que reexporten Material pueden necesitar su propia actualización.
  6. Congela versiones de material_ui / cupertino_ui en el pubspec.lock y decide conscientemente tu política de actualización: la cadencia semanal es una ventaja solo si no la sigues a ciegas.

En un proyecto de tamaño medio, la parte automatizada es cuestión de minutos. El tiempo real se va en la verificación visual y en el long tail de dependencias, no en reescribir imports.

Cuándo NO deberías migrar todavía

Aquí es donde conviene bajar el hype. Que se pueda migrar hoy no significa que debas hacerlo esta semana:

  • Si tu app está en plena release crítica, no metas una migración de sistema de diseño en el camino. Tienes hasta noviembre para la deprecación; úsalo.
  • Si dependes de paquetes de terceros que aún no soportan material_ui/cupertino_ui, migrar te dejaría con imports mixtos y potenciales conflictos. Espera a que tu cadena de dependencias esté lista.
  • Si no tienes golden tests ni una suite de UI decente, migra después de tenerlos. Sin ellos, no vas a saber si algo se rompió visualmente hasta que lo vea un usuario.
  • Si tu equipo no tiene ancho de banda para adoptar la cadencia semanal, plantéate una política de actualización mensual o trimestral: el desacople te da la opción, no la obligación.

La ventana hasta noviembre existe por algo. La decisión correcta para la mayoría de equipos no es "migrar ya" ni "ignorarlo", sino agendar la migración dentro de un sprint donde puedas verificarla bien.

Un apunte sobre Impeller

En la misma 3.47, Impeller pasa a ser el renderizador por defecto también en escritorio (macOS, Windows y Linux), completando el movimiento que ya venía en móvil. Impeller compila un conjunto fijo de shaders en tiempo de build en lugar de hacerlo dinámicamente en ejecución, lo que elimina el jank de compilación de shaders. Hay opción temporal de opt-out, pero se retirará en una release futura: como con el desacople de diseño, la dirección es clara y conviene planificar en consecuencia.

Qué haríamos nosotros

Si estuviéramos gestionando tu base de código Flutter, el plan sería sencillo: subir a 3.47 en una ventana controlada, ejecutar el dart fix en dry-run para dimensionar el trabajo, y agendar la migración de imports para antes de la deprecación de noviembre, no dejarla para el último trimestre. En paralelo, revisaríamos qué dependencias de terceros bloquean el cambio y definiríamos una política de actualización de material_ui/cupertino_ui acorde a la capacidad real del equipo.

Es exactamente el tipo de mantenimiento evolutivo silencioso que evita que un proyecto acumule deuda hasta que "actualizar Flutter" se convierte en un proyecto en sí mismo. En Dribba llevamos desde 2011 construyendo con Flutter —somos Flutter Partner oficial de Google desde 2017, la única agencia española en el directorio— y este tipo de decisiones de arquitectura de dependencias son parte del día a día en los proyectos que mantenemos para clientes como Rastreator, Dogfy Diet o Playfinder.

¿Tienes una app en Flutter y quieres planificar esta migración sin frenar tu roadmap? Hablemos.