Aplikacja mobilna czy PWA: co wybrać w 2026 i czego PWA nadal nie potrafi

PWA wystarczy, gdy aplikacja pokazuje dane, przyjmuje zamówienia, rezerwacje albo formularze, korzysta z aparatu i lokalizacji tylko wtedy, gdy jest otwarta, a użytkownicy trafiają do niej z linku, maila albo kodu QR. Aplikacja ze sklepu jest potrzebna, gdy musisz działać w tle (śledzenie trasy, synchronizacja), łączyć się z urządzeniami przez Bluetooth lub NFC na iPhonie, pokazywać widżety albo gdy obecność w App Store i Google Play jest sama w sobie wymogiem klienta.

Wybór między tymi opcjami zbyt często zapada na poziomie "aplikacja brzmi poważniej". To kosztowna intuicja: aplikacja w sklepach to dwa konta deweloperskie, recenzje każdej wersji, coroczne wymagania dotyczące narzędzi i czasem prowizja od sprzedaży. PWA nie ma żadnego z tych kosztów, ale ma twarde ograniczenia, szczególnie na iPhonie. Niżej rozpisujemy jedne i drugie.

Najpierw lista funkcji, potem technologia

Decyzję ułatwia spisanie wszystkiego, co aplikacja ma robić, zanim padnie słowo "PWA" czy "natywna". Nie w formie ogólnej ("wygodna obsługa klienta"), tylko jako czynności: klient skanuje kod na paczce, kurier zapisuje trasę przez cały dzień, pracownik zatwierdza wniosek urlopowy, klient dostaje przypomnienie o wizycie dzień wcześniej.

Każdą czynność oznacz trzema pytaniami. Czy wymaga dostępu do sprzętu telefonu, a jeśli tak, to do czego: aparatu, lokalizacji, Bluetooth, NFC, czujników. Czy musi działać, gdy aplikacja jest zamknięta albo telefon leży zablokowany. Czy musi działać bez internetu, a jeśli tak, to czy chodzi o przeglądanie danych, czy o ich zapisywanie i późniejszą synchronizację.

Po tej analizie zwykle okazuje się, że o wyborze decydują jedna lub dwie funkcje, a nie cały zakres. Aplikacja z czterdziestoma ekranami formularzy i jedną funkcją śledzenia trasy w tle potrzebuje aplikacji natywnej lub cross-platformowej przez tę jedną funkcję. Aplikacja z dwoma ekranami, ale bez żadnej pracy w tle, prawdopodobnie obejdzie się bez sklepu.

Drugie pytanie to kto będzie używał aplikacji. Klienci, którzy trafiają do firmy raz lub kilka razy w roku, rzadko instalują cokolwiek ze sklepu. Pracownicy, którzy korzystają z aplikacji codziennie, zainstalują to, co każe firma. Stali użytkownicy usługi konsumenckiej, na przykład aplikacji treningowej, oczekują jej w sklepie i tam jej szukają.

Co PWA potrafi w 2026 na Androidzie i iPhonie

PWA, czyli progresywna aplikacja webowa, to strona internetowa z plikiem manifestu i skryptem działającym w tle przeglądarki (service worker). Dzięki nim można ją dodać do ekranu początkowego, uruchamiać bez paska adresu, działać częściowo offline i odbierać powiadomienia. Możliwości zależą jednak od przeglądarki i systemu, a różnice między Androidem a iPhonem są duże.

Z tabeli wynika wzór, który powtarza się w praktyce. Na Androidzie PWA ma dostęp do większości funkcji sprzętowych, więc aplikacja dla użytkowników Androida, na przykład wewnętrzna aplikacja magazynowa na firmowych urządzeniach, może obejść się bez sklepu nawet przy Bluetooth i NFC. Na iPhonie te same funkcje są niedostępne, więc aplikacja dla ogółu klientów, wśród których są użytkownicy iPhone'ów, musi uwzględniać najsłabszą platformę.

Przyczyną różnic jest silnik przeglądarki. Popularne przeglądarki na iPhonie korzystają z silnika WebKit, więc Chrome na iPhonie ma w praktyce te same możliwości co Safari. Dostęp do nowych interfejsów dla aplikacji webowych na iPhonie zależy więc od decyzji jednej firmy, a nie od wyboru przeglądarki przez użytkownika.

Tabela opisuje stan na 2026 rok i warto sprawdzić ją ponownie przy podejmowaniu decyzji. Możliwości przeglądarek zmieniają się co kilka miesięcy, a pojedyncza nowa funkcja w Safari potrafi zmienić wynik całej analizy. Aktualne wsparcie konkretnej funkcji łatwo sprawdzić w publicznych tabelach zgodności przeglądarek.

Powiadomienia push na iPhonie: działają, ale z warunkiem

Przez lata brak powiadomień push na iPhonie był głównym argumentem przeciw PWA. Od wersji iOS i iPadOS 16.4 aplikacje webowe mogą wysyłać powiadomienia, ale tylko wtedy, gdy użytkownik wcześniej dodał je do ekranu początkowego. Zwykła strona otwarta w Safari nadal nie może poprosić o zgodę na powiadomienia.

Oznacza to dwa kroki, których użytkownik iPhone'a musi dokonać sam. Najpierw otwiera stronę, wybiera menu Udostępnij i opcję dodania do ekranu początkowego. Potem uruchamia aplikację z ikony i dopiero wtedy, po kliknięciu przycisku w aplikacji, może zgodzić się na powiadomienia. Prośba o zgodę musi wynikać z działania użytkownika, więc nie można jej wyświetlić automatycznie przy starcie.

Dla części zastosowań ten proces jest akceptowalny. Pracownik, któremu firma pokaże instrukcję na szkoleniu, zrobi to raz i zapomni. Stały klient, który korzysta z usługi co tydzień, zrobi to, jeśli dostanie jasną instrukcję z obrazkami i powód, dla którego powiadomienia są mu potrzebne. Jednorazowy klient sklepu internetowego prawie na pewno tego nie zrobi.

Przed wyborem PWA z powodu powiadomień odpowiedz więc na pytanie, jaki odsetek twoich użytkowników korzysta z iPhone'ów i czy powiadomienia są dla nich wygodą, czy warunkiem działania usługi. Jeśli przypomnienie o wizycie jest miłym dodatkiem do maila i SMS-a, PWA wystarczy. Jeśli cała usługa opiera się na natychmiastowym powiadomieniu, na przykład o nowym zleceniu dla kuriera, aplikacja ze sklepu jest bezpieczniejszym wyborem.

Instalacja i dystrybucja: link kontra sklep z aplikacjami

PWA rozprowadzasz linkiem. Wysyłasz go mailem, drukujesz jako kod QR, umieszczasz na stronie. Użytkownik klika i od razu korzysta z aplikacji, bez konta w sklepie, bez pobierania kilkudziesięciu megabajtów i bez czekania. Dodanie do ekranu początkowego jest opcjonalne i może nastąpić później, gdy użytkownik uzna, że będzie wracał.

Aplikacja ze sklepu wymaga instalacji przed pierwszym użyciem. Każdy krok między kliknięciem w link a pierwszym ekranem aplikacji to miejsce, w którym część osób rezygnuje: przejście do sklepu, pobranie, uruchomienie, zgody systemowe, rejestracja. Dla usług, z których ktoś korzysta raz, na przykład zamówienia w restauracji przy stoliku, ta ścieżka jest zbyt długa.

Sklep ma jednak zalety, których link nie da. Użytkownicy wyszukują w nim aplikacje po kategorii i nazwie, więc aplikacja może być znaleziona przez osoby, które nie znają twojej firmy. Obecność w sklepie z ocenami i liczbą pobrań buduje wiarygodność. Część klientów, zwłaszcza w sprzedaży do firm, wymaga aplikacji ze sklepu, bo ich działy IT zarządzają telefonami służbowymi przez systemy dopuszczające tylko aplikacje ze sklepów.

Warto też pamiętać o linkach. Link w mailu prowadzący do konkretnego ekranu PWA działa zawsze, bo to zwykły adres strony. W aplikacji ze sklepu podobne linki trzeba skonfigurować osobno dla iOS i Androida, a gdy aplikacja nie jest zainstalowana, link musi mieć sensowny adres zastępczy. To dodatkowa praca, której PWA nie wymaga.

Koszty wejścia do sklepów: konta, testy, recenzje

Publikacja w App Store wymaga członkostwa w Apple Developer Program, które kosztuje 99 USD rocznie. Jeśli nie odnowisz członkostwa, aplikacja znika ze sklepu. Konto Google Play kosztuje jednorazowo 25 USD. Obie opłaty są niewielkie w porównaniu z kosztem wykonania aplikacji, ale konto Apple jest kosztem stałym na cały czas życia aplikacji.

Nowe konta prywatne w Google Play mają dodatkowy wymóg. Konta osobiste założone po 13 listopada 2023 roku muszą przed publikacją przeprowadzić test zamknięty z co najmniej 12 testerami, którzy są w nim zapisani nieprzerwanie przez 14 dni. Konta firmowe są z tego zwolnione. Jeśli aplikacja ma być publikowana na koncie twojej firmy, załóż konto jako organizacja, bo zaoszczędzisz dwa tygodnie i szukanie testerów.

Każda wersja aplikacji przechodzi recenzję sklepu. Recenzja Apple sprawdza zgodność z wytycznymi, w tym wymaganie minimalnej funkcjonalności: aplikacja, która jest wyłącznie opakowaną stroną internetową bez wartości dodanej, może zostać odrzucona. Odrzucenie oznacza poprawki i ponowne zgłoszenie, co przy pierwszej publikacji potrafi wydłużyć termin o kilka dni.

Do kosztów wejścia dochodzą materiały do sklepów: zrzuty ekranu w wymaganych rozmiarach, opisy, polityka prywatności, deklaracje dotyczące zbieranych danych. Apple i Google wymagają szczegółowego opisu tego, jakie dane aplikacja zbiera i do czego ich używa. To praca na styku techniki i prawa, której PWA na stronie firmy w takiej formie nie wymaga.

Prowizje sklepów: kiedy dotyczą ciebie, a kiedy nie

Sklepy z aplikacjami pobierają prowizję od sprzedaży treści i usług cyfrowych wewnątrz aplikacji. W App Store standardowa prowizja wynosi 30%, a dla deweloperów w programie dla małych firm, z przychodem do 1 mln USD rocznie, 15%. Google Play pobiera 15% od pierwszego miliona USD przychodu rocznie i 15% od subskrypcji. W Unii Europejskiej Apple udostępnia dodatkowo alternatywne warunki wynikające z aktu o rynkach cyfrowych, które zmieniają ten rachunek, więc przed decyzją sprawdź warunki aktualne dla twojego przypadku.

Prowizja nie dotyczy wszystkiego, co sprzedajesz przez aplikację. Towary fizyczne i usługi realizowane poza aplikacją, na przykład zamówienie jedzenia, przejazd, wizyta u fryzjera czy produkt ze sklepu internetowego, można opłacać zwykłymi metodami płatności, bez systemu płatności sklepu. Prowizja dotyczy treści i funkcji cyfrowych: subskrypcji premium, kursów wideo, wirtualnych przedmiotów, odblokowania funkcji.

Dla firm sprzedających usługi cyfrowe to jeden z najmocniejszych argumentów za PWA. Subskrypcja kupiona na stronie internetowej nie przechodzi przez żaden sklep, więc cała kwota trafia do ciebie, pomniejszona tylko o prowizję operatora płatności. Część firm łączy oba modele: aplikacja ze sklepu służy do korzystania z usługi, a zakup odbywa się na stronie, w granicach, na jakie pozwalają aktualne zasady sklepów.

Przykładowe wyliczenie, na założeniach przyjętych wyłącznie do ilustracji: subskrypcja za 40 zł miesięcznie, 500 aktywnych subskrybentów, prowizja sklepu 15%, prowizja operatora płatności na stronie 2%. W sklepie z aplikacjami prowizja wynosi 500 x 40 zł x 15% = 3 000 zł miesięcznie. Na stronie 500 x 40 zł x 2% = 400 zł miesięcznie. Różnica 2 600 zł miesięcznie to w skali roku 31 200 zł. Tę kwotę zestaw z kosztem wykonania i utrzymania aplikacji, zanim uznasz obecność w sklepie za oczywistą.

Utrzymanie: coroczne wymagania sklepów i szybkość aktualizacji

Aplikacja w sklepie wymaga regularnej pracy, nawet jeśli nie dodajesz funkcji. Apple od 28 kwietnia 2026 roku przyjmuje nowe aplikacje i aktualizacje tylko wtedy, gdy są zbudowane w Xcode 26 z SDK dla iOS 26. Google Play od 31 sierpnia 2026 roku wymaga, żeby nowe aplikacje i aktualizacje były przeznaczone dla Androida 16 (API 36). Oba sklepy podnoszą te wymagania co roku.

W praktyce oznacza to, że aplikacja, której nikt nie aktualizował przez rok, przestaje dać się zaktualizować bez dostosowania do nowych narzędzi. Gdy pojawi się pilny błąd, najpierw trzeba podnieść wersje narzędzi i bibliotek, a dopiero potem naprawić problem. Warto zaplanować to w budżecie jako stałą pozycję, a nie niespodziankę raz na rok.

PWA tego problemu nie ma. Aktualizacja to wdrożenie nowej wersji na serwer i przy kolejnym uruchomieniu użytkownicy dostają nową wersję, bez recenzji i bez czekania, aż ktoś kliknie "aktualizuj". Poprawka krytycznego błędu trafia do wszystkich w ciągu minut. W aplikacji ze sklepu ta sama poprawka czeka na recenzję, a potem na to, aż użytkownicy zainstalują aktualizację.

Aplikacje pisane we frameworkach cross-platformowych mogą częściowo zmniejszyć tę różnicę. Zmiany w warstwie interfejsu i logice aplikacji da się w wielu przypadkach wysłać bezpośrednio do użytkowników, bez pełnej recenzji, w granicach, na jakie pozwalają zasady sklepów. Zmiany dotyczące natywnych modułów, uprawnień i wersji systemu nadal wymagają nowej wersji w sklepie.

Offline, praca w tle i dostęp do sprzętu

Tryb offline w PWA działa dobrze, gdy chodzi o przeglądanie danych. Service worker może zapisać ekrany i dane w pamięci urządzenia, więc aplikacja otwiera się bez internetu i pokazuje ostatnio pobrane informacje. Można też zapisywać wprowadzone dane lokalnie i wysłać je na serwer przy następnym uruchomieniu z dostępem do sieci.

Problem zaczyna się, gdy dane mają zostać wysłane bez udziału użytkownika. Na Androidzie PWA może zsynchronizować zaległe dane w tle, gdy wróci połączenie. Na iPhonie ten mechanizm nie jest dostępny, więc dane wyślą się dopiero po ponownym otwarciu aplikacji. Dla serwisanta, który wypełnia protokoły w piwnicy bez zasięgu i zamyka aplikację przed wyjściem, oznacza to ryzyko, że dane dotrą na serwer dopiero następnego dnia.

Praca w tle to granica, której PWA nie przekracza na żadnej platformie. Śledzenie lokalizacji przy zablokowanym ekranie, liczenie kroków, odtwarzanie i kontrola dźwięku jak w dedykowanych odtwarzaczach, okresowa synchronizacja danych, reagowanie na zbliżenie do określonego miejsca: to wszystko wymaga aplikacji ze sklepu. Jeśli którakolwiek z tych funkcji jest w twoim zakresie, dalsza analiza nie jest potrzebna.

Dostęp do sprzętu dzieli się według platform. Aparat, mikrofon, lokalizacja przy otwartej aplikacji, wibracje i orientacja ekranu działają w PWA wszędzie. Bluetooth i NFC działają w Chrome na Androidzie, ale nie na iPhonie. Integracje z danymi zdrowotnymi, zegarkami, systemem samochodowym czy asystentem głosowym są dostępne tylko dla aplikacji natywnych.

Kiedy PWA wystarczy

PWA jest dobrym wyborem dla narzędzi wewnętrznych firmy. Panel dla handlowców, aplikacja do zgłaszania usterek, zatwierdzanie wniosków, podgląd zamówień i stanów magazynowych. Użytkownicy są znani, można im pokazać, jak dodać aplikację do ekranu, a firma unika publikacji w sklepach aplikacji, która nie jest przeznaczona dla nikogo spoza zespołu. Kiedy takie narzędzie ma sens w miejsce arkusza, opisujemy we wpisie panel zamiast arkusza.

Drugi przypadek to usługi, z których klient korzysta okazjonalnie lub jednorazowo. Zamówienie przy stoliku, rezerwacja terminu, śledzenie przesyłki, zgłoszenie reklamacji, formularz rejestracji na wydarzenie. Klient trafia do usługi z linku lub kodu QR i nie chce niczego instalować. Każdy krok instalacji zmniejsza liczbę osób, które dotrą do końca.

Trzeci przypadek to produkty cyfrowe sprzedawane w subskrypcji, dla których prowizja sklepu byłaby dużym kosztem, a funkcje nie wymagają pracy w tle. Platformy kursów, narzędzia do planowania, systemy rezerwacji dla firm, dashboardy analityczne. Tu PWA pozwala zatrzymać całą marżę i aktualizować produkt bez recenzji.

Czwarty przypadek to test produktu przed inwestycją w aplikację. PWA z kluczowymi funkcjami pozwala sprawdzić, czy użytkownicy wracają, które funkcje są używane i czy powiadomienia mają sens. Te dane są znacznie lepszą podstawą do decyzji o aplikacji w sklepach niż założenia z etapu pomysłu.

Kiedy potrzebujesz aplikacji w sklepie

Aplikacja ze sklepu jest konieczna, gdy funkcja podstawowa wymaga pracy w tle. Aplikacje dla kierowców i kurierów śledzące trasę, aplikacje treningowe rejestrujące aktywność, aplikacje do monitorowania urządzeń, które muszą reagować na zdarzenia przy zablokowanym ekranie. Tych funkcji nie da się obejść w przeglądarce.

Druga sytuacja to połączenie z urządzeniami fizycznymi, gdy wśród użytkowników są posiadacze iPhone'ów. Sterowanie urządzeniami przez Bluetooth, odczyt tagów NFC, parowanie sprzętu IoT. Na Androidzie część tych rzeczy da się zrobić w PWA, ale produkt dla ogółu klientów nie może pomijać iPhone'ów.

Trzecia sytuacja to aplikacje, w których powiadomienia są rdzeniem usługi, a użytkownicy są konsumentami, którym nie da się przeprowadzić szkolenia. Komunikatory, aplikacje dla kurierów przyjmujących zlecenia, aplikacje z alertami bezpieczeństwa. Wymóg dodania PWA do ekranu przed włączeniem powiadomień na iPhonie oznacza, że część użytkowników nigdy ich nie dostanie.

Czwarta sytuacja jest biznesowa, a nie techniczna. Klient korporacyjny wymaga aplikacji w sklepie, bo zarządza telefonami pracowników przez system, który dopuszcza tylko aplikacje ze sklepów. Produkt konsumencki konkuruje z aplikacjami, które użytkownicy znajdują w sklepie, i obecność tam jest częścią strategii dotarcia. W takich przypadkach aplikacja ze sklepu jest potrzebna niezależnie od tego, co potrafi przeglądarka.

Droga pośrednia: PWA teraz, aplikacja w sklepie później

Wybór nie musi być ostateczny. Najważniejsza decyzja architektoniczna to oddzielenie backendu, czyli serwera z danymi i logiką biznesową, od aplikacji, która go wyświetla. Jeśli PWA komunikuje się z serwerem przez API, aplikacja natywna lub cross-platformowa zbudowana później korzysta z tego samego API i tych samych danych. Praca włożona w backend nie przepada.

Na Androidzie PWA można opublikować w Google Play bez przepisywania, jako Trusted Web Activity. To lekka aplikacja, która wyświetla PWA w pełnym ekranie, bez paska przeglądarki, a w sklepie wygląda jak każda inna aplikacja. Dla wielu zastosowań to wystarczy, żeby być w sklepie Google przy zerowym koszcie przepisywania interfejsu.

Na iPhonie podobne opakowanie jest ryzykowne. Wytyczne App Store wymagają minimalnej funkcjonalności wykraczającej poza stronę internetową, a aplikacja będąca wyłącznie opakowaną stroną może zostać odrzucona. Jeśli potrzebujesz aplikacji w App Store, zaplanuj funkcje, które uzasadniają jej istnienie: powiadomienia, integracje z systemem, działanie offline wykraczające poza stronę.

Warto też uwzględnić ryzyko po stronie platform. Na początku 2024 roku Apple zapowiedziało wyłączenie aplikacji webowych dodanych do ekranu początkowego dla użytkowników w Unii Europejskiej, a po kilku tygodniach wycofało się z tej decyzji. Epizod pokazał, że możliwości PWA na iPhonie zależą od decyzji jednej firmy. Dla narzędzia wewnętrznego to akceptowalne ryzyko, dla produktu, na którym opiera się cały biznes, argument za posiadaniem planu awaryjnego.

Jak przygotować zapytanie o wycenę i ile to kosztuje

Wycena aplikacji zależy od liczby ekranów, funkcji sprzętowych, integracji i platform, a wybór między PWA a aplikacją ze sklepu zmienia ją bardziej niż którakolwiek pojedyncza funkcja. Dlatego zapytanie o wycenę najlepiej oprzeć na liście funkcji z pierwszej sekcji tego artykułu, z zaznaczeniem, które z nich wymagają pracy w tle, Bluetooth, NFC albo powiadomień.

PWA to aplikacja webowa, więc wycenia się ją podobnie jak platformę internetową albo panel. Nasze ceny zaczynają się od: Aplikacje Mobilne od 749 zł, Platformy Internetowe od 899 zł, Panele i Dashboardy od 699 zł, Integracje i Automatyzacje od 299 zł. To wartości "od" dla najprostszego zakresu, a nie pakiety. Przy ogólnym zarysie podajemy widełki, a konkretną kwotę po ustaleniu zakresu, terminu i wymagań. Zakresy opisujemy na stronach aplikacji mobilnych, platform internetowych i paneli.

Rozliczenie najczęściej dzielimy na trzy części: zaliczka, połowa projektu i oddanie. W cenie jest zapas na poprawki równy 15% czasu projektu, a w trakcie pracy masz dostęp do repozytorium i wersji testowej. Po oddaniu dostajesz pełne prawa do kodu i dokumentację, więc aplikację może rozwijać inny wykonawca, a monitoring działania jest darmowy, najczęściej przez 90 dni. Na życzenie podpisujemy NDA.

Jeśli nie wiesz, czy twój projekt wymaga aplikacji w sklepie, wyślij listę funkcji przez formularz kontaktowy. Wycena jest bezpłatna, odpowiadamy w ciągu godziny i rozmawiasz z osobą, która pisze kod, więc pytanie o to, czy dana funkcja zadziała w PWA na iPhonie, dostaje odpowiedź od razu, a nie po przekazaniu dalej.