.NET MAUI Artık CoreCLR’da: Mono Devri Kapanıyor

Açık konuşayım: Bu haberi ilk duyduğumda biraz afalladım. Çünkü Xamarin günlerinden beri Mono ile epey şey yaşadık — debug saatleri, GC sancıları, iOS AOT’nın garip sürprizleri — şimdi birden “tamam, artık CoreCLR’a geçiyoruz” denince insan ister istemez durup bakıyor. Sonra düşündüm… aslında bu, yıllardır kapıda bekleyen bir değişimdi.

.NET 11 Preview 4 ile birlikte Microsoft,.NET MAUI uygulamalarının Android, iOS ve Maç Catalyst tarafında varsayılan runtime’ını CoreCLR yaptı. Yani mobil uygulamanız artık ASP.NET Core API’nizin, Azure Functions’ınızın ve production’da milyonlarca isteği taşıyan aynı runtime üzerinde koşuyor. Tek çatı altında toplama diyelim, başka da lafı yok.

Mono’ya Veda — Ama Hakkını Vererek

Bu konuya girmeden önce bir saniye durmak lazım. Çünkü Mono olmasaydı, bugün bu yazıyı yazıyor olmazdık.

Miguel de Icaza 2001’de Mono’yu başlattığında hedefi.NET’i Linux’a taşımaktı. Çok daha mütevazı bir plan yani. Ama iş büyüdü, dağıldı, sonra yeniden şekillendi; 2009’da MonoTouch ile C# iPhone’a girdi, MonoDroid ile Android’e geçti, Xamarin doğdu, Microsoft Xamarin’i 2016’da satın aldı ve sonunda.NET MAUI’ye uzanan yol açıldı. Siz ne dersiniz? Kısacası hikâye düz gitmedi, biraz zikzak çizdi.

İşin ilginç yani şu: Mono’nün etkisi sadece Microsoft tarafında kalmadı. Unity’nın scripting runtime’ı Mono üzerine kurulu. Milyonlarca oyun onun üstünde dönüyor. Godot’nün C# backend’i, Avalonia, Uno Platform, MonoGame… Liste uzayıp gidiyor. Yani Mono sadece “mobil için.NET” değildi; daha çok “her yere sızan.NET” gibiydi (ben de ilk duyduğumda şaşırmıştım)

Mono sadece mobilde.NET’i mümkün kılmadı..NET’in her yere gidebileceğini gösterdi. CoreCLR’ın MAUI’de varsayılan olması bu hikâyenin sonu değil, yeni bir sayfası.

Şunu da ekleyeyim: Unity de kendi CoreCLR geçişini başlattı. Yani bu hareket yalnızca MAUI meselesi değil; tüm.NET ortaminde yavaş ama net bir birleşme var.

İşte tam da bu noktada devreye giriyor.

Peki Ne Değişti?

Konuya teknik girersek:.NET 11 hedefleyen bir MAUI projesi build ettiğinizde, Android, iOS. Maç Catalyst için hem Release hem de Debug build’lerde varsayılan runtime artık CoreCLR oluyor. tvOS da bu gruba katıldı bu arada.

Birkaç noktayı netleştirelim:

• Android, iOS, Maç Catalyst ve tvOS — hepsi CoreCLR’a taşınıyor (bence en önemlisi)
• Blazor WebAssembly etkilenmiyor — WASM hâlâ Mono’da kalıyor
• Geri dönüş mümkün — geçişte sorun çıkarsa Mono’ya opt-out yapabiliyorsunuz
• Tooling tarafında — diagnostics, profiling ve GC davranışları backend’inizle daha yakın hâle geliyor

Aslında durun, bunu da söylemeden geçmeyeyim: Microsoft için bu sıfırdan atılmış bir adım değil. CoreCLR’a uzun zamandır platform ekliyorlar; önce Windows geldi, sonra Linux, sonra macOS (AppKit). Android….NET 11’de yapılan şey işe hâlâ Mono’da kalan son birkaç platformu da aynı hatta çekmek. Yani ortada anı bir patlama yok; daha çok uzun süredir hazırlanan geçişin son parçası var.

Mono’ya Geri Dönüş — Güvenlik Ağınız Var

Eğer projeyi build ederken işler ters giderse csproj dosyaniza küçük bir property eklemek yetiyor:

<PropertyGroup>
<UseMonoRuntime>true</UseMonoRuntime>
</PropertyGroup>

Bu opt-out mekanizması ne kadar yaşar bilmiyorum. Tahminim.NET 12 ya da 13 civarında neredeyse tamamen kalkacak yönünde ama emin değilim tabii; yine de şimdilik elimizde kaçış kapısı olması iyi hissettiriyor.

Neden CoreCLR?

Microsoft’un kendi açıklamasında üç ana sebep var. Ben biraz saha tarafını da karıştırayım dedim.

1. Runtime Birliği

Daha önce manzara şuydu: Backend API’nız CoreCLR’da çalışıyor, mobil uygulamanız Mono’da dönüyor. Farklı JIT davranışları var, farklı GC karakteristikleri var, farklı diagnostic araçları var… Logosoft’ta bir bankacılık projesinde tam bunu yaşamıştık — sunucuda sorunsuz çalışan serialization kodu iOS tarafında AOT kısıtları yüzünden bambaşka davranmıştı. Saatlerce bug kovalamıştık yani (ben de ilk duyduğumda şaşırmıştım)

Şöyle söyleyeyim, Tek runtime olunca böyle “platform-specific gariplik” sürprizleri azalacak gibi duruyor. Tamamen bitecek demiyorum; çünkü Android ve iOS’un kendi platform kuralları hâlâ orada duruyor. Peki bunu neden söylüyorum? Ama runtime kaynaklı farkların çoğu bayağı küçülecek.

2. Performans

CoreCLR’ın JIT compiler’ı olan RyuJIT yıllardır didik didik optimize ediliyor. Tiered compilation var, dynamic PGO var, loop hoisting var, devirtualization var… Mono’nün JIT’i kötü değildi ama yarış eşit değildi açıkçası. Şimdi mobil uygulamalar da bu optimize etmelardan payını alacak.

Erken benchmark sonuçlarında startup time iyileşmeleri ve throughput artışı raporlanıyor (kendi tecrübem). Ama buyurun açık konuşayım: asıl tabloyu production gösterecek. Lab ortamındaki rakamlarla gerçek hayat bazen birbirine pek benzemez.

3. Tooling ve Diagnostics

Bence en tatlı kazanç burada geliyor olabilir. dotnet-trace, dotnet-counters ve dotnet-gcdump gibi araçlar artık mobil uygulamalarda da kullanılabilecek gibi görünüyor. Geçen ay bir e-ticaret müşterisinde MAUI uygulamasında memory leak avlıyorduk; Mono profiler’ın çıktısı biraz cılız kalmıştı doğrusu. CoreCLR ile bu iş ciddi biçimde rahatlayacak.

Mono ve CoreCLR Karşılaştırması — Kısa Tablo

Özellik	Mono (eski)	CoreCLR (.NET 11+)
JIT Compiler	Mono JIT	RyuJIT + Dynamic PGO
GC	SGen	Server/Workstation GC
AOT	Mono AOT	NativeAOT (yol haritasında)
Diagnostics	Sınırlı	Tam dotnet-* tooling
Backend ile uyum	Ayrı runtime	Aynı runtime
WASM desteği	Var (devam ediyor)	Yok (Mono kalıyor)

Peki Türkiye’deki Şirketler İçin Ne Anlama Geliyor?

Lafın yerel tarafına gelelim şimdi biraz da bizden bakalım meseleye. Türkiye’de MAUI’nın. Öncesinde Xamarin’in benimsenmesi kendine has ilerledi diyebilirim ben buna istesem bile dümdüz diyemem çünkü öyle olmadı zaten büyük kurumlar özellikle bankalar sigorta şirketleri telekomlar Xamarin yatırımlarını yıllar önce yaptılar ve o emeği çöpe atmak istemiyorlar onlar için CoreCLR geçişi güzel haber çünkü ekiplerin backend bilgisini mobile taşımak artık daha doğal hâle geliyor.

Küçük startup tarafında işe durum başka türlü akıyor mesela ekipler çoğunlukla Flutter ya da React Native seçiyor MAUI çok sık tercih edilmiyor bu geçiş onların gözünde MAUI’yi daha cazip yapar mı açıkçası emin değilim. Mobil dünyada karar sadece runtime kalitesiyle verilmiyor community paket ekosistemi hot reload deneyimi gibi şeyler de masada duruyor ki burada MAUI bazı alanlarda hâlâ geriden geliyor gibi hissediliyor.

Ama şunu net söyleyeyim: Eğer zaten.NET ile enterprise backend yazıyorsanız ve yanina mobil uygulama da koyacaksanız MAUI artık eskisine göre çok daha mantıklı bir seçenek hâline geldi tek dil tek runtime tek tooling kulağa slogan gibi geliyor olabilir ama pratikte karşılığı bayağı var.

Kurum mu Startup mı?

Bunu sık soruyorlar diye kısa kısa ayırayım: (bizzat test ettim) Azure IaaS Performans: Sistem Düzeyli Yaklaşımın Gücü yazımızda bu konuya da değinmiştik.

• Büyük kurumsal yapı, mevcut.NET ekibi: MAUI + CoreCLR bayağı mantıklı duruyor backend web mobil hepsi aynı runtime üzerinde aynı diagnostics zincirinde ilerleyebiliyor.
• Küçük startup hızlı hareket ediyor:, Flutter hâlâ daha pratik olabilir özellikle UI özelleştirmesi yoğunsa iş görüyor yani öyle boşuna tercih edilmiyor.
• Melez ekip mobil ağırlıklıysa:, React Native ya da.NET MAUI arasında karar çıkabilir bütçe ile mevcut yetkinliği yan yana koyup bakmak lazım.

Süreçte Neler Takılabilir?

.Preview 4’ü kendi test projemde denedim ilk build’de eski bir bindings kütüphanesi NuGet paketi AOT uyumsuzluğu yüzünden patladı hata mesajı kabaca şöyleydi:

Error : Could not resolve native function 'xyz_native_call'
targeting CoreCLR runtime on iOS.

Çözüm aslında basitti paketin güncel sürümüne geçmek gerekiyordu eski versiyon Mono runtime varsayıyormuş yani en kritik nokta şu neredeyse tüm NuGet bağımlılıklarını güncelleyin özellikle native binding içeren paketlere ekstra dikkat edin.

İkinci uyarım şu reflection ağırlıklı kodunuz varsa mesela bazı eski MVVM framework’lerinde olduğu gibi trimming davranışı CoreCLR tarafında biraz farklı işleyebiliyor test etmeden geçmeyin production’a aceleyle koşmayın.

Kademeli Geçiş İçin İlk Adımlar

1. Yedek alın— git branch açın “maui-coreclr-test” gibi
2. . NET 11 SDK’yı kurunve TargetFramework’ü güncelleyin
3. NuGet paketlerini güncelleyin— özellikle community binding olanları
4. Release build alın— Debug’da görünmeyen AOT sorunları burada çıkar (bence en önemlisi)
5. Gerçek cihazda test edin— emulator/simulator yetmez
6. Performance baseline alın— startup memory FPS karşılaştırması yapın
7. Sorun olursa— UseMonoRuntime=true ile geri dönün GitHub’a issue açın

Maliyet Tarafına Bakınca Ne Görüyoruz?

İşin para kısmına gelelim mobil göç dediğimizde Türkiye şartlarında doğrudan ekip eforu konuşuyoruz orta büyüklükte bir MAUI projesini diyelim ki 100-150 ekranlık bir yapıyı CoreCLR’a taşımak için tahminimce iki üç hafta developer eforu yeterli ölür eğer paket bağımlılıklarınız makulse ekip kıdemine göre TL bazında yaklaşık 80-150 bin TL bandından söz edebilirim.

Karşılığında ne alıyorsunuz? Daha iyi diagnostics üretimde bug çözme süresi düşer daha iyi performans Azure’da koşan backend ile aynı GC davranışı oluşur uzun vadeli destek tarafında işe Mono’nün MAUI ayağının ne kadar bakım göreceği biraz belirsiz kalıyor bence ROI fena değil. Aceleniz yoksa beklemek de mantıklı çünkü.NET 11 LTS değil asıl LTS yolu.NET 12 ile geliyor. Daha fazla bilgi için VS Code’da Copilot’a C++ Bağlamı: Custom Instructions yazımıza bakabilirsiniz.

Bir dakika — bununla bitmedi. Kubernetes v1.36: Silinemeyen Admission Politikaları Dönemi yazımızda bu konuya da değinmiştik.

.NET Tarafındaki Diğer Yeniliklere de Bakın

Bu geçiş aslında.NET 11’in tek büyük konusu değil Process API tarafında da ciddi iyileştirmeler var yazımda detaylandırmıştım Aynı şekilde dil tarafındabaşlığında bellek güvenliği yeniliklerini anlattım Paket yönetimi tarafındakiyazısı da bence okunmaya değer.

Kendi Kanaatim

Açık konuşayım doğru yönde atılmış bir adım bu yıllardır Xamarin/MAUI tarafında mobil. NET hep geride kalıyor hissi vardı backend yazarken son teknolojiyi kullanıp mobile gelince eski araçlarla idare etmek zorunda kalıyorduk şimdi o uçurum kapanıyor.

Ama kağıt üstünde iyi görünen şeylerin pratiğini görmek için biraz zaman gerekiyor Preview 4 hâlâ Preview hot reload designer bazı XAML davranışları derken sürpriz çıkabilir o yüzden production projelerinde bence . NET11 GA çıkana kadar bekleyin yeni projelerde işe Preview4 ile deneme yapmak gayet mantıklı hatta yapılmalı bile çünkü geri bildirim Microsoft’un işi sağlamlaştırmasına yardım eder.

İlginç olan şu ki, Mono’ya da ayrı parantez açmak lazım on beş yılı aşkın süredir imkansız sandığımız yerlere. NET’i taşıdı şimdi bayrağı Core CLR devralıyor. O miras unutulmamalı çünkü gerçekten o olmasaydı bugün burada anlattığımız şeylerin hiçbiri olmazdı.

>>

Sıkça Sorulan Sorular

Mevcut MAUI uygulamam.NET 11’e geçince otomatik CoreCLR’a mı taşınır?

Şunu söyleyeyim, Evet, taşınıyor..NET 11 hedefleyen MAUI projelerinde Android, iOS ve Maç Catalyst için varsayılan runtime artık CoreCLR. Aslında hiçbir ekstra property falan eklemenize gerek yok, sadece TargetFramework’ü güncellemek yeterli. Sorun yaşarsanız UseMonoRuntime=true ile eski hâline dönebilirsiniz.

Blazor Hybrid uygulamam etkilenir mi?

Blazor Hybrid, yani MAUI içinde çalışan Blazor, MAUI’nın runtime’ını kullandığı için evet, CoreCLR’a geçiyor. Ama Blazor WebAssembly biraz farklı bir senaryo — tarayıcıda çalışıyor (kendi tecrübem). Hâlâ Mono kullanıyor..NET 11’de bu değişmiyor, yani ikisini karıştırmamak lazım.

Kısa bir not düşeyim buraya.

Uygulamamın boyutu artar mı?

Erken testlerde APK/IPA boyutlarında küçük farklılıklar gözüküyor ama dramatik bir artış raporlanmıyor açıkçası. Trimming ve AOT optimizasyonları da çalışmaya devam ediyor. Bence en sağlıklısı kendi uygulamanızda Release build alıp karşılaştırmak, çünkü her proje farklı davranabiliyor (ki bu çoğu kişinin gözünden kaçıyor)

Production’a ne zaman alabilirim?

Tecrübeme göre.NET 11 GA çıkana kadar beklemek en mantıklısı — Kasım 2026 civarı bekleniyor. Şu an Preview döneminde, yani bug bulma ve düzeltme süreci hâlâ devam ediyor. Yeni başlayan projelerde Preview ile rahatça deneyebilirsiniz, (inanın bana). Kritik production yükleri için GA’yı beklemenizi öneririm.

Bunu biraz açayım.

Xamarin.Forms uygulamam ne olacak?

Bir şey dikkatimi çekti: Xamarin.Forms’un desteği zaten Mayıs 2024’te sona erdi. CoreCLR geçişi sadece.NET MAUI için geçerli. Hâlâ Xamarin.Forms kullanıyorsanız önce MAUI’ye geçmek lazım, sonra.NET 11 ile CoreCLR’ın getirdiği avantajlardan faydalanabilirsiniz. Bence bu geçişi ne kadar erken yaparsanız o kadar iyi.

Kaynaklar ve İleri Okuma

.NET MAUI Moves to CoreCLR in.NET 11 — Microsoft DevBlogs

.NET MAUI Resmî Dokümantasyonu

dotnet/maui GitHub Repository

.NET Runtime Configuration Reference