Budujesz aplikację dla Windows, ale nie chcesz zamykać sobie drogi do Androida i macOS? .NET MAUI pozwala tworzyć natywne aplikacje desktopowe i mobilne w C# oraz XAML, korzystając ze wspólnego kodu. Pokażę, jak działa na Windowsie, kiedy ma sens, jak wygląda konfiguracja, wdrażanie oraz gdzie pojawiają się kompromisy względem WPF i WinUI 3.
Jedna baza kodu może obsłużyć Windows i urządzenia mobilne
- Windows korzysta z WinUI 3, więc aplikacja nie jest zwykłą stroną uruchomioną w przeglądarce.
- C# i XAML pozwalają współdzielić interfejs, logikę biznesową, testy i dostęp do usług.
- Projekt single project porządkuje konfigurację wielu platform w jednym projekcie.
- MSIX lub publikacja do folderu dają dwie główne drogi dystrybucji aplikacji na Windows.
- WPF lub WinUI 3 mogą być lepszym wyborem, gdy aplikacja ma działać wyłącznie na Windowsie.
Czym naprawdę jest .NET MAUI na Windowsie
.NET MAUI to framework do budowy aplikacji natywnych dla Androida, iOS, macOS oraz Windows. Wspólny kod obejmuje zwykle widoki, modele, logikę biznesową i komunikację z API, natomiast każda platforma może mieć własne fragmenty implementacji. Nie jest to emulacja Windowsa, tylko warstwa, która mapuje kontrolki na elementy właściwe dla danego systemu.
W przypadku Windows aplikacja korzysta z WinUI 3, czyli nowoczesnej biblioteki interfejsu działającej w ramach Windows App SDK. Dzięki temu przyciski, pola tekstowe czy listy są obsługiwane przez mechanizmy systemu Windows, a program może korzystać także z platformowych API.
Największą zaletą jest model single project. Zamiast utrzymywać osobny projekt dla Windows, Androida i iOS, pracuję w jednej strukturze, w której konfiguracja oraz kod wspólny znajdują się obok katalogów platformowych. Microsoft opisuje to jako jeden system zarządzania konfiguracją aplikacji wieloplatformowej.
W praktyce współdzielenie kodu nie oznacza, że wszystko powinno być identyczne. Interfejs aplikacji magazynowej może wyglądać podobnie na telefonie i komputerze, ale sposób obsługi myszy, klawiatury, menu kontekstowego czy wielu okien będzie już inny. Wspólna baza jest punktem wyjścia, a nie zakazem korzystania z natywnych możliwości Windows.
Co trzeba przygotować przed utworzeniem projektu
Do rozpoczęcia pracy potrzebujesz komputera z Windowsem, zgodnej wersji .NET SDK oraz środowiska z workloadem .NET Multi-platform App UI development. Najwygodniejszym wyborem pozostaje Visual Studio, ponieważ zapewnia szablony projektów, debugowanie, emulator oraz obsługę narzędzi Windows App SDK.
Aplikacje Windows budowane za pomocą tej technologii wymagają systemu Windows 10 w wersji 1809 lub nowszej. Do samego tworzenia aplikacji najlepiej używać aktualnego Windows 11, ponieważ łatwiej wtedy testować wygląd, skalowanie i zachowanie kontrolek zgodne z obecnym środowiskiem użytkownika.
Minimalny przebieg konfiguracji
- Zainstaluj Visual Studio z workloadem przeznaczonym do tworzenia aplikacji .NET MAUI.
- Utwórz projekt typu .NET MAUI App.
- Wybierz Windows jako cel uruchomienia.
- Uruchom aplikację bezpośrednio z Visual Studio i sprawdź zachowanie przy zmianie rozmiaru okna.
- Dodaj dopiero później kod specyficzny dla Windows, jeśli wspólne API nie wystarcza.
W nowym projekcie znajdziesz między innymi katalogi Platforms/Windows, pliki XAML dla widoków oraz klasy usług. Ja zwykle zaczynam od uruchomienia pustej aplikacji i sprawdzenia procesu publikacji, zanim dołożę logowanie, bazę danych czy rozbudowaną nawigację. Wczesne wykrycie problemu z SDK oszczędza później sporo czasu.
Prosty widok i logika w C#
Interfejs można opisać w XAML, a zachowanie kontrolować z poziomu C#. Przykładowy widok może zawierać pole tekstowe oraz przycisk:
W kodzie obsługi wystarczy zmienić zawartość etykiety:
private void OnSaveClicked(object sender, EventArgs e)
{
StatusLabel.Text = $"Zapisano: {NameEntry.Text}";
}Taki przykład jest prosty, ale pokazuje ważną rzecz. Widok nie musi wiedzieć, gdzie trafiają dane. W większej aplikacji logikę przenoszę do ViewModelu, a zapis do osobnego serwisu. Dzięki temu ten sam kod może obsłużyć Windows i urządzenie mobilne bez kopiowania całych ekranów.
Do jakich aplikacji desktopowych ten framework pasuje najlepiej
Najlepiej sprawdza się tam, gdzie aplikacja ma mieć kilka wydań, ale zespół chce utrzymywać jedną logikę biznesową. Dobrym przykładem jest panel klienta, aplikacja do obsługi zamówień, prosty system magazynowy, narzędzie terenowe z wersją mobilną albo wewnętrzny program korzystający z firmowego API.
Jeżeli aplikacja działa głównie na formularzach, listach, kartach, wykresach i ekranach ustawień, produktywność może być bardzo dobra. Szczególnie doceniam możliwość współdzielenia modeli, walidacji, autoryzacji i komunikacji z backendem napisanym w ASP.NET Core.
Trudniej robi się wtedy, gdy program ma być typowym narzędziem windowsowym. Rozbudowane menu aplikacji, wiele niezależnych okien, zaawansowana integracja z paskiem zadań, obsługa drukowania, globalne skróty klawiszowe czy głęboka integracja z systemem mogą wymagać kodu platformowego.
Nie traktuję tego jako wady samej w sobie. Problem pojawia się dopiero wtedy, gdy ktoś zakłada, że aplikacja wieloplatformowa będzie w 100 procentach wspólna. W realnym projekcie rozsądny podział to często 80-95 procent kodu współdzielonego, a reszta przeznaczona na różnice systemowe. Dokładny wynik zależy od charakteru interfejsu.
.NET MAUI, WPF czy WinUI 3
Wybór technologii powinien wynikać z docelowych platform, wieku istniejącego kodu i rodzaju interfejsu. Sam fakt, że aplikacja działa na Windowsie, nie oznacza jeszcze, że framework wieloplatformowy będzie najlepszą opcją.
| Technologia | Najlepsze zastosowanie | Największa zaleta | Ograniczenie |
|---|---|---|---|
| .NET MAUI | Windows plus Android, iOS lub macOS | Wspólny kod C# i XAML | Różnice między platformami wymagają dodatkowej pracy |
| WPF | Rozbudowane aplikacje wyłącznie dla Windows | Dojrzały ekosystem i duża liczba bibliotek | Brak naturalnej ścieżki do aplikacji mobilnych |
| WinUI 3 | Nowoczesne aplikacje skupione na Windows | Bezpośredni dostęp do aktualnego stosu Windows | Windows pozostaje jedyną główną platformą |
| Blazor Hybrid | Aplikacje z interfejsem HTML, CSS i Razor | Możliwość wykorzystania kompetencji webowych | Trzeba świadomie kontrolować wydajność i zachowanie WebView |
Do nowego systemu firmowego działającego tylko na komputerach wybrałbym WPF albo WinUI 3, jeśli najważniejsza jest pełna zgodność z Windows. Gdy jednak ten sam produkt ma trafić także na telefony, MAUI daje wyraźną przewagę organizacyjną, bo model domenowy, API i znaczna część widoków pozostają wspólne.
Blazor Hybrid jest ciekawym wariantem, gdy zespół dobrze zna Razor i CSS. Nie wybierałbym go jednak automatycznie. Dla aplikacji mocno formularzowej może przyspieszyć pracę, ale dla interfejsu wymagającego bardzo płynnych animacji i typowo natywnego zachowania klasyczne kontrolki XAML bywają prostszym rozwiązaniem.
Jak zaprojektować aplikację, żeby dobrze działała na komputerze
Najczęstszy błąd polega na przeniesieniu układu mobilnego na duży monitor. Na Windowsie użytkownik oczekuje sensownego wykorzystania szerokości, wygodnej pracy klawiaturą i przewidywalnego zachowania okna. Dlatego projektuję ekran tak, aby dobrze reagował na rozmiar okna, skalowanie DPI i orientację treści.
Układ, który skaluje się razem z oknem
Zamiast ustawiać sztywne szerokości, lepiej korzystać z układów opartych na proporcjach, marginesach i ograniczeniach maksymalnej szerokości. Formularz rozciągnięty od lewej do prawej krawędzi monitora zwykle wygląda źle, więc centralną zawartość warto ograniczyć, a obok niej przeznaczyć miejsce na listę lub panel szczegółów.
Na komputerze przydają się także skrót klawiszowy, fokus i nawigacja klawiszem Tab. Interfejs może wyglądać atrakcyjnie, ale jeśli użytkownik musi za każdym razem sięgać po mysz, praca z dużą liczbą rekordów szybko staje się męcząca.
Gdzie umieścić kod windowsowy
Do zwykłych scenariuszy używam wspólnych abstrakcji frameworka. Gdy potrzebuję zmienić sposób działania kontrolki tylko w Windows, korzystam z handlerów. Handler to warstwa łącząca kontrolkę .NET MAUI z jej natywnym odpowiednikiem, dzięki czemu można dostosować wygląd lub zachowanie bez kopiowania całego widoku.
Inną drogą jest kod w katalogu Platforms/Windows. To dobre miejsce na funkcje zależne od systemu, takie jak integracja z plikami, powiadomieniami, oknem aplikacji czy mechanizmami Windows App SDK. Ważne, aby nie rozrzucać takich wywołań po całym kodzie biznesowym.
Najczytelniejszy układ to interfejs usługi w kodzie wspólnym i implementacje platformowe poniżej. Dzięki temu reszta aplikacji wie, że ma na przykład otworzyć plik lub wyświetlić powiadomienie, ale nie musi znać szczegółów Windows.
Publikowanie aplikacji na Windows
Po zakończeniu programowania zostają dwie główne decyzje. Możesz opublikować aplikację do folderu razem z zależnościami albo przygotować pakiet MSIX, który ułatwia instalację, aktualizacje i dystrybucję w środowisku Windows.
Publikacja do folderu
Wariant folderowy bywa wygodny w firmowej sieci, na serwerze plików albo podczas wdrażania wewnętrznego. Trzeba jednak zadbać o dostarczenie wszystkich zależności oraz dobrać właściwą architekturę, na przykład win-x64 albo win-arm64.
Publikacja samodzielna zawiera również runtime .NET, więc użytkownik nie musi instalować go osobno. Zwiększa to rozmiar paczki, ale upraszcza wdrożenie. Wersja zależna od frameworka jest mniejsza, lecz wymaga odpowiedniego środowiska na komputerze odbiorcy.
Przeczytaj również: Execution policy w PowerShellu - jak bezpiecznie uruchamiać skrypty
Pakiet MSIX
MSIX lepiej pasuje do aplikacji, która ma być instalowana przez większą grupę użytkowników. Oferuje uporządkowany proces instalacji i może współpracować z kanałami dystrybucji Windows. Trzeba jednak pamiętać o certyfikacie podpisu, konfiguracji pakietu oraz uprawnieniach wymaganych przez aplikację.
W dokumentacji Microsoftu publikowanie aplikacji Windows obejmuje zarówno wdrożenie do folderu, jak i przygotowanie pakietu MSIX. Ja przed wyborem sprawdzam, kto będzie instalował program, jak często ma się aktualizować i czy środowisko firmowe akceptuje instalatory pakietowe.
Sam proces publikacji nie powinien być testowany dopiero w dniu premiery. Już na początku warto sprawdzić instalację na czystej maszynie, brakujące runtime’y, dostęp do plików, uprawnienia oraz działanie aktualizacji. Aplikacja uruchamiająca się w Visual Studio nie zawsze jest gotowa do dystrybucji.
Kiedy wybrać tę technologię, a kiedy odpuścić
Wybrałbym ją, gdy planujesz co najmniej dwie platformy, zespół zna C# i XAML, a aplikacja ma współdzielić logikę biznesową. To także dobry kierunek dla projektu, który zaczyna się od Windowsa, ale w roadmapie ma wersję mobilną.
Zachowałbym ostrożność przy aplikacji wyłącznie windowsowej, która ma działać jak klasyczne narzędzie administracyjne z wieloma oknami, rozbudowanym drukowaniem i głęboką integracją z systemem. W takim przypadku WPF może oznaczać mniej ryzyka, szczególnie gdy organizacja ma już doświadczenie i gotowe biblioteki.
Nie wybierałbym też frameworka tylko dlatego, że obiecuje jeden kod na wszystko. Przed decyzją buduję mały prototyp z najtrudniejszym ekranem, logowaniem, dostępem do plików oraz publikacją. Jeśli prototyp przejdzie te testy, dopiero wtedy warto inwestować w pełną aplikację.
Windows jako pierwszy cel bez zamykania drogi na przyszłość
Najrozsądniejsze podejście polega na rozpoczęciu od doświadczenia użytkownika na Windowsie, ale od początku oddzieleniu logiki biznesowej od platformy. Dzięki temu aplikacja może wyglądać jak porządny program desktopowy, a nie jak mobilny ekran powiększony do rozmiaru monitora.
W 2026 roku .NET MAUI jest sensownym wyborem dla zespołów, które potrzebują wspólnej aplikacji C# dla Windows i innych systemów. Nie zastępuje WPF ani WinUI 3 w każdym scenariuszu, lecz dobrze łączy świat aplikacji desktopowych i mobilnych. Najważniejsza decyzja nie dotyczy samego frameworka, tylko zakresu platform i oczekiwanej integracji z Windowsem.
Jeżeli masz jedną aplikację, kilka docelowych systemów i kontrolę nad architekturą, zacznij od małego prototypu oraz testu wdrożenia. To najszybciej pokaże, czy wspólny kod rzeczywiście skróci pracę, czy wymagania desktopowe będą wymagały technologii stricte windowsowej.
