Microsoft w końcu robi natywne apki Windows. Będzie lepiej i na bogato
Idą nowe czasy dla Windowsa. Zechcesz dać drugą szansę, za sprawą w stu procentach natywnych aplikacji, wypychających wersje webowe z systemu.
Przez ostatnie kilka lat Microsoft robił coś dość osobliwego: uparcie przekonywał, że aplikacje oparte na technologiach webowych są "natywne" dla Windowsa. Teraz firma formuje zespół mający zbudować "prawdziwe", "w 100 proc. natywne" aplikacje dla Windowsa 11. To wpłynie na każdy element systemu operacyjnego używanego przez ponad miliard osób.
Jak do tego doszło, czyli krótka historia webowego skrętu Microsoftu
Microsoft przez lata nie miał jednej spójnej strategii tworzenia aplikacji desktopowych. Po kolejnych falach frameworków - WinForms, WPF, Silverlight, WinRT, UWP - firma ostatecznie obrała kurs na Windows App SDK i WinUI 3 jako "właściwą" drogę do budowania nowoczesnych aplikacji dla Windowsa. WinUI 3 to w pełni natywna warstwa interfejsu użytkownika, skompilowana bezpośrednio do kodu maszynowego, integrująca się z systemem bez żadnego pośrednika w postaci silnika przeglądarki.
Czytaj też:
Problem w tym, że ta droga okazała się mało uczęszczana - bo sam Microsoft z niej nie korzystał. Zamiast aplikacji opartych na WinUI w Windows 11 zaczęły mnożyć się komponenty oparte na WebView2, czyli osadzonym silniku Chromium (tym samym, który napędza Edge’a), oraz całe aplikacje zbudowane w Electronie. WebView2 pozwala osadzić stronę internetową wewnątrz okna aplikacji desktopowej, a Electron idzie o krok dalej - pakuje cały silnik Chromium razem z kodem aplikacji. Efekt? Każda taka aplikacja de facto uruchamia własną przeglądarkę.
Lista aplikacji "pozornie natywnych" jest długa. Microsoft Teams. Widżety Windowsa 11 - WebView2. Nowe Outlook - WebView2. Widok agendy w centrum powiadomień, który w Windows 10 był natywną funkcją systemu - w Windowsie 11 to WebView2. Clipchamp, wbudowany edytor wideo w Windowsa 11 - Progressive Web App.
Nawet Microsoft Copilot przeszedł prawdziwą odyseję: startował jako element Edge/WebView2, potem Microsoft ogłosił "natywną" wersję w grudniu 2024 r., która okazała się kolejną powłoką WebView używającą gigabajta RAM-u, a dopiero w marcu ubiegłego roku firma w końcu wydała aplikację zbudowaną w WinUI, która faktycznie nie ładuje komponentów webowych. Żeby jednak nie było za pięknie Copilot znów jest na drodze do stania się hybrydą z WebView.
"Natywny" znaczy co innego dla Microsoftu i dla reszty świata
Najbardziej frustrującym aspektem tej historii był nie sam kierunek zmian, lecz sposób, w jaki Microsoft o nim mówił. Firma wielokrotnie ogłaszała "natywne" wersje swoich aplikacji, które po bliższym przyjrzeniu okazywały się kolejnymi opakowaniami na kod webowy.
Partner Architect w Microsofcie odpowiedzialny za Microsoft Store i Eksploratora plików, Rudy Huyn, obiecuje, że że nowe aplikacje będą "100% native". Kiedy ktoś zapytał wprost, czy chodzi o PWA to Huyn zaprzeczył. To sygnał zmiany, bo dotychczas oficjalny przekaz Microsoftu bywał niejednoznaczny - w 2020 r. Sam Ramji z Microsoftu sugerował wręcz, że web jest "natywny" dla Windowsa, co stało się cytatem-memem w środowisku programistów.
Warto tu przytoczyć liczby, bo robią wrażenie. Typowa aplikacja Electron zużywa 150-300 MB RAM-u samym tylko runtimem, a łącznie może sięgnąć 500 MB-1 GB. Dla porównania natywna aplikacja Win32 w stanie bezczynności obciąża procesor na poziomie 0-0,1 proc., aplikacja .NET/WPF na poziomie 0,1-0,5 proc., a aplikacja Electron - 1-3 proc.. Czas startu natywnej aplikacji Win32 to 100-300 ms, WPF - 500–800 ms, WebView2 - 800 ms do 1,5 s, a Electron - 1,5 do 4 sekund. Innymi słowy: za każdym razem gdy otwierasz aplikację opartą na Electronie to czekasz dwa do czterech razy dłużej niż byś czekał(a) na aplikację natywną.
WhatsApp na Windowsa jest tu modelowym przykładem. Meta najpierw zastąpiła swoją pierwotną aplikację webową wersją napisaną w natywnym WinUI/XAML - i była ona chwalona przez Microsoft jako przykład wzorcowej aplikacji na Windowsa. Potem, po kilku latach inwestycji w natywny kod, Meta pod koniec ubiegłego roku po cichu przesiadła się z powrotem na WebView2, ładując po prostu web.whatsapp.com w oknie desktopowym. Efekt? Użycie RAM-u przez WhatsAppa po aktualizacji sięgnęło 2 GB. To cofnięcie o kilka lat w kategoriach wydajności, uzasadnione głównie cięciem kosztów po zwolnieniach w Mecie.
Dlaczego Microsoft (i wszyscy inni) szli w stronę weba
Uczciwie trzeba przyznać, że ten trend miał racjonalne podstawy. Utrzymywanie osobnych, natywnych aplikacji dla każdej platformy - Windows, macOS, iOS, Android - jest drogie i czasochłonne. Jedna wspólna baza kodu webowego pozwala wysyłać nowe funkcje jednocześnie na wszystkie platformy, obniżyć koszty QA i zmniejszyć zespoły. To czysty rachunek biznesowy: mniejsze koszty, szybszy development.
Microsoft z kolei miał dodatkowy motyw: umożliwienie deweloperom którzy nie znają unikalnych dla Windowsa frameworków szybkiego tworzenia funkcji dla systemu. WebView2 i Electron to technologie, które zna dosłownie każdy developer webowy - a tych jest nieporównanie więcej niż specjalistów od WinUI czy Win32. Wewnętrzne zespoły Microsoftu mogły dzięki temu szybciej iterować i współdzielić kod między platformami, w tym między Windowsem, Xboxem, mobile’em i webem.
Problem w tym, że te oszczędności były często przerzucane na użytkownika: w postaci wyższego zużycia RAM, wolniejszego startu aplikacji, gorszej integracji z systemem (powiadomienia, przeciąganie plików, zarządzanie energią), a przede wszystkim tego poczucia, że aplikacje "nie są częścią systemu". Brendan Eich, twórca JavaScriptu i współzałożyciel Brave'a, skomentował tę tendencję pod koniec 2025 r.: "Jestem przeciwko bloatowi wynikającemu z pochopnego używania Web UX zamiast natywnego. Da się to zrobić dobrze, ale wymaga czasu". Twórca JavaScript krytykuje nadużywanie JavaScriptu w aplikacjach desktopowych - ale ma rację.
Co to oznacza w praktyce: WinUI jako fundament
Jeśli deklaracje Huyna są poważne to naturalna baza technologiczna dla nowych aplikacji to WinUI 3 - platforma dla nowoczesnych, natywnych aplikacji desktopowych. WinUI 3 jest częścią Windows App SDK i oferuje nowoczesny zestaw kontrolek w stylu Fluent Design, natywny rendering bez silnika przeglądarki, obsługę Win32 i .NET, a od wersji 1.6 SDK - kompilację Ahead-Of-Time (AOT), która zmniejsza czas startu aplikacji o 50 proc. i redukuje rozmiar pakietu nawet ośmiokrotnie.
WinUI nie jest technologią bez problemów. Przez lata programiści narzekali na liczne błędy, brakujące funkcje i wolne tempo poprawek ze strony Microsoftu. Przeniesienie aplikacji z UWP czy starszych frameworków do WinUI 3 nieraz wymagało przepisania niemal całego kodu. Jednym z przewlekłych problemów był brak obsługi XAML Islands. Ponadto natywny development na Windowsa wciąż nie jest priorytetem w Microsofcie - issue trackery dla Windows App SDK są pełne niezałatwionych zgłoszeń.
Jest jeszcze kwestia WebView2 w kontekście "100% natywny". Nawet wiele obecnych "natywnych" aplikacji korzysta z WebView2 do renderowania pewnych fragmentów - np. dokumentów, stron internetowych czy dynamicznej zawartości. Pytanie czy Huyn ma na myśli aplikacje bez WebView w ogóle, czy aplikacje, których rdzeń logiki i UI jest natywny, a WebView służy wyłącznie do wyświetlania treści zewnętrznych - to subtelna, ale ważna różnica.
Efekt dla ekosystemu: czy trzeci deweloperzy pójdą w ślady?
To chyba najtrudniejsze pytanie. Microsoft może kontrolować własne aplikacje systemowe, ale nie może zmusić Mety, Google'a czy Slacka do porzucenia Electrona i WebView2. Jak pokazuje historia WhatsAppa - Meta zainwestowała kilka lat w natywną aplikację na Windowsa, a potem i tak ją porzuciła ze względów kosztowych.
Żeby ekosystem się zmienił Microsoft musiałby albo zaostrzyć wymagania Microsoft Store (odrzucając aplikacje oparte na webowych wrapperach), albo sprawić, że development w WinUI stanie się na tyle atrakcyjny i prosty, że deweloperzy sami z siebie wybiorą tę drogę. Dotychczasowa historia nie daje w tym zakresie za wiele optymizmu: UWP miał być natywną platformą przyszłości dla Windowsa, ale sami Microsoft długo nie używał jej w sztandarowych produktach, co było sygnałem nie do zignorowania dla zewnętrznych deweloperów.
No i cross-platform development wcale nie traci na popularności. React Native for Desktop i .NET MAUI - które Microsoft sam rekomenduje obok WinUI - to frameworki umożliwiające budowanie aplikacji działających na wielu platformach, nierzadko z użyciem komponentów webowych. Czy Microsoft będzie spójny w tym, co mówi deweloperom? To pytanie pozostaje bez jednoznacznej odpowiedzi.
