.NET MAUI 10: XAML Source Generator ve SafeArea Rehberi

.NET MAUI 10, 11 Kasım 2025'te .NET 10 ile birlikte genel kullanıma (GA) sunuldu ve iOS, Android, Windows ile macOS'u tek codebase'ten hedefleyen geliştiriciler için üç önemli değişiklik getirdi: derleme zamanında çalışan yeni bir XAML source generator, genişletilmiş bir SafeAreaEdges API'si ve .NET Aspire servis şablonu entegrasyonu. Bu yazıda .NET MAUI 10 XAML source generator SafeArea ikilisini resmi Microsoft dokümantasyonundan aktarıyorum ve Xamarin.Forms'tan ya da eski MAUI projelerinden geçiş yapan ekipler için pratik bir kontrol listesi çıkarıyorum.

💡 Pro Tip: MauiXamlInflator değerini SourceGen yapmadan önce projede RC1 öncesinden kalma manuel source-generation etkinleştirme kodu varsa onu kaldır — dokümantasyon bu kodun artık kaldırılabileceğini söylüyor.

İçindekiler

• .NET MAUI 10 ile Ne Değişti: Tek Tablo
• GA ve Destek Takvimi
• Neden Şimdi Önemli
• XAML Source Generator: Derleme Zamanında Tip Güvenliği
• RC1 Öncesi Koddan Temizlik
• Eski Runtime Inflator ile Karşılaştırma
• SafeArea API'si: Ekran Kenarları ve Klavye
• Hangi Kontroller SafeAreaEdges Destekliyor
• Border ile Kombine Kullanım Örneği
• .NET Aspire Servis Şablonu Entegrasyonu
• Xamarin.Forms ve Eski MAUI Projelerinden Geçiş Kontrol Listesi
• Eski API → Yeni API Eşleştirme Tablosu
• Diagnostics ve Layout Performans Metrikleri
• Diğer Notlar: Global Namespace, İkincil Toolbar, MediaPicker
• Flutter ve React Native'e Göre .NET MAUI 10 Nerede Duruyor
• Ekip Seçimini Neler Belirliyor
• SSS
• .NET MAUI 10'da neler yeni?
• MAUI XAML source generator nasıl açılır?
• MAUI'de ListView deprecate mi oldu?
• MAUI 10 ne zaman GA oldu?
• Xamarin.Forms projemi doğrudan MAUI 10'a mı taşımalıyım?
• XAML source generator derleme süresini gerçekten kısaltıyor mu?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

.NET MAUI 10 ile Ne Değişti: Tek Tablo

.NET MAUI 10, .NET 10'un bir parçası olarak GA'ya çıktı ve LTS (Uzun Süreli Destek) sürümü statüsünde. Aşağıdaki tablo, MAUI ekosistemini doğrudan ilgilendiren takvim ve destek bilgilerini resmi kaynaklardan özetliyor.

GA ve Destek Takvimi

Bu tablodan çıkan pratik sonuç şu: MAUI workload'unun destek penceresi ile .NET runtime'ının LTS penceresi ayrı politikalara bağlı. .NET MAUI 10'un desteği 11 Mayıs 2027'de bitiyor, .NET 10 runtime'ının LTS'i ise 10 Kasım 2028'e kadar sürüyor. Destek politikası sayfası kuralı şöyle koyuyor: "A major version of .NET MAUI receives support for a minimum of 6 months after a successor (the next major release) ships." Yani planını runtime takvimine göre değil, workload'un kendi takvimine göre yapmalısın.

Neden Şimdi Önemli

Eğer hâlâ Xamarin.Forms'ta ya da .NET MAUI'nin daha eski bir sürümünde bir proje çalıştırıyorsan, .NET MAUI 10'un LTS statüsü seni önemli bir karara zorluyor: MAUI 10'un destek penceresi 11 Mayıs 2027'de kapanıyor, yani geçişi ertelemenin maliyeti her geçen ay artıyor. Özellikle ListView gibi deprecated edilen kontrolleri hâlâ yoğun kullanan büyük bir codebase'in varsa, geçişi küçük parçalar halinde planlamak (önce deprecated API'leri temizlemek, sonra source generator'a geçmek) tek seferde büyük bir "big bang" migration yapmaktan daha az risklidir. Bu yazının geri kalanı da bu sırayı izliyor: önce derleme zamanı araçlarını (source generator), sonra runtime davranışını (SafeArea) sonra da geçiş kontrol listesini ele alıyorum.

XAML Source Generator: Derleme Zamanında Tip Güvenliği

.NET MAUI 10'daki en somut geliştirici deneyimi değişikliklerinden biri, XAML dosyalarının artık derleme zamanında (compile-time) işlenebilmesi. Resmi dokümantasyon bunu şöyle özetliyor: source generator "improves build performance and enables better tooling support" ve "creates strongly-typed code for your XAML files at compile time". Yani XAML'in çalışma zamanında (runtime) reflection ile "inflate" edilmesi yerine, derleyici sana doğrudan tip-güvenli C# kodu üretiyor.

Bunu projende açmak için tek satır yeterli:

1<PropertyGroup>
2  <MauiXamlInflator>SourceGen</MauiXamlInflator>
3</PropertyGroup>

Üretilen tipler, tooling entegrasyonu ve debug deneyimi için [Generated] attribute'u ile işaretleniyor — bu sayede IDE'nin ve debugger'ın hangi kodun elle yazıldığını, hangisinin üretildiğini ayırt etmesi kolaylaşıyor.

RC1 Öncesi Koddan Temizlik

Eğer projen .NET MAUI 10'un RC1 sürümünden önce başladıysa dikkat: dokümantasyon açıkça "Before RC1 enabling source generation was different... Any other code you have implemented to enable source generation can now be removed" diyor. Yani eski, elle yazılmış etkinleştirme kodun varsa bunları MauiXamlInflator satırıyla değiştirip temizleyebilirsin — dokümantasyon bu kodun artık kaldırılabileceğini söylüyor.

Not: dokümantasyonda somut bir performans yüzdesi (ms veya % cinsinden) paylaşılmıyor; yalnızca nitel bir "derleme performansını iyileştirir" ifadesi var. Kendi projende ölçmek istersen derleme süresini SourceGen açık ve kapalıyken iki ayrı temiz build ile karşılaştırabilirsin.

Eski Runtime Inflator ile Karşılaştırma

Aşağıdaki tablo, iki yaklaşımın dokümantasyonda tarif edilen davranış farkını özetliyor. Sayısal bir ölçüm değil, resmi metnin nitel karşılaştırmasıdır.

Bu tablo, projendeki hangi XAML hatalarının artık derleme aşamasında yakalanacağını tahmin etmene yardımcı olur: yanlış property adı, tip uyuşmazlığı gibi hatalar için artık uygulamayı çalıştırmana gerek kalmıyor.

SafeArea API'si: Ekran Kenarları ve Klavye

.NET MAUI 10, SafeAreaEdges API'sini genişletti. Enum değerleri şöyle: None = 0, SoftInput = 1, Container = 2, Default = 4, All = int.MaxValue. SoftInput değeri özellikle klavye açıldığında layout'un güvenli alanı nasıl ele alacağını kontrol ediyor.

1<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
2             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">
3  <Grid RowDefinitions="*,Auto"
4        SafeAreaEdges="Container, Container, Container, SoftInput">
5    <ScrollView Grid.Row="0">
6      <VerticalStackLayout Padding="20" Spacing="10">
7        <Label Text="Profil" FontSize="24" />
8        <Entry Placeholder="Ad" />
9        <Entry Placeholder="E-posta" />
10      </VerticalStackLayout>
11    </ScrollView>
12 
13    <Border Grid.Row="1"
14            BackgroundColor="LightGray"
15            Padding="20">
16      <HorizontalStackLayout Spacing="10">
17        <Entry Placeholder="Mesajınız" HorizontalOptions="Fill" />
18        <Button Text="Gönder" />
19      </HorizontalStackLayout>
20    </Border>
21  </Grid>
22</ContentPage>

İki ayrıntıya dikkat et. Birincisi, dokümantasyon SoftInput değerinin ScrollView üzerinde doğrudan çalışmadığını söylüyor: "SoftInput doesn't work directly on ScrollView because ScrollView manages its own content insets." Çözüm de aynı yerde: ScrollView'u bir Grid ya da VerticalStackLayout içine alıp SafeAreaEdges değerini saran konteynere vermek. İkincisi, virgüllü yazım flag birleştirme değil, kenar başına bir değer listesi; dokümantasyonun kendi anlatımıyla yukarıdaki örnek üst ve yanlarda Container, altta SoftInput istiyor.

Dokümantasyona göre SafeAreaEdges, Layout, ContentView, ContentPage, Border ve ScrollView üzerinde kullanılabiliyor. Ayrıca .NET MAUI 10'da iOS tarafında bilinen bir hata da düzeltildi: "Resolved issues with SafeArea management on iOS, including extra bottom space in ScrollView when using SafeAreaEdges" — yani SafeAreaEdges kullanan ScrollView'larda iOS'ta oluşan fazladan alt boşluk sorunu giderildi.

Hangi Kontroller SafeAreaEdges Destekliyor

• Layout: VerticalStackLayout, Grid gibi temel yerleşim konteynerleri
• ContentView: özel kullanıcı kontrollerinin taban sınıfı
• ContentPage: standart sayfa tipi
• Border: kenarlıklı içerik konteyneri
• ScrollView: kaydırılabilir içerik — klavye senaryolarında özel davranışı olan kontrol (SoftInput doğrudan işlemez)

Varsayılan değerler kontrol tipine göre değişiyor: ContentPage için None, Layout ve türevleri için Container, ContentView ile Border için None, ScrollView için Default. Android tarafında bu, .NET 10'un kırıcı değişikliği: .NET 9'da ContentPage Android'de varsayılan olarak Container'a benzer davranıyordu, .NET 10'da ise "ContentPage defaults to None (edge-to-edge), providing a more immersive experience by default". .NET 9 davranışını korumak istiyorsan ContentPage.SafeAreaEdges="Container" değerini açıkça vermen gerekiyor.

Border ile Kombine Kullanım Örneği

SafeAreaEdges'i Border üzerinde kullanmak, özellikle alt navigasyon barı gibi ekranın en altına yakın duran özel bileşenlerde işine yarar:

1<Border SafeAreaEdges="Container"
2        Stroke="Transparent"
3        StrokeThickness="0">
4  <Border.StrokeShape>
5    <RoundRectangle CornerRadius="16,16,0,0" />
6  </Border.StrokeShape>
7  <Grid Padding="16" ColumnDefinitions="*,*,*">
8    <Label Grid.Column="0" Text="Ana Sayfa" />
9    <Label Grid.Column="1" Text="Ara" />
10    <Label Grid.Column="2" Text="Profil" />
11  </Grid>
12</Border>

Dokümantasyon Container değerini şöyle tanımlıyor: konteyner güvenli alanlarına (sistem çubukları, çentik) saygı gösterir ama içeriğin klavyenin altına akmasına izin verir. Yani Border'ın iPhone'daki home indicator alanıyla çakışmasını engeller; klavye açıldığında içeriğin klavyenin üstünde kalmasını istiyorsan SoftInput değerine ihtiyacın var.

.NET Aspire Servis Şablonu Entegrasyonu

.NET MAUI 10 ile birlikte gelen bir diğer değişiklik, yeni proje şablonlarına .NET Aspire desteği eklenmesi. Resmi ifade şöyle: ".NET MAUI 10 includes a new project template that creates a .NET Aspire service defaults project for .NET MAUI." Bu, mobil/masaüstü uygulamanın backend servisleriyle birlikte tek bir Aspire orkestrasyonu altında geliştirilmesini kolaylaştırıyor — özellikle mikroservis tabanlı backend'e bağlanan MAUI uygulamaları için.

Bu değişikliğin pratikteki anlamı şu: daha önce bir MAUI uygulamasını ASP.NET Core tabanlı bir backend ile birlikte geliştirirken, iki projeyi (mobil client + backend) ayrı ayrı yapılandırman ve servis keşfi, logging, health check gibi ortak altyapı kodunu elle kurman gerekiyordu. Yeni proje şablonu, bu "service defaults" projesini MAUI tarafına da bağlayarak, Aspire'ın tek dashboard'undan hem mobil uygulamanın hem backend servislerinin çalışır durumunu izleyebilmeni sağlıyor. Dokümantasyona göre bağlantıyı kurmak için MauiProgram sınıfındaki CreateMauiApp metodunda, MauiAppBuilder nesnesi üzerinde tek bir çağrı yapman yeterli:

1builder.AddServiceDefaults();

AddServiceDefaults metodunun yaptıkları da tek tek sayılıyor: OpenTelemetry metrik ve trace yapılandırmasını kurmak, servis keşfi (service discovery) işlevselliğini eklemek ve HttpClient'ı servis keşfiyle çalışacak şekilde yapılandırmak.

Xamarin.Forms ve Eski MAUI Projelerinden Geçiş Kontrol Listesi

.NET MAUI 10'da birkaç API deprecated edildi. Eski bir Xamarin.Forms ya da önceki MAUI sürümü projesini taşıyorsan aşağıdaki listeyi kontrol listesi olarak kullanabilirsin:

• ListView ve Cell tabanlı kontroller: ListView, EntryCell, ImageCell, SwitchCell, TextCell ve ViewCell deprecated edildi; yerine CollectionView önerilir.
• Animasyon API'leri: FadeTo gibi eski animasyon metotları deprecated edildi, yerine Async sonekli karşılıkları (FadeToAsync vb.) geldi.
• MessagingCenter: .NET 10'da internal yapıldı, proje dışından artık erişilemiyor; yerine WeakReferenceMessenger kullanılması öneriliyor.
• CollectionView/CarouselView handler'ları: .NET MAUI 10'da bu iki kontrol için yeni handler'lar varsayılan hale geldi.

Animasyon API geçişi kodda şöyle görünüyor:

1// Önce (deprecated API)
2await profileImage.FadeTo(0, 250);
3 
4// Sonra (.NET MAUI 10)
5await profileImage.FadeToAsync(0, 250);

MessagingCenter geçişi ise şu şekilde:

1// MessagingCenter artık internal - proje dışından erişilemiyor
2// CommunityToolkit.Mvvm'deki WeakReferenceMessenger kullanılır
3WeakReferenceMessenger.Default.Send(new StatusChangedMessage(newStatus));

Bu değişikliklerin hiçbiri "önerilir" seviyesinde değil — deprecated işaretli API'ler ileride kaldırılabileceği için geçiş kontrol listesine mutlaka eklenmeli.

Eski API → Yeni API Eşleştirme Tablosu

Bu tabloyu bir migration ticket'ına dönüştürürken her satırı ayrı bir iş kalemi olarak ele almanı öneririm — özellikle ListView'dan CollectionView'a geçiş, veri şablonlarının (DataTemplate) yeniden yazılmasını gerektirdiği için tek başına önemli bir efor.

Diagnostics ve Layout Performans Metrikleri

.NET MAUI 10, layout ölçüm performansını gözlemlemek için yerleşik diagnostics/metrics isimleri sunuyor. Dokümantasyonda ve ilgili GitHub pull request'inde geçen metrik adları şöyle:

1// .NET MAUI 10 diagnostics metrik adları (yalnız isimlendirme; kod örneği değil)
2// maui.layout.measure_count
3// maui.layout.measure_duration (ns)
4// maui.layout.arrange_count
5// maui.layout.arrange_duration (ns)

Bu metrikler, Microsoft.Maui ActivitySource'u üzerinden standart .NET diagnostics altyapısına (System.Diagnostics.Metrics) bağlanıyor; yani mevcut OpenTelemetry tabanlı izleme araçlarınla toplayabilirsin.

Bu ölçüm/sayaç isimlerinin pratikteki değeri şurada: bir ekranın layout geçişinde beklenmedik yavaşlık yaşıyorsan, önce maui.layout.measure_count ve maui.layout.arrange_count sayaçlarının normalden yüksek olup olmadığına bakabilirsin. Yüksek measure_count, genelde iç içe geçmiş çok sayıda Grid/StackLayout kombinasyonunun tekrar tekrar ölçüldüğü anlamına gelir ve bu genelde layout ağacını basitleştirerek çözülür.

Diğer Notlar: Global Namespace, İkincil Toolbar, MediaPicker

• Global XML namespace: http://schemas.microsoft.com/dotnet/maui/global adında yeni bir xmlns, birden fazla namespace'i tek yerde toplamana izin veriyor.
• İkincil toolbar item'lar: iOS ve macOS artık iOS 13+ API'lerini kullanan, pull-down menü tasarımına sahip ikincil toolbar item'ları destekliyor.
• Modal'ı popover olarak gösterme: iOS ve Mac Catalyst için modal sayfayı popover şeklinde göstermeyi sağlayan platform-specific bir API eklendi.
• MediaPicker geliştirmeleri: EXIF verisi artık otomatik yönetiliyor; API çoklu dosya seçimini ve MaximumWidth/MaximumHeight ile doğrudan sıkıştırmayı destekliyor.

Bu dört madde tek tek küçük görünse de, birlikte ele alındığında .NET MAUI 10'un platform-specific detaylara (iOS toolbar tasarımı, EXIF metadata) giderek daha fazla önem verdiğini gösteriyor. Özellikle MediaPicker'daki MaximumWidth/MaximumHeight desteği, önceden manuel olarak resim sıkıştırma kütüphanesi eklemek zorunda kalan ekipler için doğrudan bir bağımlılık azaltma fırsatı.

Flutter ve React Native'e Göre .NET MAUI 10 Nerede Duruyor

.NET MAUI 10'un XAML source generator'ı, Flutter'ın derleme zamanında tip kontrolü yapan widget ağacına ve React Native'in yeni mimarisindeki (Fabric/TurboModules) derleme zamanı codegen adımlarına kavramsal olarak yakınlaşıyor: üçü de "çalışma zamanında reflection/interpret yerine derleme zamanında üret" yönünde ilerliyor. Kesin bir performans karşılaştırması ise her üç framework'ün aynı ölçüm metodolojisiyle test edilmesini gerektirir; kavramsal yakınlaşma tek başına bir hız iddiası değildir.

Cross-platform ekosistemi daha geniş açıdan değerlendirmek istersen, Flutter'ın kendi performans optimizasyonu pratiklerine ve Kotlin Multiplatform ile Compose Multiplatform'un production'daki durumuna bakan yazılarımıza göz atabilirsin; bu üç yaklaşımı (MAUI, KMP, Compose Multiplatform) yan yana koyduğunda hangi ekibin hangi trade-off'u kabul ettiğini daha net görürsün.

Ekip Seçimini Neler Belirliyor

Ben genelde bu tür bir kararı tek bir teknik özelliğe (source generator var mı, yok mu gibi) indirgemeyi tercih etmiyorum. Pratikte ekibin mevcut yetkinliği belirleyici oluyor: ekip zaten C#/.NET backend'i biliyorsa MAUI'nin öğrenme eğrisi düşük kalıyor; ekip Dart'a veya TypeScript'e daha yakınsa Flutter ya da React Native daha doğal bir seçim oluyor. .NET MAUI 10'un bu yazıda anlattığım değişiklikleri (source generator, SafeArea, deprecation temizliği) bir "üstünlük" iddiası değil, ekosistemin olgunlaşmaya devam ettiğinin bir göstergesi olarak okumak daha doğru — üç framework de kendi hızında derleme zamanı araçlarına yatırım yapıyor.

SSS

.NET MAUI 10'da neler yeni?

.NET MAUI 10 (GA: 11 Kasım 2025), katman performansı için yerleşik diagnostics/metrics desteği, XAML için derleme zamanı çalışan bir source generator (MauiXamlInflator=SourceGen), genişletilmiş SafeAreaEdges API'si, iOS/macOS'ta ikincil toolbar item'lar ve .NET Aspire servis şablonu entegrasyonu getirdi. Aynı zamanda ListView ve ilgili Cell tipleri deprecated edildi.

MAUI XAML source generator nasıl açılır?

Proje dosyana (.csproj) bir PropertyGroup içine <MauiXamlInflator>SourceGen</MauiXamlInflator> eklemen yeterli. Eğer projende RC1 öncesinden kalma manuel source-generation kodu varsa, bu satırı eklerken o eski kodu kaldırman gerekiyor.

MAUI'de ListView deprecate mi oldu?

Evet. .NET MAUI 10'da ListView, EntryCell, ImageCell, SwitchCell, TextCell ve ViewCell deprecated edildi; yerine CollectionView kullanılması öneriliyor.

MAUI 10 ne zaman GA oldu?

.NET MAUI 10, 11 Kasım 2025'te .NET 10 ile birlikte genel kullanıma sunuldu ve LTS statüsünde (birincil kaynak: Microsoft .NET Blog).

Xamarin.Forms projemi doğrudan MAUI 10'a mı taşımalıyım?

Daha kontrollü yol, mevcut projeni önce bir önceki MAUI sürümünün son servicing seviyesine taşımak, sonra MAUI 10'a geçmek. .NET MAUI 10'a özgü olarak temizlemen gerekenler ise ListView ile Cell tipleri, eski animasyon metotları ve MessagingCenter kullanımı; bunlar dokümantasyonda deprecated ya da internal olarak işaretlendi.

XAML source generator derleme süresini gerçekten kısaltıyor mu?

Microsoft'un resmi dokümantasyonu bu konuda yalnızca nitel bir ifade kullanıyor: "improves build performance and enables better tooling support." Somut bir ms veya yüzde rakamı paylaşılmamış. Bu yüzden kendi projen için kesin bir sayı söyleyemem — güvenilir tek yöntem, MauiXamlInflator değerini açıp kapatarak aynı projede iki ayrı temiz build süresi ölçmek.

Güncelleme (Eylül 2026)

Bu yazının ilk yayınından bu yana MAUI'nin kendisinde büyük bir özellik değişikliği olmadı — resmi destek politikası sayfası "Minor updates for .NET MAUI aren't planned at this time" diyor, yani sadece servicing patch'ler geliyor (destek politikası sayfasının listelediği son patch: 10.0.101, 7 Eylül 2026). Öte yandan NuGet paket akışında Microsoft.Maui.Controls için .NET 11 hattına ait 11.0.0-rc.1 sürümünün paketlendiğini görebiliyorsun (NuGet flatcontainer kaydında 11.0.0-rc.1.26451.6 sürüm etiketi mevcut). Bu, .NET 11'in RC aşamasına girdiğinin bir göstergesi. Destek tarafında ise politika sayfası .NET MAUI 10 için destek bitişini 11 Mayıs 2027 olarak veriyor.

Sonuç

.NET MAUI 10, XAML source generator ve genişletilmiş SafeAreaEdges API'siyle geliştirici deneyimini derleme zamanına doğru kaydırıyor; bu da Flutter'ın compile-time yaklaşımına kavramsal olarak yaklaştığı anlamına geliyor. Eski bir Xamarin.Forms ya da MAUI projesini taşıyorsan önce deprecated API listesini (ListView, animasyon metotları, MessagingCenter) kontrol et, sonra MauiXamlInflator=SourceGen satırını ekleyip eski etkinleştirme kodunu temizle.

Cross-platform kararını daha geniş bağlamda değerlendirmek istersen Flutter'ın SwiftUI karşısındaki 60 bin satırlık production karşılaştırmasına, Kotlin Multiplatform'un production vaka çalışmasına, Compose Multiplatform'un Android/iOS production deneyimine ve React Native'in yeni mimarisi Fabric/TurboModules yazımıza göz atabilirsin. Flutter tarafında performans optimizasyonu pratiklerini merak edenler için de Flutter performans optimizasyonu rehberimiz faydalı olacaktır.

Kaynaklar

• Announcing .NET 10 — .NET 10'un GA duyurusu, yayın tarihi ve LTS statüsü.
• .NET MAUI 10 — What's new — XAML source generator, SafeAreaEdges, deprecation listesi ve diagnostics metrikleri.
• .NET MAUI destek politikası — GA tarihi, minör güncelleme planı ve patch geçmişi.
• .NET 10 RC1 release notes — MAUI — RC1'de eklenen diagnostics/metrics altyapısı ve Compressed layout deprecation'ı.
• NuGet — Microsoft.Maui.Controls sürüm kaydı — 10.0.0 GA paketi ve 11.0.0-rc.1 sürüm kanıtı.