Flutter 3.47: material_ui ve cupertino_ui Paketlerine Geçiş

Flutter 3.47, 12 Ağustos 2026'da yayınlandığında en dikkat çeken haber render motoru değil, SDK'nın kendi iskeletiydi: Material ve Cupertino tasarım kütüphaneleri artık yalnızca flutter/flutter'a bağlı değil — bu sürümde SDK'da durmaya devam ediyorlar, ama aynı zamanda material_ui ve cupertino_ui adıyla pub.dev üzerinde bağımsız 1.0 paketleri olarak da yayınlanıyor. Bu yazıda Flutter 3.47 material_ui geçiş rehberini adım adım işliyoruz: otomatik göç komutundan bilinen pubspec hatasına, MaterialUiCompatibilityBridge'in ne işe yaradığından Kasım'daki deprecation takvimine kadar her şeyi resmi kaynaklarla birlikte anlatıyoruz.

💡 Pro Tip: Göçe başlamadan önce flutter --version ile SDK'nın gerçekten 3.47 veya üstü olduğunu doğrula — dart fix --apply --code=migrate_design_widgets komutu daha eski sürümlerde tanınmaz.

İçindekiler

• 3.47 tek cümlede ne değiştirdi
• Neden Material/Cupertino SDK'dan ayrıldı
• Sürüm zaman çizelgesi
• Sıkça karışan noktalar
• dart fix --apply --code=migrate_design_widgets ile otomatik göç
• pubspec bug'ı ve manuel flutter pub add çözümü
• MaterialUiCompatibilityBridge
• flutter_localizations ayrışması (GlobalMaterialLocalizations.delegates)
• Kasım deprecation takvimi ve gerçek risk
• Eski ve yeni import yolları karşılaştırması
• Paket bakımcıysan: major release olarak yayınla
• Kontrol listesi
• Büyük projelerde adım adım göç stratejisi
• Impeller ve göç dışındaki 3.47 başlıkları
• Golden Test ve CI'da göçü doğrulama
• SSS
• Flutter 3.47'de material_ui paketi nedir?
• material_ui 1.0'a nasıl geçiş yapılır?
• Cupertino widget'ları SDK'dan çıkarılıyor mu?
• MaterialUiCompatibilityBridge ne işe yarar?
• flutter_localizations paketini pubspec'ten silmem gerekiyor mu?
• Göçü yapmazsam ne olur?
• Sonuç
• Kaynaklar

3.47 tek cümlede ne değiştirdi

Flutter 3.47, Material ve Cupertino tasarım kütüphanelerini çekirdek SDK'dan ayırıp material_ui ve cupertino_ui adıyla pub.dev'de bağımsız 1.0 paketlere dönüştürdü. Flutter ekibi bunu resmi blog yazısında "tasarım sistemlerini çekirdek SDK'dan kopararak büyük bir dönüm noktası" olarak tanımlıyor. Aynı sürümde Impeller, macOS, Windows ve Linux'ta varsayılan render motoru hâline geldi ve Flutter Widget Previews stabil sürüme geçti — ama bu yazının odağı paket ayrışması ve pratik göç adımları.

Pratikte bu, projendeki import 'package:flutter/material.dart'; satırlarının artık geçerliliğini yakın gelecekte kaybedeceği, yerine import 'package:material_ui/material_ui.dart'; gelmesi gerektiği anlamına geliyor. SDK içindeki eski kütüphaneler şu an için hâlâ çalışıyor; hiçbir şey aniden kırılmıyor. Ama ayrışma, "biletlerin artık ayrı bir kapıdan kesilmeye başladığı" bir dönüm noktası ve bu geçişi ne kadar erken tamamlarsan Kasım'daki resmi deprecation duyurusunu o kadar sakin karşılarsın.

Neden Material/Cupertino SDK'dan ayrıldı

Flutter ekibinin gerekçesi net: Material ve Cupertino kütüphaneleri çekirdek SDK içine gömülüyken, SDK'nın üç aylık stabil release döngüsüne mahkûm kalıyordu. Ekip, bu kütüphanelere yönelik katkıları Nisan 2026'da dondurarak ayrışmaya hazırlandığını ve artık sürümlerin haftalık olarak planlandığını açıkladı. Bağımsız paket olmak, bir buton bileşenindeki küçük bir düzeltmenin bir sonraki Flutter stabil sürümünü beklemeden, günler içinde pub.dev'e çıkabilmesi demek.

Bu aynı zamanda ekosistem katkısına açılma anlamına da geliyor: flutter/packages deposuna taşınan bu paketler, çekirdek SDK'ya kıyasla daha hafif bir katkı süreciyle geliştirilebiliyor. Senin için pratik sonucu şu: Material bileşenlerindeki hata düzeltmeleri ve küçük iyileştirmeler artık SDK sürüm numarasından bağımsız olarak, çok daha sık sana ulaşacak.

Sürüm zaman çizelgesi

Bu ayrışma bir gecede olmadı; Flutter ekibi, Material ve Cupertino kütüphanelerine yönelik doğrudan katkıları Nisan 2026'da dondurarak sürece hazırlandı. Dört aylık bir hazırlığın ardından her iki paket de 3.47 ile birlikte 1.0 sürümüne ulaştı. 15 Ağustos 2026 tarihinde (yani bu makalenin yayın tarihinde) her iki paketin de güncel sürümü 1.0.0; haftalık release temposu gereği küçük sürümlerin önümüzdeki haftalarda gelmesi bekleniyor.

Sıkça karışan noktalar

Bu geçişi ilk duyduğunda kafa karıştıran birkaç nokta var, onları baştan netleştirelim. Birincisi: material_ui ve cupertino_ui'ye geçmek, Flutter SDK'nı yükseltmekten farklı bir işlem — SDK'nı zaten 3.47'ye yükselttiysen, eski importlarla da çalışmaya devam edebilirsin; paket göçü ayrı, isteğe bağlı bir adım. İkincisi: material_ui paketi Material bileşenlerinin yalnızca bir alt kümesini değil, uygulama iskeleti, navigasyon, giriş bileşenleri, theming ve internationalization dahil eksiksiz bir Material 3 kataloğunu içeriyor — yani "bazı widget'lar eski pakette kalacak" gibi bir ara durum söz konusu değil; tek bir dosya içinde ya eski importu ya yeni paketi kullanırsın, proje genelinde ise göçü modül modül ilerletebilirsin (bkz. MaterialUiCompatibilityBridge). Üçüncüsü: cupertino_ui, Flutter'ın resmi iOS/macOS tasarım kütüphanesinin standalone hâli ve aynı mantıkla çalışıyor — CupertinoApp, CupertinoButton gibi tüm bileşenler burada.

Bir diğer karışıklık noktası da versiyon numaraları etrafında. Bu paketler pub.dev'de kendi sürüm numaralarıyla ilerliyor ve Flutter SDK'nın sürüm numarasından bağımsız; yani projendeki pubspec.yaml'da material_ui: ^1.0.0 gibi bir bağımlılık göreceksin, bu Flutter SDK sürümünle karıştırılmamalı. Haftalık release temposu sayesinde bu sürüm numarası, Flutter SDK'nın üç ayda bir değişen sürümünden çok daha sık ilerleyecek — bu da paket bağımlılıklarını güncel tutmayı, eskisinden daha rutin bir bakım işine dönüştürüyor.

dart fix --apply --code=migrate_design_widgets ile otomatik göç

Göçün merkezinde tek bir komut var. Proje kök dizininde şunu çalıştır:

1dart fix --apply --code=migrate_design_widgets

Bu komut, projendeki package:flutter/material.dart ve package:flutter/cupertino.dart importlarını sırasıyla package:material_ui/material_ui.dart ve package:cupertino_ui/cupertino_ui.dart ile değiştirir; aynı zamanda pubspec.yaml'a gerekli bağımlılıkları eklemeye çalışır. Küçük ve orta ölçekli projelerde bu tek komut, elle import değiştirme işini ortadan kaldırır. Çalıştırmadan önce git durumunun temiz olduğundan emin ol — dart fix --apply diff'i doğrudan dosyalarına uygular, geri almak için versiyon kontrolüne ihtiyacın olacak.

pubspec bug'ı ve manuel flutter pub add çözümü

Flutter ekibi, göç aracının pubspec.yaml'ı güncellerken bilinen erken bir hatası olduğunu resmi blog yazısında açıkça belirtiyor. Bu durumda dart fix --apply importları değiştirir ama pubspec'e yeni bağımlılıkları eklemeyi başaramayabilir; sonuç olarak proje derlenmez.

Çözüm iki adımlık, resmi olarak önerilen bir manuel müdahale:

1flutter pub add material_ui
2flutter pub add cupertino_ui  # yalnızca Cupertino kullanıyorsan
3dart fix --apply

Önce eksik paketleri elle pubspec.yaml'a eklersin, sonra dart fix --apply'ı (bu kez --code bayrağı olmadan) tekrar çalıştırarak kalan import düzeltmelerinin tamamlanmasını sağlarsın. Bu sırayı takip etmek, "importlar değişti ama paket pubspec'te yok" tipi derleme hatalarının neredeyse tamamını çözer.

MaterialUiCompatibilityBridge

Gerçek projelerde göç nadiren tek seferde ve anlık olur: uygulaman material_ui'ye geçmiş olabilir ama hâlâ eski package:flutter/material.dart importunu kullanan bir üçüncü parti paket bağımlılığın varsa, iki farklı ThemeData/MaterialLocalizations ağacı çakışabilir. Bunun için Flutter ekibi MaterialUiCompatibilityBridge'i sunuyor: uygulamanın, bazı paket bağımlılıkları hâlâ eski çekirdek SDK importlarını kullanıyor olsa bile standalone paketlere hemen geçmesine izin veren bir köprü katmanı.

Pratikte bunu MaterialApp.builder içine sararak ya da yalnızca ilgili alt ağaca uygulayarak kullanırsın:

1MaterialApp(
2  builder: (context, child) {
3    return MaterialUiCompatibilityBridge(
4      child: child!,
5    );
6  },
7  home: const HomeScreen(),
8)

Bu, kalıcı bir mimari parça olarak düşünülmemeli — geçici bir uyumluluk katmanı. Tüm bağımlılıkların material_ui/cupertino_ui'ye geçtiğini doğruladığında köprüyü kaldırman, gereksiz bir soyutlama katmanını projede bırakmamak için mantıklı.

flutter_localizations ayrışması (GlobalMaterialLocalizations.delegates)

Burada önemli bir nüansı netleştirmek gerekiyor: flutter_localizations paketi ortadan kalkmadı ve deprecated olmadı. Değişen şey, Material ve Cupertino widget'larına ait lokalizasyon delegelerinin ve çevrilmiş metinlerin flutter_localizations içinin yanı sıra, artık doğrudan material_ui ve cupertino_ui paketlerinin kendi içinde de taşınıyor olması. Yani flutter_localizations bağımlılığı, tamamen migrate olmuş bir projede artık zorunlu değil — pubspec'ten çıkarılabilir hâle geliyor, ama çıkarman şart değil.

Yeni kurulum, eskiden üç ayrı delege listelemeyi gerektiren localizationsDelegates satırını tek bir referansa indiriyor:

1MaterialApp(
2  localizationsDelegates: GlobalMaterialLocalizations.delegates,
3  supportedLocales: const [
4    Locale('tr'),
5    Locale('en'),
6  ],
7  home: const HomeScreen(),
8)

GlobalMaterialLocalizations.delegates artık gerekli tüm delegeleri (Material, Widgets, Cupertino dahil) tek satırda sağlıyor. Cupertino tarafında ihtiyaç varsa aynı desen GlobalCupertinoLocalizations üzerinden de geçerli. Bu değişiklik hem Flutter'ın resmi blog yazısında hem de material_ui paketinin pub.dev README'sinde birebir aynı kod örneğiyle doğrulanıyor.

Kasım deprecation takvimi ve gerçek risk

SDK içindeki orijinal Material ve Cupertino kütüphaneleri, önümüzdeki Kasım ayındaki "Fall stable" sürümünde resmi olarak deprecation sürecine girecek şekilde planlanıyor. Bunun anlamı şu: 15 Ağustos 2026 itibarıyla eski package:flutter/material.dart importları hâlâ tamamen çalışır durumda, hiçbir uyarı vermez, projen kırılmaz. Gerçek risk aciliyette değil, ihmalde — Kasım'a kadar göçü tamamlamayan projeler, deprecation duyurusuyla birlikte derleyici uyarılarıyla karşılaşacak ve bir sonraki adımda (kesin kaldırma tarihi resmi kaynaklarda henüz netleştirilmedi) SDK içi kütüphanelerin tamamen kaldırılması senaryosuyla yüzleşecek.

Bu yüzden "acele etmene gerek yok ama ertelemene de gerek yok" tavsiyesi burada tam yerine oturuyor: göç mekanik ve otomatik komutla yapılabilir durumdayken, riski Kasım'a bırakmanın hiçbir faydası yok.

Eski ve yeni import yolları karşılaştırması

Paket bakımcıysan: major release olarak yayınla

Kendi pub.dev paketini bakımını yapıyorsan bu geçiş senin için farklı bir sorumluluk taşıyor. Flutter ekibinin resmi tavsiyesi net: ekosistemdeki bir paketi bu standalone paketlere geçiriyorsan, bu hamleyi semver açısından major sürüm olarak ele almalısın. Sebep basit — paketinin public API yüzeyinde MaterialApp, ThemeData ya da widget tipleri varsa, bu tipler artık farklı bir pakette tanımlı; paketini kullanan projeler için bu potansiyel olarak kırıcı bir değişiklik.

Kendi paketini major sürüm olarak etiketlemek, kullanıcılarının MaterialUiCompatibilityBridge ihtiyacı olup olmadığını değerlendirmesine de zaman tanır. Changelog'unda hangi importların değiştiğini ve minimum gereken material_ui/cupertino_ui sürümünü açıkça belirtmen, downstream projelerin sürpriz derleme hatalarıyla karşılaşmasını önler.

Kontrol listesi

Büyük projelerde adım adım göç stratejisi

Küçük bir demo uygulamada dart fix --apply --code=migrate_design_widgets komutunu çalıştırıp beş dakikada bitirebilirsin. Ama yüzlerce dosyalı, çok sayıda özellik ekibinin çalıştığı bir monorepo'da tek seferlik dev bir diff, code review'u anlamsız hâle getirir ve merge çakışması riskini büyütür. Bu tip projelerde göçü paket/modül sınırlarına göre bölmek daha güvenli: önce göçün ana dart fix komutunu yalnızca bir feature modülünde (örneğin lib/features/onboarding/) çalıştır, testleri koştur, PR'ı birleştir; sonra sıradaki modüle geç.

Göç öncesi ve sonrası bir widget dosyasının importlarını karşılaştırmak faydalı:

1// Göç öncesi
2import 'package:flutter/material.dart';
3import 'package:flutter/cupertino.dart';
4 
5class OnboardingScreen extends StatelessWidget {
6  const OnboardingScreen({super.key});
7 
8  @override
9  Widget build(BuildContext context) {
10    return Scaffold(
11      appBar: AppBar(title: const Text('Hoş geldin')),
12      body: const Center(child: Text('Başlayalım')),
13    );
14  }
15}

1// Göç sonrası
2import 'package:material_ui/material_ui.dart';
3import 'package:cupertino_ui/cupertino_ui.dart';
4 
5class OnboardingScreen extends StatelessWidget {
6  const OnboardingScreen({super.key});
7 
8  @override
9  Widget build(BuildContext context) {
10    return Scaffold(
11      appBar: AppBar(title: const Text('Hoş geldin')),
12      body: const Center(child: Text('Başlayalım')),
13    );
14  }
15}

Widget'ın gövdesi tek bir karakter değişmedi — değişen yalnızca importlar. Bu, göçün neden düşük riskli sayıldığını da açıklıyor: Scaffold, AppBar, Text gibi API'lerin davranışı material_ui içinde aynı kalıyor, sadece paketin adresi değişiyor.

Göçün modül modül ilerlediği bir projede, hangi dosyaların hâlâ eski importu kullandığını hızlıca listelemek için basit bir grep de işini görür:

1grep -rl "package:flutter/material.dart" lib/ | wc -l
2grep -rl "package:flutter/cupertino.dart" lib/ | wc -l

Bu iki komutun çıktısı sıfıra düştüğünde, modülün göçü tamamlanmış demektir — CI pipeline'ına bir adım olarak eklemek, bir sonraki PR'da yanlışlıkla eski importun geri gelmesini de engeller.

Impeller ve göç dışındaki 3.47 başlıkları

Bu ayrışma tek başlık değil. Aynı sürümde Impeller, macOS, Windows ve Linux'ta varsayılan render motoru hâline geldi — daha önce yalnızca iOS ve Android'de varsayılandı. Masaüstü hedefleyen projelerde bu, render pipeline'ının değişmesi anlamına geliyor ve renderer davranışıyla ilgili gözlemlediğin farklılıkları Impeller render motoru rehberimiz yazımızda daha ayrıntılı ele aldık. Aynı sürümde Flutter Widget Previews de stabil sürüme geçti; bu ikisi material_ui/cupertino_ui ayrışmasından bağımsız gelişmeler ama aynı release notunda birlikte duyuruldu.

Göç sürecinde mimari kararlarını gözden geçiriyorsan, katmanlı bir yapı bu tip SDK değişikliklerini izole etmeyi kolaylaştırır — bu konuyu Flutter Clean Architecture rehberi'nde işledik. Performans tarafında dikkatini çekmesi gereken bir diğer nokta, widget ağacındaki paket sınırlarının değişmesinin profil çıktılarını nasıl etkileyebileceği; bunu Flutter performans optimizasyonu yazımızla birlikte okuyabilirsin.

Golden Test ve CI'da göçü doğrulama

Göçü tamamladıktan sonra widget testlerinin hâlâ geçtiğinden emin olmak, importların değiştiği ama davranışın değişmediğini kanıtlamanın en güvenilir yolu. Test kurulumunu ve golden test stratejini gözden geçirmek istiyorsan Flutter test rehberi unit, widget ve integration test katmanlarını ayrıntılı işliyor. State management katmanında material_ui widget'larına bağımlı UI kodun varsa, Flutter Riverpod ile state management rehberimizdeki katman ayrımı, bu tip SDK değişikliklerinin state mantığına sızmasını önlemek için faydalı bir referans.

CI pipeline'ında flutter analyze çalıştırman, geçişten sonra unutulmuş eski importları erken yakalamanın en ucuz yolu. Firebase entegrasyonu olan projelerde ek bir bağımlılık zinciri oluşabileceğinden, Flutter Firebase entegrasyonu rehberimizdeki paket sürüm uyumluluğu notlarını da göz önünde bulundurmakta fayda var.

SSS

Flutter 3.47'de material_ui paketi nedir?

material_ui, önceden Flutter SDK'sına gömülü olan package:flutter/material.dart kütüphanesinin flutter/packages deposuna taşınmış, pub.dev üzerinde bağımsız sürümlenen hâlidir. Flutter 3.47 ile (12 Ağustos 2026) 1.0 sürümüne ulaştı ve artık SDK'nın üç aylık release döngüsünden bağımsız, haftalık olarak güncellenebiliyor.

material_ui 1.0'a nasıl geçiş yapılır?

Terminalde dart fix --apply --code=migrate_design_widgets komutu çalıştırılır; bu komut package:flutter/material.dart ve package:flutter/cupertino.dart importlarını yeni paketlerle değiştirir ve pubspec.yaml'a bağımlılıkları eklemeye çalışır. pubspec güncellemesi başarısız olursa flutter pub add material_ui (ve gerekiyorsa cupertino_ui) elle çalıştırılıp dart fix --apply tekrarlanmalı.

Cupertino widget'ları SDK'dan çıkarılıyor mu?

Şimdilik hayır — geçiş opsiyonel ve SDK içindeki eski kütüphaneler Flutter 3.47'de hâlâ tam olarak çalışıyor. Yalnızca önümüzdeki Kasım'daki "Fall stable" sürümünde resmi olarak deprecation sürecine girmeleri planlanıyor; kesin kaldırma tarihi bu kaynaklarda netleştirilmedi, bu nokta hâlâ belirsiz.

MaterialUiCompatibilityBridge ne işe yarar?

Projenin bir kısmı material_ui'ye geçmişken hâlâ eski package:flutter/material.dart'a bağımlı üçüncü parti paketler varsa, MaterialUiCompatibilityBridge bu iki widget ağacının ThemeData ve MaterialLocalizations'ı paylaşarak aynı anda çalışmasını sağlayan bir geçiş katmanı. MaterialApp.builder içine sarılarak ya da yalnızca ilgili alt ağaca uygulanarak kullanılır; tüm bağımlılıklar migrate olduğunda kaldırılması önerilir.

flutter_localizations paketini pubspec'ten silmem gerekiyor mu?

Hayır, zorunlu değil. flutter_localizations deprecated olmadı; yalnızca Material ve Cupertino'ya özgü lokalizasyon delegeleri artık material_ui/cupertino_ui içinde de bulunuyor. Tamamen migrate olmuş bir projede paketi kaldırabilirsin ama bırakman projeyi bozmaz — delegeleri material_ui/cupertino_ui üzerinden aldığın sürece.

Göçü yapmazsam ne olur?

15 Ağustos 2026 itibarıyla hiçbir şey kırılmaz; eski importlar çalışmaya devam ediyor. Ancak Kasım'daki resmi deprecation duyurusundan sonra derleyici uyarılarıyla karşılaşman ve ileride SDK içi kütüphanelerin kaldırılma ihtimaliyle plansız bir göçe zorlanman olası — bu yüzden göçü şimdiden mekanik adımlarla tamamlamak daha güvenli.

Sonuç

Flutter 3.47'nin material_ui/cupertino_ui ayrışması, çoğu proje için tek komutla başlayan ama dikkatli doğrulama isteyen bir göç. dart fix --apply --code=migrate_design_widgets ile başla, pubspec bug'ına karşı flutter pub add yedeğini elde tut, karışık bağımlılık ağaçlarında MaterialUiCompatibilityBridge'e güven ve GlobalMaterialLocalizations.delegates ile lokalizasyon kurulumunu sadeleştir. Render motoru tarafındaki paralel değişiklikleri Impeller render motoru rehberimiz yazımızda, mimari hazırlığı Flutter Clean Architecture rehberi'nde, test doğrulamasını Flutter test rehberi'nde bulabilirsin. Kasım'daki deprecation takvimi net bir tarih vermiyor ama baskı yaratıyor — göçü şimdi, kontrollü biçimde yapmak, ileride acele bir göçten çok daha ucuza gelecek.

Kaynaklar

• What's new in Flutter 3.47 — The Flutter Blog — resmi duyuru: material_ui/cupertino_ui 1.0, göç komutu, deprecation takvimi
• material_ui | Flutter package — pub.dev — resmi paket sayfası, README ve kod örnekleri
• cupertino_ui | Flutter package — pub.dev — resmi Cupertino tasarım kütüphanesi paketi
• How to Work with Material and Cupertino Decoupling in Flutter — freeCodeCamp — adım adım göç handbook'u
• flutter/flutter Issue #188757 — flutter_localizations with material_ui/cupertino_ui — 1.0 öncesi lokalizasyon uyumsuzluğu tartışması (15 Temmuz 2026'da kapandı)
• Flutter 3.47: Material and Cupertino Become Standalone Packages — daily.dev — özet haber kaynağı
• Flutter 3.47 Upgrade Readiness Checklist — Dopebase — üçüncü parti uyumluluk kontrol listesi