Microsoft ogłasza migrację Menu Start z React na WinUI 3 jako przełom dla wydajności systemu. Brzmi dobrze. Jest jeden problem — deweloperzy którzy próbowali budować aplikacje na WinUI 3 przez ostatnie lata mają zupełnie inne zdanie o tym frameworku. I dokumentują je szczegółowo na GitHubie.
Krótka historia złych decyzji
Żeby zrozumieć czym jest WinUI 3 i dlaczego jego obecny status jest paradoksalny, trzeba cofnąć się o dwie dekady.
Microsoft miał przez lata jeden pewny framework do budowania aplikacji Windows — WPF, czyli Windows Presentation Foundation, wydany w 2006 roku razem z .NET 3.0. WPF był dojrzały, stabilny, bogaty w komponenty i mimo że stary, działał. Deweloperzy go lubili.
Potem przyszło Windows 8 i UWP — Universal Windows Platform. Microsoft ogłosił że to przyszłość, że WPF jest legacy i wszyscy powinni migrować. Deweloperzy niechętnie zaczęli się przestawiać. Windows 8 okazał się katastrofą komercyjną. UWP nigdy nie zyskał takiej adopcji jakiej oczekiwał Microsoft. WPF nadal żył.
Następnie pojawił się Xamarin — do aplikacji mobilnych. Potem MAUI jako jego następca. Gdzieś po drodze UWP zaczął być cicho wygaszany. W 2021 roku Microsoft ogłosił WinUI 3 jako "natywny framework UI dla Windows" który miał połączyć to co najlepsze z UWP i WPF, wyzwolony z ograniczeń UWP dzięki decoupling od cyklu aktualizacji systemu.
Każda z tych platform była ogłaszana jako "przyszłość Windows development." Żadna nie zastąpiła poprzedniej w sposób czysty i kompletny.
WinUI 3 — dobry pomysł, słaba egzekucja
Idea za WinUI 3 jest solidna. Oddzielenie frameworka od systemu operacyjnego oznacza że aplikacje mogą być aktualizowane niezależnie od cyklu Windows Update. Natywny rendering zamiast webowych warstw. Fluent Design jako spójny język wizualny. Na papierze — wszystko czego brakowało UWP bez jego ograniczeń.
Praktyka okazała się inna. Na GitHubie projektu microsoft-ui-xaml kumulowały się przez lata raporty błędów które nie były naprawiane. Społeczność zaczęła dokumentować rosnące zaniepokojenie nie tylko liczbą bugów ale brakiem aktywności ze strony zespołu Microsoft.
Jeden z deweloperów na GitHubie przeprowadził analizę porównując aktywność commitów w projekcie WinUI 3 versus MAUI — cross-platformowy framework Microsoftu dla aplikacji mobilnych. Wynik był niepokojący: Microsoft inwestował wielokrotnie więcej wysiłku w MAUI niż w WinUI 3, który miał być "wyznaczoną główną technologią UI dla Windows desktop." Wniosek który część społeczności wyciągnęła był prosty — jeśli to prawda, WinUI 3 prawdopodobnie nie jest już priorytetem.
Na GitHubie pojawiły się dyskusje z wymownymi tytułami. "WinUI 3 jest naprawdę martwy — kiedy możemy spodziewać się ogłoszenia?" to jedna z nich, z setkami komentarzy deweloperów dokumentujących frustrację. Brak oficjalnych odpowiedzi ze strony Microsoftu na zgłaszane problemy. Nieaktualizowana mapa drogowa projektu. Product Board który przestał być utrzymywany.
Jeden z uczestników tych dyskusji podsumował problem zwięźle: "Poważne błędy i ich liczba to główny powód dla którego nie przechodzimy na WinUI 3, nie brakujące funkcje."
Paradoks 2026 roku
I tutaj robi się interesująco. Microsoft w tym samym czasie gdy deweloperzy pytają publicznie czy WinUI 3 jeszcze żyje, ogłasza migrację kluczowych elementów systemu operacyjnego właśnie na ten framework.
Menu Start przechodzi z React na WinUI 3. Quick Settings mają być szybsze dzięki WinUI. File Explorer ma poprawić responsywność przez migrację kolejnych komponentów. To brzmi jak deklaracja że Microsoft wierzy we własny framework na tyle żeby budować na nim rdzeń systemu.
Jest w tym pewna logika. Używanie własnych narzędzi do budowania własnego systemu — tzw. dogfooding — to jeden z najskuteczniejszych mechanizmów napędowych jakości. Jeśli deweloperzy Microsoftu będą musieli codziennie pracować z WinUI 3 budując Windows, mają bezpośredni interes w naprawianiu jego problemów.
Ale jest też cyniczne odczytanie tej sytuacji. Microsoft może migrować system na WinUI 3 przede wszystkim dlatego że chce poprawić wydajność Windows, nie dlatego że WinUI 3 jako platforma dla zewnętrznych deweloperów jest gotowa i wspierana. To dwa różne cele które mogą iść w tym samym kierunku — albo nie.
Open source jako ostatnia szansa
W sierpniu 2025 roku Microsoft ogłosił że WinUI 3 staje się projektem open source, w czterech fazach. To znaczący sygnał — firma rzadko otwiera projekty które traktuje jako strategicznie martwe. Ale społeczność przyjęła to z mieszanymi uczuciami.
Na GitHubie pojawiły się komentarze które celnie podsumowały sceptycyzm: "To świetne, ale Microsoft musi zaalokować zasoby do zarządzania społecznością, albo to stanie się kolejnym porzuconym projektem open source." Inni pytali wprost ile deweloperów jest faktycznie przypisanych do WinUI i czy web nie jest już od lat prawdziwym priorytetem.
Historia Microsoftu z open source jest złożona. .NET jest historią sukcesu — firma otworzyła go, społeczność go przyjęła, ekosystem wyrósł. Inne projekty trafiały na GitHub i powoli obumierały z braku uwagi.
Jaka jest prawda
WinUI 3 jest technicznie lepszy niż React Native jako warstwa UI systemu operacyjnego. To nie jest kontrowersyjna teza — natywny framework po prostu ma niższe opóźnienia niż webowy. Migracja Menu Start przyniesie realną poprawę wydajności dla użytkowników i to jest dobra wiadomość.
Pytanie o WinUI 3 jako platformę dla deweloperów budujących zewnętrzne aplikacje jest oddzielne i mniej optymistyczne. Framework ma otwarte bugi których wiek mierzy się w latach. Dokumentacja ma luki. Narzędzia deweloperskie mają swoje problemy. WPF który miał być zastąpiony odzyska status na Build 2024 po tym jak społeczność deweloperów wyraziła jasno że WinUI 3 nie jest gotowy jako jego zamiennik.
Kiedy Microsoft buduje Menu Start na WinUI 3, robi to z zasobami i wiedzą wewnętrzną której zewnętrzny deweloper nie ma. Korzysta z frameworka od środka, z dostępem do kodu który nie jest jeszcze publiczny, z możliwością naprawiania problemów które zgłaszałby jako bug gdyby był zewnętrznym użytkownikiem.
To nie jest ten sam WinUI 3 który dostaje zewnętrzny deweloper próbujący zbudować aplikację biznesową.
Paradoks roku 2026 polega na tym że Microsoft naprawia własny system używając narzędzia o którego jakość społeczność deweloperów pyta od lat. Może to wymusi poprawę frameworka. Może to tylko przyspieszy Windows kosztem wszystkiego innego.
Na to pytanie odpowiedź przyjdzie za rok lub dwa. I osflux będzie ją śledzić.