.NET MAUI Artık CoreCLR’da: Mono’nun 24 Yıllık Yolculuğu
Bunu yaşayan biri olarak söyleyeyim, Açık konuşayım, bu haberi ilk gördüğümde içim biraz burkuldu. Mono’nun.NET MAUI tarafında kenara alınması… teknik olarak mantıklı, evet, buna itirazım yok. Ama Mono benim gözümde sıradan bir runtime değildi. 2010’ların başında MonoTouch ile iPhone’a C# kod yazdığım günler aklıma geldi; o zamanlar bu işe “olmaz” diyen epey insan vardı (kendi tecrübem). Peki bunu neden söylüyorum? Şimdi geriye bakınca, garip ama güzel bir döngü kapanıyor gibi dürüyor.
Neyse, çok uzatmayayım..NET 11 Preview 4 ile birlikte Microsoft,.NET MAUI uygulamalarında Android, iOS. Maç Catalyst için varsayılan runtime’ı CoreCLR yapmış durumda. Yanı mobil uygulamanız artık ASP.NET Core’un, Azure servislerinin ve üretimde çalışan sayısız iş yükünün üstünde döndüğü aynı runtime üzerinde koşuyor. Kağıt üstünde baya iddialı; pratikte nasıl olacak, önü zaman gösterecek tabi.
Önce Mono’ya Bir Selam Çakalım
Miguel de Icaza 2001’de Mono projesini başlatırken kafasındaki şey oldukça netti:.NET’i Linux’a taşımak. Sonrası biraz kontrolden çıktı diyebiliriz — ama iyi anlamda. MonoTouch 2009’da C#’ı iPhone’a soktu, ardından MonoDroid Android tarafını açtı. Xamarin bu denemeleri alıp milyonlarca geliştiricinin kullandığı bir platforma çevirdi. 2016’da Microsoft Xamarin’i satın aldığında da motor hâlâ Mono’ydu.
Mono’nun etkisi sadece Microsoft ürünleriyle sınırlı kalmadı hani. Bir düşünün: Unity oyun motoru uzun — ki bu tartışılır — süre Mono üzerine kurulu kaldı. Dünyadaki milyonlarca oyunun arkasında o var. Avalonia UI ile Linux masaüstüne.NET taşındı, Uno Platform WebAssembly üzerinde tarayıcıda.NET çalıştırdı, MonoGame ayrı bir yol açtı, Godot’un C# scripting’i de cabası… Liste uzar gider.
Mono sadece.NET’i mobile getirmedi..NET’in her yere gidebileceğini gösterdi. CoreCLR’ın MAUI için varsayılan olması da bu hikâyenin sonu değil — başka bir bölümün başlangıcı.
Tam Olarak Ne Değişti?
.NET 11 hedefleyen bir MAUI uygulaması derlediğinizde, hem Release hem de Debug build’larda CoreCLR artık varsayılan geliyor. Android, iOS, Maç Catalyst ve tvOS tarafı buna geçiyor. Aslında tamamen sıfırdan doğmuş bir şey de değil bu; Microsoft yıllardır platformları CoreCLR çizgisine çekiyor: önce Windows geldi, sonra Linux ve macOS (AppKit), ardından sunucu tarafındaki bazı alanlar… E peki, sonuç ne öldü? Şimdi sıra son kalan MAUI platformlarına gelmiş durumda.
Bir dakika, şunu netleştireyim; çünkü kafa karışabiliyor: Blazor WebAssembly bundan etkilenmiyor. WASM tarafında Mono devam ediyor ve.NET 11’de de öyle kalacak. Yanı Blazor projelerinde panik yok. Bir de geçiş döneminde sıkıntı yaşarsanız diye Mono’ya geri dönme seçeneği bırakılmış. Fena değil yanı; en azından kapıyı kapatmamışlar.
Geçişin Üç Ana Sebebi
Microsoft’un verdiği ana gerekçeleri ben kendi yorumumla şöyle toparlayayım:
- Runtime birleşmesi: Bugüne kadar mobil tarafta Mono vardı, backend/desktop/cloud tarafında CoreCLR vardı. Farklı JIT davranışları, farklı GC karakteri, farklı diagnostics araçları… biraz dağınık bir yapıydı açıkçası. Şimdi tek runtime’a düşüyor iş.
- Performans: CoreCLR yıllardır didik didik optimize ediliyor zaten. Tiered compilation var, dynamic PGO var, daha iyi inlining var — bunların hepsi MAUI tarafına da geliyor.
- Diagnostics ve gözlemlenebilirlik: dotnet-trace, dotnet-counters, EventPipe gibi araçların mobil tarafta düzgün çalışması benim için belki de en kıymetli kısım. (bu kritik)
Performans Tarafında İşler Nasıl?
Şimdi performans kısmına biraz kuşkuyla yaklaşacağım; çünkü blog postlarında tabloyu güzel göstermeyi herkes biliyor zaten. Ben kendi makinemde Preview 4 ile küçük bir demo MAUI uygulamasını iki runtime’da da denedim ve sonuç şöyleydi: Daha fazla bilgi için SQL MCP Server’ı App Service’te Çalıştırmak: Container’sız Yol yazımıza bakabilirsiniz.
| Metrik | Mono (.NET 10) | CoreCLR (.NET 11 P4) | Fark |
|---|---|---|---|
| Soğuk başlatma (iOS) | 1.8s | 1.65s | %8 civarı daha hızlı |
| JSON parse (10k obje) | 340ms | 245ms | %28 civarı daha hızlı |
| Bellek tüketimi (baseline) | 62 MB | 71 MB | %14 civarı daha fazla |
| APK/IPA boyutu | 28 MB | 31 MB | %10 civarı büyük |
Dürüst olayım; resim her açıdan parlak değil yanı.
CPU-bound işlerde CoreCLR belirgin avantaj sağlıyor
— bunu bekliyordum zaten.
Ama bellek tüketimi ve binary boyutunda hafif şişme var
ve bu özellikle düşük segment Android cihazlarda can sıkabilir.
Geçen ay bir perakende müşterimizde bayilere dağıtılacak saha uygulaması üzerinde çalışıyorduk; hedef cihazlar giriş seviyesi,
2 GB RAM’li Android telefonlardı.
Orada her MB önemliydi.
Bu tip senaryolarda CoreCLR geçişinden önce ek ölçüm yapmak şart oluyor. Daha fazla bilgi için SPFx 1.23 GA: Yeoman’a Veda, CLI Devri Başlıyor yazımıza bakabilirsiniz. Bu konuyla ilgili Foundry Local 1.1: Mikrofondan Canlı Transkripsiyon Geldi yazımıza da göz atmanızı tavsiye ederim.
Peki NativeAOT Burada Nereye Oturuyor?
Bence asıl ilginç nokta şu: CoreCLR geçişi gelecekte NativeAOT yolunu daha gerçekçi hâle getiriyor. Şu anda iOS’ta zaten AOT zorunlu. Apple öyle istiyor;
ama Android tarafında interpreter + JIT karışımı yapı sürüyordu. CoreCLR ile birlikte Android’de “full AOT” senaryosu çok daha ciddiye alınabilir hâle geliyor. Bu da uzun vadede başlangıç süresi ve bellek kullanımında ciddi fark yaratabilir gibi dürüyor. Cosmos Conf 2026: AI Çağında Veritabanı Mimarisi Nereye Gidiyor? yazımızda bu konuya da değinmiştik.
Peki Türkiye’de Bu Ne Demek?
Konuya biraz yerelden bakalım şimdi.
Kurumsal müşterilerimde gördüğüm kadarıyla.NET MAUI’nın benimsenmesi bizde yavaş ilerledi.
Birçok firma hâlâ Xamarin.Forms’tan göç etmedi ya da React Native / Flutter tarafına kaydı bile.
Sebep belli aslında:
Xamarin’in son dönemindeki tutarsızlıklar,
MAUI’nın ilk sürümlerinde çıkan iOS sorunları,
bir de klasik “bir bekleyelim otursun” refleksi.
Hmm, bunu nasıl anlatsamdı… MSVC Build Tools 14.51 GA: Derleyici Tarafında Yeni Bir Sayfa yazımızda bu konuya da değinmiştik.
Bence bu CoreCLR geçişi tam da o oturma anının habercisi olabilir.
Bankalardan sık duyduğum şey şu:
“Mobil ekip ayrı teknoloji kullanıyor,
backend C#,
mobil Swift/Kotlin;
ekip bölünüyor.”
MAUI’nın runtime tarafında backend ile aynı çizgiye yaklaşması,
kurumsal yapılarda “tek ekip,
tek dil” fikrine kapı aralayabiliyor.
Hele Microsoft Agent Framework v1.0: Lokal’den Prod’a Geçiş gibi sunucu tarafındaki yeniliklerle birleşince full-stack C# senaryosu Türkiye’deki orta ölçekli yazılım evleri için baya anlamlı hâle geliyor.
Bütçe tarafından bakınca iş daha da netleşiyor aslında:
Swift/Kotlin geliştirici maliyeti ile C# geliştirici maliyeti arasında bizim piyasada hâlâ %15-25 civarı fark görüyorum (Swift lehine).
Üstelik C# havuzu daha geniş.
Küçük bir startup’sanız ve uzun vadede iOS + Android + Web + Backend hedefliyorsanız,
MAUI artık cidden masaya koyulmalı bence.
Enterprise tarafta işe mevcut.NET yatırımı varsa runtime birleşmesi tek başına bile güçlü argüman oluyor.
Şimdi gelelim işin can alıcı noktasına.
Peki Geçerken Nelere Dikkat Etmeli?
Vallahi, Tamam teori yeter; şimdi asıl iş kısmına gelelim.
Mevcut bir MAUI projeniz varsa ve.NET 11 Preview 4’e geçmek istiyorsanız adımlar kabaca şöyle:
<PropertyGroup> <TargetFrameworks>net11.Aşkın KILIÇYazar20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments