Independence Day : les design systems Cupertino et Material seront bientôt découplés du cœur du framework de Flutter

Vous l’avez entendu vous aussi, ce vent d’indépendance qui souffle de plus en plus fort sur la communauté Flutter ? Si vous n’êtes pas développeur, probablement pas. Et pourtant, cette annonce survenue il y a quelques mois du découplage imminent des widgets Material et Cupertino du core¹ de Flutter a fait grand bruit chez les experts du framework et pourrait bien avoir un impact notable sur les projets existants et futurs d’applications Flutter. Bien qu’il ne soit pas encore possible de mesurer pleinement les effets de ces évolutions car la migration ne sera complète que courant 2026, une chose est sûre selon nous : il va y avoir du changement ! On vous expose dans cet article nos théories pour l’avenir.

Développement cross-plateforme : petit rappel des fondamentaux

Dans le monde du développement mobile, le cross-plateforme, qui permet de créer deux applications à partir d’un seul code et d’une seule équipe, s’est imposé comme une composante majeure de l’écosystème. Nos différents UApp Observers le confirment : la tendance est massive, tous secteurs confondus. Cette maturité du marché du cross-plateforme se traduit par une certaine stabilité, où deux acteurs se partagent désormais l’essentiel du terrain : React Native et bien sûr Flutter². 

Pour autant la philosophie des deux acteurs est assez différente. Si on garde toujours un seul code pour deux applications, React Native exécute, lui, le même code en fonction de la plateforme en exploitant les composants UI natifs des OS, ce qui lui permet de coller un maximum aux possibilités offertes par les éditeurs d’iOS et Android.

Flutter, développé avec le langage Dart, va de son côté compiler le code pour chaque OS en s’appuyant sur des logiques de widgets UI internes au framework. Historiquement, Flutter intègre deux bibliothèques de composants : Cupertino, qui simule l’environnement iOS et Material, qui simule l’environnement Android.

Jusqu’ici, ces deux design systems “simulés” étaient intégrés par défaut dans le cœur du framework, qu’on les utilise ou non. Cette logique, bien que pertinente pour faciliter le travail d’import et rendre le processus plus accessible pour les nouveaux développeurs Flutter, a commencé à présenter quelques limites. Les développeurs étaient bien souvent contraints par le cadre rigide des design systems Material et Cupertino et les possibilités de customisation de widgets restaient assez limitées, ou a minima plutôt floues car très dépendantes du cas rencontré. 

Par ailleurs, il devenait de plus en plus difficile pour Flutter de suivre le rythme des mises à jour fréquentes des interfaces des OS, qui évoluent chaque année et entraînent parfois de profonds changements, comme ce fut le cas récemment avec l’arrivée de Liquid Glass sur iOS 26 et de Material Design 3 Expressive sur Android 16. Conséquence pour les applications Flutter : des délais souvent trop longs entre l’annonce de nouveaux standards et leur intégration dans les design systems Material et Cupertino. En effet, Flutter préfère généralement jouer la carte de la stabilité et la maturité, ce qui accentue parfois l’écart avec les applications React Native, dont l’UI est directement alignée sur celle des plateformes.

Mais tout ça, c’était avant. 

Ce qui va changer avec le découplage de Material et Cupertino

En route vers la neutralité

D’ici fin 2026, Flutter va donc extraire ces deux bibliothèques pour en faire des packages indépendants et il sera aussi possible de créer ses propres packages de design. Le core du framework se recentrera, lui, sur son rôle premier (le moteur de rendu, le layout, la gestion des animations, les primitives graphiques…), renforçant réellement la philosophie de “single responsability” chère à la communauté Flutter. Un module = une seule responsabilité. 

Les design systems deviendront optionnels, activables / désactivables à la demande ou tout simplement remplaçables. Autrement dit, Flutter ne sera plus “Material ou Cupertino par défaut”, mais un framework plus neutre, une fondation sur laquelle chacun pourra bâtir son propre univers visuel.

Au nom de la modularité et de la performance

Le découplage sera sûrement aussi synonyme de plus de fluidité dans les processus de développement et de maintenance. En réduisant la dépendance aux mises à jour complètes du framework pour bénéficier des évolutions de Material et Cupertino, Flutter devrait pouvoir offrir plus de souplesse et faciliter (voire accélérer) le débugage lié des problèmes internes aux design systems. 

Par ailleurs, le fait de pouvoir désormais supprimer tous les widgets inutilisés pourrait contribuer à rendre les applications plus légères, plus rapides à charger, avec un code plus clair et donc plus performantes.

Vers l’infini et au-delà du design system

Mais si, finalement, les vrais gagnants de cette annonce étaient… les designers, qui, libérés des contraintes des OS, pourront repousser encore les curseurs créatifs ?

En effet, les marques vont a priori pouvoir, avec un peu plus de flexibilité qu’avant, choisir de concevoir leur propre langage visuel sans se limiter aux codes existants des plateformes. Dans un contexte où les applications cherchent à se différencier, notamment à travers des interfaces intelligentes et personnalisées alimentées par l’IA, cette nouvelle marge de manœuvre représente une belle opportunité.

Qu’est-ce qui a motivé ce changement chez Flutter ? 

En réalité, avec cette annonce, Flutter ne fait qu’accéder à une demande longtemps formulée par la communauté des développeurs. Si Flutter est censé être un framework open source par essence, dans les faits, Google gardait la mainmise sur le contenu et la gestion de ses librairies et certains développeurs avaient parfois l’impression de “se battre” contre le framework. Les voix s’étaient d’ailleurs multipliées sur GitHub et Reddit pour réclamer plus d’ouverture, d’autant plus depuis la menace du lancement de Flock³, un fork de Flutter présenté comme “enfin véritablement open source”. 

En retirant Cupertino et Material du core du framework, Google envoie donc un signal clair : Flutter entre dans l’ère de l’indépendance partagée. Indépendance des développeurs, qui ne seront plus contraints par les choix de Google. Indépendance des marques, libres de créer véritablement et plus facilement leur propre design system. Indépendance du framework lui-même, qui s’affranchit des codes des plateformes (mobiles notamment) pour devenir vraiment multiplateforme.

Flutter s’émancipe, sa communauté aussi. 

Quelles sont les prochaines étapes pour les projets d’applications Flutter ?

Annoncé il y a 6 mois, ce changement majeur induit un processus de migration long. Nous sommes actuellement, et ce jusqu’à la fin de l’année 2025, en phase de refactoring et de renforcement. Les phases de relocalisation des nouveaux packages et de suppression interviendront, elles, en 2026⁴ et ce n’est qu’à partir de ce moment-là qu’une action sera requise de la part des développeurs, qui devront réimporter uniquement les widgets qui leur sont nécessaires (thanks god l’IA devrait pouvoir accélérer tout cela !). À noter que Flutter promet une accessibilité simplifiée aux packages Cupertino et Material pour ceux qui continueront à les utiliser. 

En revanche, à date, difficile d’estimer la charge et les coûts que vont impliquer de créer des widgets complètement sur-mesure, ni même si cela changera fondamentalement la donne par rapport au débridage de composants pratiqués régulièrement par les développeurs Flutter actuellement. Selon nous, cela va représenter très certainement un investissement supérieur à court terme mais vite amorti du fait des économies pratiquées grâce à la fluidité de maintenance sur le long terme. 

Mais pour l’instant ce ne sont que des théories. On vous donne rendez-vous dans quelques mois pour la pratique et pour vous aiguiller dans vos projets d’apps, en cours ou à venir.

En résumé

	Ancienne approche : Material & Cupertino intégrés au core Flutter	Nouvelle approche : Design systems découplés du core Flutter
Structure du framework	Tout inclus dans le framework core de Flutter, avec material.dart et cupertino.dart livrés par défaut.	Chaque design system devient un package indépendant
Simplicité de démarrage	Très simple : un seul import, tout prêt à l’emploi.	Légèrement plus complexe : il faut choisir, développer et/ou importer les design systems nécessaires.
Poids de l’application	Poids initial plus élevé, car tout le framework embarque les deux design systems, même si un seul est utilisé.	Poids réduit : seules les dépendances nécessaires sont compilées. Idéal pour rendre les apps sur-mesure plus légères.
Cohérence du développement	Cohérence garantie entre tous les widgets du package core, avec une maintenance centralisée par l’équipe Flutter.	Risque de divergence ou de versioning asynchrone entre les différents packages si les autres packages ne font pas de migration
Flexibilité / extensibilité	Moins flexible, difficile à personnaliser	Très flexible : possibilité d’intégrer des design systems multiplateformes (Samsung One UI, Fluent de Microsoft…) ou de créer d’autres design systems sur-mesure en se libérant des contraintes (de problème potentiel d’accessibilité par exemple)
Mise à jour et maintenance	Les mises à jour du framework impliquent celles de Material et Cupertino qui imposent donc leur rythme de maintenance et génèrent de la dépendance.	Chaque design system peut évoluer à son propre rythme. Le core de Flutter devient plus stable et pérenne.
Vitesse de compilation	Légèrement plus lente : plus de code embarqué dans le core.	Potentiellement plus rapide, car la compilation ne concerne que les dépendances choisies.
Adoption par les développeurs débutants	Plus rassurante : tout est prêt à l’emploi.	Moins intuitive pour les nouveaux venus, qui doivent configurer leur propre design system
Interopérabilité multiplateforme	Bon support cross-platform, mais avec un fort biais “Material-first” induit par Google.	Plus neutre et ouverte : chaque plateforme ou marque peut avoir son propre design.

En apparence, ce découplage pourrait passer pour un simple nettoyage de code. En réalité, il marque le passage de Flutter à l’âge de la maturité. Le framework quitte son costume d’outil “Google-first” pour devenir une plateforme plus universelle. Un pari audacieux mais nécessaire. 

Besoin d’accompagnement dans votre projet d’application Flutter ? Contactez nos experts ! 

¹ Librairies d’origine compilant tous les fichiers inclus dans le framework Flutter.

² Des initiatives comme Compose Multiplatform, bien que prometteuses, restent encore marginales et peu implantées dans les projets en production.

³ Un ancien développeur de Google,
Matt Carroll, actif dans la communauté Flutter, a lancé l’idée d’un "fork" (copie) de Flutter afin d’échapper à l’influence de Google sur le framework.

⁴ Pour suivre le projet de découplage sur GitHub.