Flutter saca Material y Cupertino del core: qué cambia en tu proyecto en 2026

Desde Flutter 3.44 (mayo de 2026), package:flutter/material.dart muestra un aviso de deprecación. No es un error tuyo: es el primer paso visible de una decisión de fondo del equipo de Flutter, sacar Material y Cupertino del SDK y publicarlos como paquetes independientes en pub.dev. Si tienes una app en producción, la pregunta práctica no es "¿me afecta?", sino "¿cuándo migro y cuánto cuesta?". Respuesta corta: el cambio es mayoritariamente mecánico, no urgente todavía, y conviene planificarlo ahora en lugar de descubrirlo en un upgrade forzado.

En este artículo explicamos qué se mueve exactamente, por qué, cómo es la ruta de migración y —fieles a nuestra costumbre— cuándo no deberías precipitarte.

Qué está cambiando exactamente

Hasta ahora, Material y Cupertino venían dentro del propio SDK de Flutter. Cada vez que actualizabas Flutter, actualizabas también los widgets de diseño, te interesara o no. A partir de 3.44 esa relación se rompe en tres fases:

• Fase 1 (finales de 2025): reforzar el núcleo. El objetivo es que la librería base de widgets (los widgets "raw", sin opinión de diseño) sea autosuficiente, de modo que Material y Cupertino se apoyen en ella sin estar fundidos con el SDK.
• Fase 2 (2026): la mudanza. Material y Cupertino se publican como paquetes en pub.dev. Las copias que viven dentro del SDK entran en una ventana larga de deprecación y se "congelan": no reciben funcionalidades nuevas mientras dura la migración.
• Fase 3 (finales de 2026 y más allá): la era independiente. Los sistemas de diseño se versionan y publican por su cuenta, con su propio ritmo, desacoplados de la versión del SDK de Flutter.

Según la documentación de la release 3.44, los nuevos paquetes se publican como material_ui y cupertino_ui en pub.dev. Conviene tomar los nombres con cautela: están dentro de una migración en curso y pueden afinarse en releases posteriores, así que fija la versión en tu pubspec.yaml y revisa las notas de cada actualización antes de adoptarlos a ciegas.

Por qué Google hace esto

No es un capricho de versionado. Hay tres motivaciones técnicas claras:

1. Cadencia de diseño desacoplada del SDK. Hoy, una mejora en un componente de Material tiene que esperar a la siguiente release de Flutter. Con paquetes independientes, Material y Cupertino pueden evolucionar a su ritmo, igual que cualquier otro paquete de pub.dev.
2. Un núcleo más limpio y agnóstico. Sacar la opinión de diseño del core abre la puerta a que florezcan sistemas de diseño alternativos (corporativos, propios, de terceros) en igualdad de condiciones, sin que Material sea "el de casa".
3. Menos acoplamiento en tu CI. Podrás recibir actualizaciones de Material en cuanto aterrizan en pub.dev, sin atarte a la versión del SDK de Dart que tengas en el pipeline.

Es la misma filosofía que ya viste en otras decisiones recientes del ecosistema: mover complejidad fuera del monolito del framework. Lo comentábamos al hablar de interop nativo sin platform channels y de qué cambia de verdad con Impeller en Android: el core se adelgaza y delega.

Cómo es la migración en la práctica

Para la inmensa mayoría de las apps, el cambio es una sustitución de imports. Pasas de esto:

// Antes (sigue funcionando en 3.44, pero deprecado)
import 'package:flutter/material.dart';

a esto:

// Después (nuevo hogar en pub.dev)
import 'package:material_ui/material_ui.dart';

Y declaras la dependencia explícitamente en tu pubspec.yaml:

dependencies:
  flutter:
    sdk: flutter
  material_ui: ^1.0.0
  cupertino_ui: ^1.0.0

El grueso del trabajo es buscar y reemplazar imports en todo el proyecto, algo que un script o el propio dart fix cubren bien. Lo que sí merece tu atención es lo que no es mecánico:

• Paquetes de terceros desactualizados. Si una dependencia importa internamente package:flutter/material.dart y no se ha actualizado, arrastrarás avisos de deprecación que no controlas. Audita tus dependencias antes de migrar.
• Tooling y linters propios. Reglas de análisis, generadores de código o plantillas internas que asumen la ruta antigua.
• Tests y golden files que importen widgets de diseño directamente.

Tabla rápida de decisión

Situación	Acción recomendada en 2026
App en producción, Flutter < 3.44	No hay prisa. Planifica la migración para tu próximo ciclo de upgrade.
App en 3.44 con avisos de deprecación	Migra los imports cuando toques esos módulos; no bloquees una release por ello.
Proyecto nuevo desde cero	Adopta los paquetes desde el principio y fija versiones.
Dependencias de terceros sin actualizar	Audita y, si hace falta, espera o sustituye antes de migrar a fondo.

Cuándo NO migrar todavía

Aquí va el matiz que muchos titulares se saltan: que aparezca un aviso de deprecación no significa que debas migrar mañana. La ventana de deprecación es larga y las copias en el SDK siguen funcionando. No tiene sentido:

• Abrir una rama de "gran migración" que toque miles de ficheros si tu app está estable y no vas a actualizar Flutter en breve.
• Migrar cuando tienes dependencias clave que aún no se han adaptado: heredarás sus avisos igualmente.
• Hacerlo en mitad de una entrega crítica solo por silenciar warnings.

La regla sana: migra de forma incremental, módulo a módulo, aprovechando el trabajo que ya ibas a tocar. Lo único urgente es dejar de añadir deuda: que el código nuevo use ya los paquetes correctos.

Qué significa para tu equipo y tu producto

Para un CTO o responsable de producto, el titular es tranquilizador: no es una rotura, es un desacoplamiento. Pero tiene implicaciones de planificación que conviene anticipar:

• Gestión de versiones más fina. Tendrás un eje más que versionar (Material/Cupertino aparte del SDK). Bien gestionado, es libertad; mal gestionado, es un pubspec.yaml que se descuadra.
• Oportunidad para tu design system. Si mantienes una capa de diseño propia sobre Material —algo habitual en apps de marca—, este es el momento de revisar esa frontera. Lo tratamos al hablar de state management en Flutter: cuanto más limpia sea la separación entre lógica, estado y presentación, más barato te sale cada uno de estos cambios estructurales.
• CI/CD. Revisa que tus pipelines fijen versiones y no tiren siempre de la última, para que la migración sea una decisión y no una sorpresa.

Conclusión

La salida de Material y Cupertino del core de Flutter es una buena noticia mal contada: suena a ruptura y en realidad es un desacoplamiento ordenado, con una ventana de deprecación generosa y una migración casi mecánica. Lo correcto en 2026 es no entrar en pánico, auditar tus dependencias, dejar de generar deuda con los imports antiguos y planificar la migración dentro de tu ciclo normal de upgrades. La urgencia es cero; la previsión, recomendable.

En Dribba somos Flutter Partner oficial de Google desde 2017 —la única agencia española en su directorio— y llevamos +300 proyectos a cuestas con equipo 100% senior in-house. Si tienes una app Flutter en producción y quieres planificar este tipo de migraciones sin frenar tu roadmap, hablemos.