Dyrektor operacyjny sieci laboratoriów prosi o „nowoczesną aplikację w przeglądarce” w miejsce systemu, który od dwunastu lat działa na komputerach w punktach pobrań. Zespół buduje prototyp w trzy miesiące. Wygląda świetnie, dopóki nie trafia do pierwszego punktu: drukarka etykiet z kodami kreskowymi wymaga sterownika, czytnik podpięty jest do portu szeregowego, a łącze w mniejszych miejscowościach znika kilka razy dziennie. Po kolejnych dwóch miesiącach powstaje „agent lokalny”, mała usługa instalowana na każdym komputerze, która pośredniczy między przeglądarką a sprzętem. Firma ma teraz aplikację webową i aplikację desktopową naraz, tyle że ta druga nie została nigdy zaprojektowana.
Odwrotna historia jest równie częsta. Firma od lat utrzymuje aplikację w WinForms, bo „użytkownicy są przyzwyczajeni”. Każda aktualizacja wymaga obejścia komputerów albo skryptu administratora, połowa floty pracuje na wersji sprzed roku, a nowe funkcje trafiają do ludzi z kwartalnym opóźnieniem. Nic w tej aplikacji nie wymaga desktopu: to formularze i raporty nad bazą danych.
Ten artykuł jest dla CTO, który stoi przed decyzją „desktop czy web” albo wie już, że potrzebuje desktopu, i wybiera technologię. Broni dwóch tez, z którymi można się nie zgodzić. Pierwsza: aplikacja desktopowa w 2026 roku wygrywa z webem tylko w czterech konkretnych sytuacjach, a poza nimi jest kosztownym przyzwyczajeniem. Druga: gdy desktop jest uzasadniony, pierwszą decyzją nie jest framework interfejsu, tylko sposób dystrybucji, podpisywania i aktualizacji. To ta część pochłania budżet przez lata, a wybór między Electronem a Tauri jest przy niej drugorzędny.
Dlaczego w 2026 roku w ogóle wraca pytanie o aplikację desktopową?
Przez ostatnią dekadę domyślna odpowiedź brzmiała: buduj w przeglądarce. Aplikacja webowa nie wymaga instalacji, aktualizuje się przy odświeżeniu strony, działa na każdym systemie i nie trzeba nikogo prosić o uprawnienia administratora. Ta odpowiedź była słuszna dla większości systemów biznesowych i nadal jest.
Pytanie wraca z kilku powodów. Po pierwsze, technologie wieloplatformowe dojrzały. Electron, który według dokumentacji projektu łączy w jednym pliku binarnym Chromium i Node.js i tworzy aplikacje działające na Windows, macOS i Linuksie, stał się podstawą wielu powszechnie używanych narzędzi. Tauri w wersji 2.0, wydanej 2 października 2024 roku, objął poza desktopem także iOS i Androida. Flutter kompiluje natywne aplikacje na Windows, macOS i Linuksa. Zbudowanie aplikacji na trzy systemy przestało oznaczać trzy zespoły.
Po drugie, zmieniło się środowisko Windows. Windows 10 Home i Pro według kalendarza cyklu życia Microsoftu przestał być wspierany 14 października 2025 roku. Firmy, które przy tej okazji wymieniają sprzęt i obrazy systemu, przeglądają też stare aplikacje desktopowe i pytają, co z nimi zrobić. (Samą migrację starszych aplikacji z .NET Framework omówimy w osobnym wpisie; tutaj zajmujemy się decyzją o nowej aplikacji.)
Po trzecie, rośnie liczba zastosowań, w których praca lokalna znów ma znaczenie: przetwarzanie dużych plików, integracja ze sprzętem w produkcji i logistyce, modele AI uruchamiane na urządzeniu, środowiska o ograniczonej łączności. Część z nich da się obsłużyć w przeglądarce, część nie.
Po czwarte wreszcie, koszt dystrybucji desktopu wzrósł, a nie zmalał. Wymagania wobec podpisywania kodu zaostrzono, a systemy operacyjne coraz mocniej blokują niepodpisane pliki. To argument przeciw desktopowi, ale także powód, dla którego decyzję trzeba podejmować świadomie, a nie z przyzwyczajenia.
W jakich sytuacjach aplikacja desktopowa nadal wygrywa z webem?
Proponujemy prosty test: aplikacja desktopowa jest uzasadniona, gdy zachodzi co najmniej jeden z czterech warunków. Jeśli nie zachodzi żaden, ciężar dowodu leży po stronie desktopu.
Warunek pierwszy: sprzęt i system plików. Aplikacja musi rozmawiać z urządzeniem albo z systemem w sposób, którego przeglądarka nie umożliwia lub umożliwia tylko w niektórych przeglądarkach. Typowe przykłady: drukarki etykiet i paragonów ze specyficznymi sterownikami, czytniki kart i kodów, urządzenia pomiarowe na porcie szeregowym, skanery dokumentów, kamery przemysłowe, praca na katalogach z tysiącami plików, integracja z innymi programami zainstalowanymi na tym samym komputerze. Przeglądarka ma interfejsy do części z tych zadań, ale ich dostępność zależy od przeglądarki, a sterowników nie obsłuży wcale.
Warunek drugi: offline jako norma. Nie chodzi o to, że łącze czasem znika, tylko o to, że praca bez sieci jest normalnym trybem: serwisant w piwnicy, inspektor na budowie, punkt sprzedaży z niestabilnym łączem, statek, kopalnia, hala z ekranowaniem. Aplikacja webowa z obsługą offline jest możliwa, ale jej koszt rośnie szybko, gdy dane mają być edytowane lokalnie przez wiele godzin, a potem scalane.
Warunek trzeci: lokalna wydajność na dużych danych. Edycja obrazów medycznych, modele CAD, analiza wielogigabajtowych plików, montaż, symulacje, praca z lokalną bazą liczącą miliony rekordów z wymaganiem natychmiastowej reakcji interfejsu. Przeglądarka ma dziś WebAssembly i dostęp do GPU, ale aplikacja natywna nadal daje większą kontrolę nad pamięcią, wątkami i dostępem do dysku.
Warunek czwarty: kontrola środowiska. Firma musi wiedzieć dokładnie, jaka wersja aplikacji i jakiego silnika renderującego działa na danym stanowisku, bo wymaga tego walidacja, certyfikacja albo regulacja. Albo przeciwnie: stanowisko jest zamknięte, bez przeglądarki i bez dostępu do internetu, a aplikacja ma działać jak urządzenie.
Zwróć uwagę, czego na tej liście nie ma. Nie ma „lepszego wyglądu”, „szybszego działania” w zwykłych formularzach ani „przyzwyczajenia użytkowników”. Nowoczesna aplikacja webowa może wyglądać i reagować równie dobrze jak desktopowa, a przyzwyczajenie to argument za dobrym projektem interfejsu, nie za konkretną platformą.
Kiedy desktop jest kosztownym przyzwyczajeniem, a nie potrzebą?
Gdy aplikacja jest w istocie zestawem formularzy, list i raportów nad centralną bazą danych, a użytkownicy pracują przy stałym łączu, desktop prawie zawsze przegrywa rachunek całkowitego kosztu posiadania. Każda wersja musi trafić na każdy komputer. Każdy system operacyjny i każda jego wersja to osobna konfiguracja do testowania. Każda zmiana certyfikatu podpisującego to ryzyko, że użytkownicy zobaczą ostrzeżenie systemu.
Najdroższy objaw tego przyzwyczajenia to rozjechana flota. Gdy aktualizacje nie są automatyczne, po roku część stanowisk pracuje na wersji bieżącej, część na poprzedniej, a kilka na wersji sprzed dwóch lat, bo ktoś wyłączył aktualizacje „na chwilę”. Zespół musi wtedy utrzymywać zgodność serwera z kilkoma wersjami klienta naraz, a zgłoszenia błędów zaczynają się od pytania „jaką wersję pan ma”.
Drugi objaw to ukryty koszt wsparcia. W aplikacji webowej błąd naprawiony rano jest naprawiony dla wszystkich po południu. W desktopowej naprawa wymaga nowego wydania, podpisania, dystrybucji i czekania, aż użytkownicy zrestartują aplikację. Jeśli w kalkulacji całkowitego kosztu posiadania tej różnicy nie ma, porównanie jest niepełne. Szerzej o tym, które koszty ujawniają się dopiero po wdrożeniu, piszemy w tekście o całkowitym koszcie posiadania oprogramowania.
Jest też sytuacja pośrednia, która często prowadzi do złej decyzji: aplikacja w 90% jest zwykłym systemem biznesowym, a w 10% potrzebuje sprzętu. Zamiast budować całość jako desktop, warto rozważyć aplikację webową z małym, dobrze zaprojektowanym komponentem lokalnym, który obsługuje wyłącznie sprzęt. To ten sam „agent lokalny” z historii na początku artykułu, tyle że zaplanowany od pierwszego dnia, z własnym procesem podpisywania i aktualizacji. Taki komponent bywa tańszy niż pełny desktop, ale tylko wtedy, gdy jest naprawdę mały.
Czy PWA wystarczy zamiast instalowanej aplikacji?
Progresywna aplikacja webowa (PWA) jest kuszącym kompromisem: działa w przeglądarce, ale może mieć własne okno, ikonę i pamięć podręczną do pracy offline. Na macOS od Safari 17 każdą stronę można dodać do Docka, a według bloga WebKit taka strona zawsze otwiera się wtedy we własnym oknie jako aplikacja, nawet jeśli nie ma pliku manifestu. W Chrome i Edge PWA instaluje się podobnie od dawna.
Ograniczenia zaczynają się przy dostępie do plików i sprzętu. File System Access API, czyli interfejs pozwalający stronie otworzyć plik lub katalog użytkownika i zapisywać w nim zmiany, według caniuse.com działa w Chrome (w pełni od wersji 105) i innych przeglądarkach opartych na Chromium, ale nie w Firefoksie ani w Safari. Dokumentacja MDN opisuje też prywatny system plików źródła (OPFS), czyli magazyn widoczny tylko dla danej strony, zoptymalizowany pod wydajność, który jednak nie zastąpi pracy na plikach użytkownika. Podobnie jest z interfejsami do urządzeń: WebUSB według caniuse.com działa w Chrome od wersji 61, ale nie w Firefoksie ani w Safari, a interfejsy do portów szeregowych i Bluetooth też są dostępne tylko w części przeglądarek, a sterowników producenta nie obsłużą w ogóle.
Wniosek jest praktyczny. PWA wystarcza, gdy firma kontroluje przeglądarkę na stanowiskach (na przykład wszędzie jest Edge lub Chrome zarządzany przez politykę), aplikacja potrzebuje dostępu do plików, ale nie do sterowników, a praca offline polega na przeglądaniu i krótkiej edycji danych. PWA nie wystarcza, gdy użytkownicy pracują na Macach z Safari i potrzebują pracy na plikach, gdy aplikacja musi obsłużyć urządzenie przez sterownik producenta albo gdy offline oznacza wiele godzin edycji z późniejszym scalaniem.
Dodatkowy argument za PWA w narzędziach wewnętrznych: cały proces podpisywania kodu i dystrybucji, opisany niżej, w ogóle znika. To często największa oszczędność w całym projekcie.
Jakie technologie desktopowe realnie wchodzą w grę w 2026 roku?
Jeśli test z poprzednich sekcji wskazuje desktop, wybór technologii warto zawęzić do siedmiu opcji. Każda ma swój naturalny obszar zastosowań.
WPF i WinForms (.NET). Dojrzałe technologie Microsoftu do aplikacji wyłącznie na Windows, działające na współczesnym .NET. Ogromna baza bibliotek, kontrolek komercyjnych i programistów, którzy je znają. Rozsądny wybór, gdy aplikacja ma działać tylko na Windows, a zespół zna C#. Warto pamiętać o cyklu wsparcia .NET: według polityki Microsoftu wydania LTS mają trzy lata bezpłatnego wsparcia, a wydania STS dwa lata. .NET 10 (LTS) wydano 11 listopada 2025 roku ze wsparciem do 14 listopada 2028 roku, a .NET 8 i .NET 9 kończą wsparcie 10 listopada 2026 roku. Nowa aplikacja powinna więc startować na .NET 10.
WinUI 3 (Windows App SDK). Nowsza warstwa interfejsu Microsoftu dla Windows, z wyglądem zgodnym z Windows 11. Tak jak WPF działa tylko na Windows. Ma sens, gdy aplikacja ma wyglądać jak część współczesnego systemu i korzystać z jego nowych funkcji.
.NET MAUI. Wieloplatformowy framework Microsoftu. Według dokumentacji obsługuje Androida, iOS, macOS (12 lub nowszy, przez Mac Catalyst) oraz Windows 11 i Windows 10 od wersji 1809, gdzie korzysta z WinUI 3. Nie obsługuje Linuksa. Ma sens, gdy jedna baza kodu C# ma obsłużyć Windows, Maca i urządzenia mobilne.
Electron. Aplikacja pisana w technologiach webowych (HTML, CSS, JavaScript), z własną kopią Chromium i Node.js w pakiecie. Działa tak samo na Windows, macOS i Linuksie. Pozwala współdzielić kod z aplikacją webową i korzystać z zespołu frontendowego. Ceną jest rozmiar pakietu, zużycie pamięci i obowiązek śledzenia wydań: według dokumentacji projektu nowa wersja główna wychodzi co 8 tygodni, a zespół Electrona wspiera trzy najnowsze stabilne wersje główne.
Tauri. Także interfejs w technologiach webowych, ale bez własnej przeglądarki: korzysta z WebView dostępnego w systemie, a warstwa natywna jest w Rust. Dokumentacja podaje, że minimalna aplikacja może mieć poniżej 600 KB. Od wersji 2.0 obsługuje także iOS i Androida.
Qt. Dojrzały framework C++ (z interfejsem w QML lub widgetach), od lat używany w aplikacjach przemysłowych, medycznych, motoryzacyjnych i wszędzie tam, gdzie liczy się wydajność i praca blisko sprzętu. Dostępny na licencji komercyjnej albo na LGPL v3 (część modułów tylko na GPL v3), co ma konsekwencje omówione niżej.
Flutter desktop. Framework Google w języku Dart, który według dokumentacji kompiluje natywne aplikacje na Windows, macOS i Linuksa. Rysuje interfejs własnym silnikiem, więc wygląda identycznie na każdym systemie. Naturalny wybór, gdy firma ma już aplikację mobilną we Flutterze i chce dodać wersję desktopową.
Kilka słów o licencji Qt, bo bywa źle rozumiana. Użycie Qt na LGPL v3 w produkcie zamkniętym jest możliwe, ale sekcja licencji o „dziełach połączonych” wymaga między innymi, by biblioteka była łączona przez mechanizm bibliotek współdzielonych, który zadziała ze zmodyfikowaną, zgodną interfejsowo wersją biblioteki, albo by zapewnić równoważną możliwość ponownego zlinkowania. Przy urządzeniach zamkniętych mogą dojść obowiązki dotyczące tak zwanych informacji instalacyjnych. Przed decyzją warto dać to do przeglądu prawnikowi, a jeśli spełnienie warunków byłoby niepraktyczne, wpisać do budżetu licencję komercyjną.
Jeśli rozważasz także wspólny system komponentów dla aplikacji webowej i desktopowej, warto najpierw ocenić, czy skala to uzasadnia; piszemy o tym w artykule o koszcie i zwrocie z design systemu.
Jak porównać te technologie na jednej tabeli?
Poniższa tabela porządkuje opcje według kryteriów, które w praktyce przesądzają o wyborze. Opisuje typowe cechy, a nie wynik pomiarów konkretnej aplikacji; rozmiar i zużycie pamięci zależą od tego, co aplikacja robi.
| Technologia | Systemy | Język i kompetencje | Silnik interfejsu | Mocna strona | Główne ryzyko |
|---|---|---|---|---|---|
| WPF / WinForms | Windows | C#, .NET | natywny Windows | dojrzałość, biblioteki, dostępni programiści | tylko Windows, wygląd starszej generacji |
| WinUI 3 | Windows | C#, C++ | natywny Windows | wygląd i funkcje Windows 11 | tylko Windows, mniejsza baza kontrolek |
| .NET MAUI | Windows, macOS, iOS, Android | C#, .NET | natywne kontrolki per system | jedna baza kodu z mobilnymi | brak Linuksa, różnice między platformami |
| Electron | Windows, macOS, Linux | JavaScript/TypeScript | dołączone Chromium | identyczne renderowanie, kod wspólny z webem | rozmiar, pamięć, wydania co 8 tygodni |
| Tauri | Windows, macOS, Linux, iOS, Android | front webowy + Rust | systemowy WebView | mały pakiet, model uprawnień | różnice WebView między systemami, kompetencje Rust |
| Qt | Windows, macOS, Linux, systemy wbudowane | C++, QML | własny | wydajność, praca blisko sprzętu | licencja, dostępność programistów C++ |
| Flutter desktop | Windows, macOS, Linux | Dart | własny silnik | spójność z aplikacją mobilną Flutter | mniejszy ekosystem wtyczek desktopowych |
Z tabeli wynika prosta heurystyka. Tylko Windows i zespół .NET: WPF lub WinUI 3. Windows i Mac oraz aplikacje mobilne w jednym kodzie C#: .NET MAUI. Trzy systemy desktopowe i zespół webowy: Electron lub Tauri. Praca blisko sprzętu, wysokie wymagania wydajności albo systemy wbudowane: Qt. Istniejąca aplikacja mobilna we Flutterze: Flutter desktop.
Heurystyka nie zastąpi jednak sprawdzenia, kto będzie tę aplikację utrzymywał przez następne pięć lat. Technologia, której nie zna nikt w firmie ani u dostawcy, jest ryzykiem niezależnie od zalet technicznych. Szerzej o tym, dlaczego ekosystem często waży więcej niż sam język, piszemy w artykule o ekosystemie języka programowania.
Electron czy Tauri: co naprawdę zyskujesz, wybierając lżejszy framework?
To najczęstszy spór przy aplikacjach z interfejsem webowym i warto go rozebrać na czynniki, bo obie strony mają rację w innych sprawach.
Za Electronem przemawia przewidywalność. Aplikacja zawsze renderuje się w tej samej wersji Chromium, którą dołączyłeś do pakietu. Błąd wyświetlania, który widzisz na Windows, zobaczysz też na Macu i Linuksie, a testy interfejsu przeprowadzasz raz. Ekosystem jest ogromny, a zespół frontendowy może pisać aplikację bez nauki nowego języka. Warstwa natywna w Node.js daje dostęp do systemu plików, procesów i bibliotek natywnych.
Przeciw Electronowi przemawia ciężar. Każda aplikacja niesie własną kopię silnika przeglądarki, co przekłada się na rozmiar instalatora i zużycie pamięci. Ważniejsze z perspektywy CTO jest jednak tempo: przy wersji głównej co 8 tygodni i wsparciu trzech najnowszych wersji aplikacja, która nie dostaje aktualizacji silnika przez mniej więcej pół roku, wypada poza okno wsparcia. Każda aktualizacja Electrona to nowa wersja Chromium, czyli poprawki bezpieczeństwa, ale też potencjalne zmiany zachowania, które trzeba przetestować. Ten koszt trzeba wpisać do budżetu utrzymania, a nie odkrywać go w drugim roku.
Za Tauri przemawia lekkość i model bezpieczeństwa. Brak dołączonej przeglądarki oznacza małe instalatory, a warstwa natywna w Rust daje bezpieczeństwo pamięci. Mechanizm aktualizacji jest od początku oparty na podpisach: dokumentacja wtyczki aktualizacji mówi wprost, że podpis weryfikujący pochodzenie aktualizacji jest wymagany i nie można go wyłączyć.
Przeciw Tauri przemawia zależność od systemowego WebView. Na Windows to WebView2 oparty na silniku Edge, na macOS silnik Safari, a na Linuksie WebKit (webkit2gtk). Trzy silniki oznaczają trzy zestawy różnic w renderowaniu i obsłudze funkcji, więc testy interfejsu trzeba prowadzić na każdym systemie osobno. Na Windows dochodzi pytanie o obecność środowiska WebView2: według dokumentacji Microsoftu wersja Evergreen jest częścią Windows 11 i jest zainstalowana na zdecydowanej większości urządzeń z Windows 10, ale nie na wszystkich, więc instalator powinien to sprawdzić. Druga kwestia to kompetencje: część logiki natywnej trzeba napisać w Rust, a programistów Rust jest mniej niż programistów JavaScriptu.
Jak rozstrzygnąć? Jeśli aplikacja ma działać na zarządzanych stanowiskach firmowych, gdzie pamięć nie jest problemem, a zespół jest webowy, Electron daje mniejsze ryzyko projektowe. Jeśli aplikacja trafia do szerokiego grona użytkowników zewnętrznych, rozmiar pobierania ma znaczenie, a zespół jest gotów zainwestować w Rust i testy na trzech silnikach, Tauri daje lepszy produkt. W obu przypadkach o kosztach utrzymania zdecyduje bardziej potok wydawniczy niż framework.
Dlaczego dystrybucja i podpisywanie kodu kosztują więcej niż interfejs?
To sedno drugiej tezy artykułu. Interfejs budujesz raz i rozwijasz stopniowo. Potok dystrybucji obsługujesz przy każdym wydaniu, na każdym systemie, przez cały okres życia aplikacji. Jeśli działa źle, użytkownicy widzą ostrzeżenia bezpieczeństwa, administratorzy blokują instalację, a każda poprawka trafia do ludzi z opóźnieniem.
Windows. Microsoft Defender SmartScreen ocenia pobrane pliki według reputacji wydawcy i reputacji konkretnego pliku. Według dokumentacji Microsoftu niepodpisana aplikacja wyświetla ostrzeżenie „System Windows ochronił komputer” i użytkownik musi wybrać uruchomienie mimo to, a polityka firmowa może całkowicie to zablokować. Nawet podpisana nowa aplikacja może początkowo pokazywać ostrzeżenie, dopóki nie zbierze reputacji, co według tej samej dokumentacji może zająć kilka tygodni i setki czystych instalacji. Ważna zmiana, o której wiele firm nie wie: certyfikaty EV nie omijają już SmartScreen, więc dopłata za EV wyłącznie z tego powodu nie ma uzasadnienia. Aplikacje dystrybuowane przez Microsoft Store są podpisywane certyfikatem Microsoftu i nie wywołują ostrzeżeń. Poza sklepem Microsoft rekomenduje usługę Artifact Signing (dawniej Trusted Signing), która według dokumentacji kosztuje od 9,99 USD miesięcznie i integruje się z potokami CI/CD bez fizycznego tokenu.
Formatem pakietu na Windows jest MSIX. Według dokumentacji Microsoftu zapewnia czystą instalację i deinstalację, aktualizacje różnicowe (pobierane są tylko zmienione bloki 64 KB) i wdrażanie przez Intune oraz Configuration Manager, a każdy pakiet MSIX musi być podpisany przed instalacją. Na Windows 11 dochodzi Smart App Control, który według Microsoftu blokuje niepodpisane pliki bez pozytywnej reputacji.
Certyfikaty i klucze. Wymagania CA/Browser Forum dla certyfikatów podpisywania kodu od 1 czerwca 2023 roku nakazują przechowywanie klucza prywatnego w sprzętowym module kryptograficznym. Od 1 marca 2026 roku certyfikat podpisywania kodu nie może być ważny dłużej niż 460 dni. W praktyce oznacza to, że klucza nie można już trzymać w pliku na laptopie programisty, a odnawianie certyfikatu staje się zdarzeniem mniej więcej corocznym, które trzeba zaplanować w potoku wydawniczym.
macOS. Gatekeeper według Apple sprawdza, czy aplikacja pobrana spoza Mac App Store ma certyfikat Developer ID, a domyślnie akceptuje oprogramowanie podpisane przez zarejestrowanego dewelopera i notaryzowane przez Apple. Certyfikat Developer ID może wygenerować tylko właściciel konta zespołu w Apple Developer Program, który kosztuje 99 USD rocznie. Notaryzacja polega na przesłaniu podpisanej aplikacji do automatycznej usługi Apple, która skanuje ją i wydaje bilet rozpoznawany przez Gatekeepera. Od 1 listopada 2023 roku usługa przyjmuje zgłoszenia wyłącznie przez narzędzie notarytool (lub Xcode 14 i nowsze). Na potrzeby budżetu: notaryzacja wymaga dostępu do konta Apple i komputera z macOS w potoku budowania.
Linux. Kanałów jest kilka (pakiety dystrybucji, AppImage, Flatpak, Snap) i każdy ma inne zasady. Jeśli Linux nie jest wymaganiem biznesowym, warto świadomie go nie obsługiwać, zamiast obsługiwać go „przy okazji”.
Kto za to wszystko odpowiada? To pytanie trzeba zadać przed wyborem frameworka. Konto Apple, certyfikat lub usługa podpisywania na Windows, sprzętowy moduł kluczy, potok CI/CD budujący i podpisujący wersje na każdy system, procedura odnowienia certyfikatu, procedura na wypadek kompromitacji klucza. Te elementy powinny być zapisane w umowie z dostawcą razem z informacją, czyje są konta i klucze. Jeśli należą do dostawcy, zmiana dostawcy oznacza zmianę tożsamości wydawcy, utratę reputacji w SmartScreen i ostrzeżenia u użytkowników. Więcej o tym, jak nie uzależnić się od jednego wykonawcy, piszemy w artykule o vendor lock-in.
Jak zaprojektować aktualizacje, żeby flota nie rozjechała się na pięć wersji?
Aktualizacje to miejsce, w którym desktop najczęściej przegrywa z webem w praktyce, choć wcale nie musi. Kilka decyzji warto podjąć na etapie architektury.
Kanał aktualizacji. Każda z omawianych technologii ma swój mechanizm. Electron według dokumentacji oferuje wbudowany moduł autoUpdater oparty na frameworku Squirrel, a zespół Electrona utrzymuje bezpłatną usługę update.electronjs.org dla aplikacji open source, której jednym z warunków jest podpisanie kodu na macOS. Tauri ma wtyczkę aktualizacji z obowiązkowym podpisem: klucz prywatny podpisuje pakiety, a klucz publiczny w konfiguracji aplikacji je weryfikuje. Dokumentacja ostrzega, że utrata klucza prywatnego oznacza brak możliwości publikowania aktualizacji dla istniejących instalacji. Pakiety MSIX mogą aktualizować się przez App Installer bez sklepu albo przez narzędzia zarządzania flotą.
Polityka wersji. Ustal z góry, ile wersji klienta serwer musi obsługiwać jednocześnie, i egzekwuj to. Typowe rozwiązanie: aplikacja przy starcie sprawdza minimalną obsługiwaną wersję i jeśli jest starsza, wymusza aktualizację z jasnym komunikatem. Bez tego mechanizmu serwer musi być zgodny wstecz bez końca.
Kanały wydań. Grupa pilotażowa dostaje nowe wersje kilka dni wcześniej niż reszta. To najtańsze zabezpieczenie przed błędem, który wyłączy pracę całej firmy. W środowiskach zarządzanych grupy te można zdefiniować w Intune lub innym narzędziu.
Zależności z własnym cyklem. Pamiętaj, że w aplikacji desktopowej starzeją się nie tylko twój kod, ale i silnik. W Electronie to Chromium aktualizowane razem z frameworkiem. W Tauri i aplikacjach WinUI z WebView2 silnik aktualizuje system: według Microsoftu środowisko Evergreen WebView2 aktualizuje się automatycznie, a aplikacja zaczyna używać nowej wersji dopiero po restarcie. Aplikacja, która działa bez przerwy przez tygodnie (na przykład w punkcie obsługi), może więc korzystać ze starszego silnika z niezałataną podatnością, jeśli nie obsłuży zdarzenia o dostępności nowej wersji. W .NET to cykl LTS i STS opisany wyżej.
Obserwowalność. Telemetria wersji (ile stanowisk działa na której wersji) i raportowanie awarii z podziałem na wersje i systemy to warunek, żeby wiedzieć, czy polityka aktualizacji działa. Bez tego dowiesz się o rozjechanej flocie z eskalacji.
Dobrze zaprojektowane aktualizacje sprawiają, że różnica między desktopem a webem w czasie dostarczania poprawek spada z tygodni do godzin. Źle zaprojektowane są głównym powodem, dla którego firmy po kilku latach chcą „przenieść wszystko do przeglądarki”.
Jak zaprojektować pracę offline i synchronizację danych?
Jeśli powodem wyboru desktopu jest praca offline, to ona, a nie interfejs, jest najtrudniejszą częścią projektu. Trzy decyzje przesądzają o kosztach.
Co jest źródłem prawdy. W najprostszym modelu serwer jest źródłem prawdy, a aplikacja trzyma lokalną kopię tylko do odczytu, odświeżaną przy połączeniu. To tanie i bezpieczne. W modelu z lokalną edycją aplikacja zapisuje zmiany w lokalnej bazie (często SQLite) i wysyła je po odzyskaniu łącza. To droższe, bo wymaga rozwiązania konfliktów.
Jak rozwiązywać konflikty. Gdy dwie osoby offline zmieniły ten sam rekord, ktoś musi zdecydować, która zmiana wygrywa. Opcje to: ostatni zapis wygrywa (prosty, ale gubi dane), scalanie na poziomie pól, kolejka konfliktów do ręcznego rozstrzygnięcia przez użytkownika albo struktury danych zaprojektowane tak, by scalały się automatycznie. Wybór zależy od tego, jak często konflikty mogą wystąpić i ile kosztuje utrata zmiany. W systemie inspekcji technicznej utrata wpisu może mieć skutki prawne; w lokalnym koszyku zamówień wystarczy prosta reguła.
Jak długo stanowisko może być offline. Ta liczba powinna trafić do wymagań. Inna architektura obsłuży godzinę bez sieci, inna tydzień. Od niej zależy także bezpieczeństwo: lokalna baza z danymi osobowymi wymaga szyfrowania, a uprawnienia użytkownika zapisane lokalnie muszą mieć termin ważności, żeby zwolniony pracownik nie miał dostępu do danych przez tydzień tylko dlatego, że jego laptop nie łączył się z serwerem.
Model danych dla pracy offline warto projektować na samym początku. Dodanie lokalnej edycji do aplikacji zaprojektowanej jako „zawsze online” to w praktyce przebudowa warstwy danych, a nie nowa funkcja. Jeśli aplikacja ma obsługiwać wielu klientów biznesowych z separacją danych, podobne decyzje opisujemy w artykule o architekturze SaaS i izolacji danych.
Co zmienia dostęp do sprzętu i integracja z systemem operacyjnym?
Integracja ze sprzętem to drugi najczęstszy powód wyboru desktopu i zarazem źródło ryzyk, których nie widać w makietach interfejsu.
Sterowniki i biblioteki producenta. Urządzenia przemysłowe, medyczne i fiskalne często dostarczają własne biblioteki, zwykle dla Windows, czasem tylko dla jednej architektury procesora. To może przesądzić o technologii: jeśli producent dostarcza bibliotekę .NET lub C++, najprościej integrować się z nią z aplikacji w .NET lub Qt. Z Electrona i Tauri też się da, ale przez dodatkową warstwę (moduły natywne Node.js albo kod w Rust), którą trzeba utrzymywać.
Architektury procesorów. Komputery z procesorami ARM są coraz częstsze zarówno w świecie Apple, jak i Windows. Jeśli biblioteka producenta istnieje tylko dla x64, aplikacja na ARM będzie działać w emulacji albo wcale. Sprawdź to przed wyborem sprzętu i technologii, a nie przed wdrożeniem.
Uprawnienia i izolacja. Systemy operacyjne coraz mocniej izolują aplikacje. Na macOS dostęp do kamery, mikrofonu, wybranych katalogów czy funkcji dostępności wymaga zgody użytkownika. Na Windows aplikacje w pakiecie MSIX mogą działać w lekkim kontenerze z wirtualizacją systemu plików i rejestru. To dobrze dla bezpieczeństwa, ale oznacza, że aplikacja, która działała w testach z uprawnieniami programisty, może nie działać u użytkownika.
Macierz testów. Każda kombinacja systemu, wersji, architektury i urządzenia to potencjalny przypadek testowy. Na etapie planowania określ, które kombinacje są wspierane oficjalnie, a które nie, i zaplanuj stanowiska testowe z prawdziwym sprzętem. Emulator urządzenia nie wykryje problemu ze sterownikiem drukarki, który ujawnia się dopiero przy setnym wydruku.
W tej części projektu najbardziej opłaca się krótki etap rozpoznania przed właściwą budową: prototyp, który łączy się z każdym urządzeniem z listy na docelowym systemie. Kosztuje ułamek budżetu, a eliminuje ryzyko, że wybrana technologia nie obsłuży kluczowego sprzętu.
Ile kosztuje budowa i utrzymanie aplikacji desktopowej i jak wybrać wykonawcę?
Koszt aplikacji desktopowej zależy od tych samych czynników co każdego oprogramowania (zakres, integracje, jakość), ale ma trzy pozycje, których w aplikacji webowej nie ma albo są mniejsze: obsługę kilku systemów operacyjnych, potok podpisywania i dystrybucji oraz testy na rzeczywistym sprzęcie.
Przykład ilustracyjny, a nie wycena. Zespół złożony z dwóch seniorów full-stack, seniora QA i DevOps na pół etatu, odpowiedzialnego za potok budowania i podpisywania. Według cennika ARDURA senior full-stack kosztuje 1 520–2 160 zł netto za dzień, senior QA 1 440–2 000 zł, a senior DevOps 1 600–2 240 zł. Przyjmując środki przedziałów i 21 dni roboczych w miesiącu: dwóch programistów to około 77 300 zł, QA około 36 100 zł, połowa etatu DevOps około 20 200 zł, razem około 133 600 zł netto miesięcznie. Do tego dochodzą stałe koszty platform: 99 USD rocznie za Apple Developer Program, opłata za usługę podpisywania na Windows i stanowiska testowe z docelowym sprzętem.
Jak czytać tę liczbę? Udział DevOps i QA jest wyższy niż w typowej aplikacji webowej właśnie z powodu dystrybucji i macierzy testów. Jeśli oferta na aplikację desktopową na dwa lub trzy systemy nie zawiera nikogo odpowiedzialnego za potok wydawniczy, ten koszt nie zniknął, tylko pojawi się później w postaci ręcznych wydań i ostrzeżeń u użytkowników. Ogólne zasady szacowania i modele rozliczeń przy oprogramowaniu na zamówienie opisujemy w przewodniku po oprogramowaniu dedykowanym.
Wybierając wykonawcę aplikacji desktopowej, zadaj pytania, które oddzielają doświadczenie w desktopie od doświadczenia w webie:
- Jak wygląda Wasz potok budowania i podpisywania dla każdego z docelowych systemów i gdzie przechowywane są klucze?
- Na czyje konta (Apple, usługa podpisywania na Windows) będzie wydawana aplikacja i jak przebiega przekazanie przy zakończeniu współpracy?
- Jaki mechanizm aktualizacji proponujecie i jak wymusicie minimalną wersję klienta?
- Jak testujecie na rzeczywistym sprzęcie i na których kombinacjach systemu i architektury?
- Jak obsłużycie aktualizacje silnika (Chromium, WebView2, .NET) w budżecie utrzymania?
- Jaki model pracy offline i rozwiązywania konfliktów proponujecie dla naszego przypadku i dlaczego?
Dobra odpowiedź na te pytania jest konkretna i odwołuje się do decyzji, a nie do listy technologii w portfolio.
Jakie są kluczowe wnioski przed decyzją o aplikacji desktopowej?
Aplikacja desktopowa w 2026 roku nie jest ani reliktem, ani domyślnym wyborem. Jest narzędziem do czterech konkretnych zadań, a poza nimi kosztuje więcej niż aplikacja webowa i dostarcza mniej.
Zapamiętaj sześć rzeczy. Po pierwsze, sprawdź cztery warunki: sprzęt i system plików, offline jako norma, lokalna wydajność na dużych danych, kontrola środowiska. Jeśli żaden nie zachodzi, buduj w przeglądarce. Po drugie, rozważ wariant pośredni: aplikację webową z małym komponentem lokalnym do obsługi sprzętu albo PWA w środowisku z kontrolowaną przeglądarką. Po trzecie, technologię wybieraj według systemów docelowych i kompetencji zespołu, który będzie ją utrzymywał przez lata, a nie według popularności. Po czwarte, zaprojektuj dystrybucję i podpisywanie przed pierwszą linią interfejsu: konta, klucze w sprzętowym module, certyfikaty odnawiane co najwyżej co 460 dni, notaryzacja na macOS, MSIX lub sklep na Windows. Po piąte, zaprojektuj aktualizacje z wymuszaniem minimalnej wersji, kanałem pilotażowym i telemetrią wersji. Po szóste, jeśli powodem jest offline lub sprzęt, zacznij od prototypu, który rozwiązuje właśnie ten problem, zanim zainwestujesz w resztę.
Jeśli stoisz przed decyzją „desktop czy web” albo wybierasz technologię dla aplikacji, która musi działać na kilku systemach i współpracować ze sprzętem, zobacz, jak pracujemy w tworzeniu oprogramowania na zamówienie, lub umów rozmowę. Każdy projekt zaczynamy od fazy discovery, która trwa 1–2 tygodnie i kończy się zakresem oraz architekturą, w tym decyzją o platformie, dystrybucji i sposobie aktualizacji.