- Windows yerel uygulama geliştirme ekosistemi, onlarca yıldır süren framework kopuklukları ve tekrar eden yeniden tasarımlar nedeniyle 2025 itibarıyla hâlâ gerçek anlamda geliştirme verimliliği sunamıyor.
- Win32’den MFC, WinForms, WPF, WinRT ve UWP üzerinden WinUI 3’e uzanan 7 aşamalı UI framework evrimine rağmen, yalnızca en yeni API’lerle en temel özelliklerin bile uygulanamadığı çok sayıda durum bulunuyor.
- Tepsi simgesi, global kısayol yakalama gibi gündelik işlevler hâlâ P/Invoke üzerinden Win32 çağrılarına bağımlı; bu da modern framework benimsemenin anlamını zayıflatıyor.
- Basit bir yardımcı uygulama .NET AOT derlemesi ile derlense bile 9MiB’ı aşan bir ikili dosya ortaya çıkıyor ve MSIX dağıtımı için gereken kod imzalama sertifikası yıllık $200–300 düzeyinde pratik bir engel oluşturuyor.
- Microsoft’un kendi başlıca uygulamalarının (VS Code, Outlook, Başlat menüsü) web teknolojileriyle geliştirilmiş olması, Windows yerel geliştirmenin Microsoft içinde de artık öncelik olmadığını gösteriyor.
Arka plan: Ne geliştirildi
- Yalnızca Windows’a özel ‘Display Blackout’ yardımcı uygulaması geliştirilirken mevcut yerel uygulama geliştirme ortamının sorunları ortaya çıktı.
- Bu uygulama, çoklu monitör ortamında oyun oynarken sağ ve sol ekranları siyah bir kaplama ile karartma işlevi sunuyor.
- Gerekli özellikler arasında ekran listeleme, sınır hesaplama, global kısayol işleme, tepsi simgesi gösterimi, başlangıçta otomatik çalıştırma, ayarları kaydetme yer alıyor.
- Mevcut AutoHotkey betikleri ve Microsoft Store uygulamaları olsa da, öğrenme amacı ve UI iyileştirmesi için doğrudan geliştirme denendi.
- Sonuç olarak Windows yerel uygulama geliştirme ortamının son derece karmaşık ve verimsiz olduğu görüldü.
Windows programlamanın tarihi
- Başlangıçta tek seçenek C tabanlı Win32 API idi ve bu API bugün de hâlâ geçerliliğini koruyor.
- C++ tabanlı MFC, sınıf ve şablon gibi nesne yönelimli soyutlamaları Win32’nin üzerine ekledi.
- .NET 1.0 (2002) ile C# dili, JIT bayt kodu VM’i ve otomatik bellek yönetimi geldi; Windows Forms ise Win32 pencere ve kontrol API’lerinin bir sarmalayıcısıydı.
- .NET 3.0’daki WPF (2006), XAML işaretleme dilini tanıttı ve GPU tabanlı kontrol çizimiyle Win32 bağımlılığından uzaklaşmaya yönelik ilk girişim oldu.
- Windows 8’deki WinRT (2012), sandbox uygulama modelini getirdi; masaüstü, tablet ve telefonu birleştirmeyi hedefliyordu ancak XAML yapısının WPF’den ince farklarla ayrılması kafa karışıklığı yarattı.
- Windows 10’daki UWP (2015), sandbox kısıtlarını kısmen gevşetti ama WPF düzeyindeki masaüstü yetkilerine ulaşamadı; bazı OS özellikleri (push bildirimleri, canlı kutucuklar, Microsoft Store dağıtımı) yalnızca WinRT/UWP’ye özel kaldı.
- Bu durum, Chrome ve Microsoft Office gibi mevcut uygulamaların WinRT/UWP köprü uygulamalarını IPC ile bağlayan garip mimariler benimsemesine yol açtı.
- Windows 11’deki Windows App SDK (2021), WinRT/UWP’ye özel işlevleri hem standart C++ hem de .NET uygulamalarına açtı ve WinUI 3 adlı yeni bir XAML tabanlı kontrol kütüphanesini içerdi.
- UI framework evriminin özeti:
> Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3
Geliştirme yaklaşımı seçiminin ikilemi
- WinUI 3 uygulaması geliştirmek için üç yol var:
- C++: yalın bir ikili dosya, Win32 C API ile kolay birlikte çalışabilirlik — ancak bellek güvenliği yok
- C#/XAML + framework bağımlı dağıtım: En güncel Windows 11’de bile yalnızca .NET 4.8.1 önceden kurulu geldiğinden, ilk kurulumda .NET kütüphanelerini indirme diyaloğunun çıkması kötü bir kullanıcı deneyimi yaratıyor
- C#/XAML + .NET AOT: Tüm .NET çalışma zamanı (VM, GC, standart kütüphane) ikili dosyaya gömülüyor — basit bir uygulama bile 9MiB’ın üzerinde bir ikili üretiyor
- Rust binding’lerini sürdürme girişimi olan (windows-app-rs) arşivlendi.
- Dağıtım yöntemi seçimi de başlı başına bir acı:
- MSIX biçimi kod imzalama sertifikası gerektiriyor ve ABD dışında yaşayanlar için yılda $200–300 maliyet doğuruyor
- İmzasız sideload işlemi, yalnızca yönetici terminalinde kullanılabilen karmaşık PowerShell komutları gerektiriyor
- Microsoft Store kaydı, “özgün ve kalıcı değer” sunmadığı gerekçesiyle reddedildi
Modern SDK ile bile yapılamayan özellikler
| Özellik | Windows App SDK desteği |
|---|---|
| Ekran listeleme | Kısmen mümkün (foreach döngüsü yok, değişiklik algılama için P/Invoke gerekiyor) |
| Etkinleştirmeyen siyah pencere yerleştirme | Kısmen mümkün (non-activating için P/Invoke gerekiyor) |
| Global klavye kısayolu yakalama | Mümkün değil — P/Invoke gerekiyor |
| Başlangıçta otomatik çalıştırma | Mümkün (sistem ayarlarıyla entegre API sağlanıyor) |
| Ayarları kalıcı saklama | Mümkün |
| Tepsi simgesi + menü | Mümkün değil — P/Invoke gerekiyor, menü stili standart değil |
- Tepsi simgesi menülerinin stili uygulamadan uygulamaya değişiyor; OS genelinde tutarlı bir standart yok.
- WPF’den WinUI 3’e geçiş sürecinde pencere boyutunu otomatik ayarlama gibi temel özellikler bile kaybolmuş durumda.
C# ile Win32 birlikte çalışabilirliğinin yapısal sınırları
- Modern P/Invoke aracı CsWin32 içinde, struct içindeki string’leri doğru sarmalayamayan bir hata bulunuyor.
- CsWin32 belgeleri, Win32 API’nin temel parametre tipi olan
[optional, out]ifadesinin C# içinde idiomatik olarak temsil edilememesi nedeniyle aynı metodun iki sürümünü ürettiklerini belirtiyor. - WPF’nin çıkışından (2006) yaklaşık 20 yıl sonra bile UI binding için sınıf yazmadaki boilerplate neredeyse hiç iyileşmedi.
- Tüm property’leri getter/setter çiftine dönüştürme, aynı değer koruması, event tetikleme çağrıları gibi tekrar eden kodlar hâlâ gerekiyor.
- JavaScript’teki decorator ve proxy’lere benzer dil düzeyinde çözümler 20 yıldır C#’a eklenmedi.
- CsWin32’nin changelog içeriği zayıf ve sürümü hâlâ 1.0’ın altında; bu yüzden birkaç yıl içinde projenin terk edilme ihtimali var gibi görünüyor.
Sonuç: Neden yanıt Electron
- Şu anda Microsoft yerel uygulama geliştirmeye öncelik vermiyor.
- İlgili issue tracker’lar hata ve raporlarla dolu ama Microsoft mühendislerinden neredeyse hiç yanıt yok.
- Windows App SDK’nın değişiklik günlüğü, ağırlıklı olarak makine öğrenimi API’leri eklemeye odaklanıyor.
- VS Code, Outlook ve Başlat menüsü gibi Microsoft’un kendi önemli uygulamalarının web teknolojileriyle geliştirilmiş olması da bunu doğruluyor.
- Topluluk Avalonia ve Uno Platform gibi üçüncü taraf UI framework’lerine kayıyor.
- Bunlar WPF felsefesini sürdürüyor ve çapraz platform desteğini güçlendiriyor.
- Şu an için Electron veya Tauri gibi web tabanlı framework’ler daha gerçekçi bir seçim.
- TypeScript/React/CSS kombinasyonu, C#/XAML’den daha üretken
- Win32 API erişimi de mümkün
-
Tauri** ise** sistem WebView’ını kullandığı için Chromium paketi gerektirmiyor
- WebView2 runtime’ı her 4 haftada bir güncelleniyor, buna karşılık sistem .NET’i 4.8.1’e sabitlenmiş durumda
- Microsoft, Windows App SDK’yı iyileştirme ve dağıtım sistemini basitleştirme yönünde adım atarsa toparlanma ihtimali olabilir
- Ancak şu an için çoğu geliştirici bunun olmasını beklemiyor
- Sonuç olarak değerlendirme, “web stack’i seçeceğim” noktasında bitiyor
- Microsoft’un yakın tarihli Windows kalitesine odaklanma duyurusu, OS genelinde WinUI 3’ün daha fazla kullanılacağını söylüyor; ancak bunun somut iyileşmeye dönüşüp dönüşmeyeceği belirsiz.
3 yorum
Electron ile normale döndürdüğünüz için...
WinUI 3 için WYSIWYG ne zaman gelecek acaba, gerçekten merak ediyorum
Hacker News görüşleri
Ben de diğerleri gibi Win32'ye bağlı kalmanın doğru olduğunu düşünüyorum
Uzun süre Win32 ile geliştirme yapmış biri olarak, gereken işlevlerin 8KB'den küçük bağımsız bir çalıştırılabilir dosyayla rahatça uygulanabildiğini söyleyebilirim
Ekranları listeleme, pencere oluşturma, kısayol tuşlarını yakalama, başlangıçta çalışacak şekilde kaydetme, ayarları saklama, sistem tepsisi simgesi gösterme gibi şeylerin hepsi birkaç yüz baytlık API çağrılarıyla yapılabiliyor
Ama 2026'da yeni bir projeyi bellek güvenli olmayan bir dilde (C++) yazmak çağın gerisinde kalmak olur
Yine de güvenilmeyen girdinin neredeyse hiç olmadığı bir uygulamaysa, sırf propagandaya kapılmaya gerek yok
_UNICODEsorunlarından kaçınmak istiyorsanız, .NET Framework ile aynı şeyi sürenin yarısında yapabilirsiniz“NoFramework” hareketinin geri gelip RAD dönemine dönmemiz gerektiğini düşünüyorum
Ama yeni projelerde C++ seçimi dikkatle yapılmalı
Bellek güvenli dillerde de Win32 kullanılabilir — örneğin windows-rs
O dönemde Borland Delphi en popüler araçtı
Mevcut WinRT, UAP, UWP uygulamaları dışında WinUI 3.0 veya WinAppSDK'den kaçınmak gerekir
Win32, MFC, WinForms, WPF gibi kendini kanıtlamış teknolojileri kullanmaya devam etmek daha iyi,
Microsoft dışı ekosistemde ise Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI gibi seçenekler değerlendirilebilir
WinUI 3.0 o kadar dağınık ki Microsoft bile bunu topluluğa açık kaynak olarak devretmeye çalışıyor
Sonrasında WinJS açık kaynaklı bir web framework'üne dönüştü ve resmi destek kesildi
İlgili blog yazısı
Gömülü sistem geliştiricisiyim ve cihazlarla haberleşen Win32 GUI programları yapmak hâlâ kolay
XP döneminden kalma kodlar Windows 11'de de aynen çalıştı, VC6 projesini Visual Studio 2022 ile açınca da sorunsuz derlendi
Bu tür geri uyumluluk başka platformlarda pek görülmüyor
Apple'ın Cocoa'sı yapısal olarak “zarif” görünebilir ama pratikte karmaşık ve dokümantasyonu da pek yardımcı değil
Saf Win32 API hâlâ pratik bir tercih
C++ ile MFC benzeri bir wrapper'ı kendiniz yazarsanız 2~3 haftada tamamlanabilir, sonrasında da tam denetime sahip olursunuz
Microsoft'un güçlü geri uyumluluğu sayesinde Win32 tabanlı uygulamalar uzun vadede istikrarlı
10 yıldan uzun süredir güncellenen bir örnek burada görülebilir
Sistem renkleri ve denetimler sabit kodlandığı için koyu temayla çakışıyor
Menü, mesaj kutusu, dosya iletişim kutusu gibi yalnızca bazı UI parçaları karanlık modu desteklediğinden tutarlılık bozuluyor
İlgili tartışma için bu yazıya bakılabilir
Şu anda açık kaynak olarak sürdürülüyor ve 10. sürüme kadar geldi
Birden fazla Windows uygulaması geliştirmiş biri olarak,
(1) Win32 API eski ama son derece kararlı,
(2) Microsoft'a ait UI toolkit'lerinden uzak durmak gerekiyor — çünkü eninde sonunda Win32 seviyesinde denetime ihtiyaç duyuluyor
Microsoft'un son 20 yılda yaptığı UI teknolojilerinin çoğu aslında WPF varyasyonuydu
WPF geliştirilmeye devam edilseydi bugün UI geliştirmede standart hâline gelmiş olurdu
Kullanıcı açısından yerel uygulamalar hızlı ve iyi, ama geliştirme tarafı gerçekten karmaşık bir kaos
Outlook ve Teams gibi uygulamaların giderek kötüleşmesinin nedeni de bu
Odak, klavye ile gezinme gibi konularda yerel hissi taklit etmek zor
Electrobun projesine bakılabilir
“C++ ile yeni proje yapmak suçtur” sözüne katılmıyorum
GUI'de güvenlikten çok performans ve denetim önemlidir ve C++ hâlâ kendini kanıtlamış bir dildir
Qt 2026'da da en iyi GUI framework'lerinden biridir ve içinde bellek güvenliği sağlayan özellikler barındırır
Modern .NET runtime'ının neden Windows 11'e varsayılan olarak dahil edilmediğini merak ediyorum
Bu, Microsoft'un tutarlı kullanıcı deneyiminden vazgeçtiğinin bir başka örneği gibi görünüyor
hepsini Windows Update ile dağıtmak gerçekçi değil
Bunun yerine AOT derlenmiş bağımsız çalıştırılabilir dosyalar dağıtılabilir (yaklaşık 9MiB)
Electron'dan çok daha küçük ve verimli
Artık DLL'leri birlikte paketlemek daha iyi
işletim sistemine gömmek zorlaştı
Hızlı sürüm döngüsünü korumak için OS güncellemelerinden ayrıldı
.NET Core ise ayrıca kurulmalı
Uzun zaman sonra Tauri ile Windows ve Mac için uygulama yaptım,
geliştirme ve build süreci kolaydı ama kod imzalama sorunu yüzünden iş arkadaşlarım kurulum yapamadı
Mac'te terminal komutuyla çözdük ama Windows'ta Smart App Control kapatılmak zorundaydı
Üstelik bu özellik yeniden kurulum olmadan tekrar açılamıyor
Güvenlik amacını anlıyorum ama kurulum sürecinin bu kadar zor olacağını beklemiyordum
“Neden Electron kullanmıyorsun?” sorusunun yanıtı basit —
Electron uygulamalarının kullanıcı deneyimi kötü
Geliştirmesi kolay ama performans ve kalite pahasına
İyi bir ürün yapmak istiyorsanız zor olsa da yerel geliştirmeyi seçmelisiniz
Ben kişisel olarak C#'ın TypeScript'ten çok daha iyi olduğunu düşünüyorum