Scenariusz, który znamy z rozmów z klientami: firma chce aplikację mobilną, bo „konkurencja ma" i „klienci są na telefonach". Sześć do dwunastu miesięcy developmentu, dwa sklepy, review Apple'a, budżet liczony w setkach tysięcy złotych. A po premierze okazuje się, że użytkownicy korzystają z trzech spośród dwudziestu funkcji i większość nigdy nie otwiera aplikacji po pierwszym tygodniu. Jest sposób, żeby odkryć te trzy funkcje przed wydaniem budżetu, a nie po: Progressive Web App. W tym artykule pokazujemy, dlaczego PWA to najlepszy pierwszy krok na drodze do aplikacji mobilnej: ile kosztuje, ile trwa i jakie decyzje pozwala podjąć na danych zamiast na przeczuciach.
Czym jest PWA (bez żargonu)
Progressive Web App to strona internetowa, która zachowuje się jak aplikacja. Użytkownik może dodać ją do ekranu głównego telefonu (bez wizyty w sklepie), dostaje ikonę, pełnoekranowy interfejs bez paska przeglądarki, działanie offline i powiadomienia push. Pod spodem to wciąż technologia webowa: jeden kod, który działa na iPhonie, Androidzie i desktopie.
Nie jest to technologiczna ciekawostka. Z PWA korzystają lub korzystały X (Twitter), Pinterest, Uber, Tinder, Starbucks czy AliExpress. Firmy te publikowały twarde wyniki, do których wrócimy niżej.
Najważniejsza właściwość PWA w kontekście tego artykułu jest jednak inna: PWA to produkt, nie prototyp. Ta sama aplikacja, którą walidujesz pomysł, obsługuje potem realnych klientów. A jeśli dane pokażą, że opłaca się iść w sklepy, ten sam kod da się w nich opublikować. Ale po kolei.
Korzyść #1: Time to market liczony w tygodniach, nie kwartałach
Budowa pary aplikacji natywnych to dwa równoległe projekty (Swift na iOS, Kotlin na Android), dwa zespoły albo jeden dwukrotnie wolniejszy, do tego backend i proces review w sklepach. PWA to jeden projekt webowy, co widać w liczbach z realnych wdrożeń:
- Tinder zbudował MVP swojej aplikacji webowej w trzy miesiące i zmierzył, że użytkownicy webu swipe'ują i piszą więcej niż w aplikacjach natywnych, przy porównywalnej skłonności do zakupów (perfplanet).
- Pinterest przebudował cały mobilny web do postaci PWA w trzy miesiące (case study).
- Hulu przeszło z aplikacji desktopowych na PWA siłami jednego developera w dwa tygodnie (Google, Learn PWA).
Do tego dochodzi coś, czego nie widać w harmonogramie developmentu, a co potrafi zjeść tygodnie: cykl wydawniczy. Aplikacja w sklepie przechodzi review przy każdej aktualizacji; poprawka błędu u wszystkich użytkowników to kwestia dni. W PWA aktualizacja to deploy: działa u wszystkich natychmiast. A dystrybucja to link: możesz go wysłać mailem, umieścić w reklamie, wydrukować jako QR na opakowaniu. Zero „wejdź do sklepu, wyszukaj, zainstaluj, poczekaj".
Korzyść #2: Ułamek kosztów i zero prowizji pośredników
Uczciwie: nie istnieje niezależne badanie kosztów developmentu, są dane agencji. Najbardziej przejrzyste publikuje Netguru (mediana z ponad 200 własnych projektów, dane z 2026 r.): cross-platformowe MVP aplikacji mobilnej (z logowaniem, API i 8–12 ekranami) to mediana ok. 76 000 USD, a dwa osobne buildy natywne podnoszą koszt o 30–40%. Do tego utrzymanie: ok. 15–20% kosztu budowy rocznie (Netguru). Szacunki branżowe dla PWA mówią o koszcie niższym o 30–70% względem pary aplikacji natywnych, bo to jeden kod, jeden zespół i jedna rzecz do utrzymywania zamiast dwóch.
Osobny rozdział to prowizje sklepów, które płacisz nie raz, ale od każdej transakcji, przez cały cykl życia produktu:
- Apple App Store: standardowo 30%, dla małych firm (do 1 mln USD przychodu rocznie) 15% (Apple).
- Google Play: 15% do 1 mln USD rocznie, wyżej 30%, przy czym od 30 czerwca 2026 r. w EOG, UK i USA obowiązuje nowa struktura: dla nowych instalacji 10% + 5% opłaty za billing (Google).
- W USA po procesie Epic v. Apple linki do płatności poza aplikacją są legalne, ale w grudniu 2025 r. sąd apelacyjny orzekł, że Apple może pobierać od nich „rozsądną" opłatę; jej wysokość wciąż jest w zawieszeniu.
Wniosek praktyczny: ekonomia sklepów jest w ciągłym ruchu i pilnują jej regulatorzy oraz sądy. Płatność w PWA to płatność na Twojej stronie: z prowizją operatora płatności (rzędu 1–2%), a nie platformy (15–30%). Przy modelu subskrypcyjnym ta różnica potrafi przesądzić o rentowności całego produktu.
Jak to wygląda w zestawieniu:
| PWA | Cross-platform (np. React Native) | 2× natywna (iOS + Android) | |
|---|---|---|---|
| Czas do MVP | tygodnie | 3–5 miesięcy | 4–8+ miesięcy |
| Codebase | jeden (web) | jeden + mostki natywne | dwa osobne |
| Dystrybucja | link / QR / SEO | sklepy (review) | sklepy (review) |
| Aktualizacje | natychmiast (deploy) | review sklepu | review sklepu |
| Prowizja od płatności | operator płatności ~1–2% | 15–30% platformy | 15–30% platformy |
| Koszt względny | najniższy | ~60–70% kosztu dual-native | najwyższy (+30–40% vs cross-platform) |
Korzyść #3: Dane do decyzji, zanim wydasz właściwy budżet
To najważniejsza sekcja tego artykułu. Statystyki rynku aplikacji są brutalne: według klasycznego badania Quettra (2015, Android) przeciętna aplikacja traci 77% dziennych użytkowników w trzy dni od instalacji, a 90% w miesiąc (Andrew Chen). Z kolei badanie comScore dla rynku USA pokazało, że połowa użytkowników smartfonów nie pobiera ani jednej nowej aplikacji w typowym miesiącu (TechCrunch). Zanim zainwestujesz w produkt, który musi pokonać taki opór, lepiej wiedzieć o nim jak najwięcej.
PWA pozwala to zmierzyć na realnych użytkownikach:
- Czy to w ogóle produkt „appkowy"? Prompt „dodaj do ekranu głównego" to naturalny test popytu na instalację. Jeśli użytkownicy nie chcą instalować darmowej PWA jednym tapnięciem, nie zainstalują też aplikacji ze sklepu.
- Które funkcje żyją, a które są martwe? Analityka webowa (lejki, mapy zachowań) pokaże, z czego użytkownicy naprawdę korzystają. Specyfikacja ewentualnej aplikacji natywnej powstaje potem na danych: chuda i trafna, zamiast „wszystkiego, co może się przydać".
- Retencja i częstotliwość powrotów, czyli odpowiedź na pytanie, czy Twój produkt wytrzyma statystykę „77% odchodzi w 3 dni".
- Engagement powiadomień push (na Androidzie bez ograniczeń, na iOS po instalacji). Goibibo zmierzyło, że użytkownicy retargetowani pushem konwertują 4× lepiej (web.dev).
- Ruch i konwersja z SEO i reklam, bo PWA, w przeciwieństwie do aplikacji, jest indeksowalna przez Google. Każda podstrona to potencjalne wejście z wyszukiwarki; aplikacja w sklepie jest z tego ruchu wykluczona.
Bywa też, że walidacja daje wynik przewrotny: web okazuje się lepszym produktem końcowym niż aplikacja. MishiPay (samoobsługowe zakupy skanowaniem telefonu) po przejściu z aplikacji natywnej na PWA odnotował 10-krotny wzrost liczby transakcji, bo przy kasie nikt nie chce instalować aplikacji; ostatecznie 92,7% transakcji szło przez web, a przez obie aplikacje natywne łącznie ~7% (web.dev).
Co osiągały firmy, które zaczęły od webu
Klasyczne, wielokrotnie cytowane wyniki pochodzą z lat 2016–2017. Mają już swoje lata, ale skala mówi sama za siebie:
- Twitter Lite: +65% stron na sesję, +75% publikowanych tweetów, −20% bounce rate; PWA ważyła 600 KB wobec 23,5 MB aplikacji natywnej (web.dev).
- Pinterest: +60% core engagement i +44% przychodów reklamowych po przebudowie na PWA (case study).
- AliExpress: +104% konwersji nowych użytkowników, +82% konwersji na iOS (web.dev).
Z nowszych: Rakuten 24 (2020) raportował +200% konwersji i +150% sprzedaży na klienta wśród użytkowników, którzy zainstalowali PWA (web.dev), a JD.ID +53% konwersji mobile (Google). Do liczb z porównań „instalujący vs nieinstalujący" podchodź z rezerwą (najbardziej zaangażowani instalują chętniej), ale trend jest jednoznaczny.
Czego PWA nie zrobi: uczciwa lista
PWA nie jest odpowiedzią na wszystko i lepiej wiedzieć to przed decyzją niż po:
- Głęboka integracja sprzętowa. Web Bluetooth, NFC czy synchronizacja w tle nie działają na iOS. Kamera, geolokalizacja i płatności działają; opaska fitness po Bluetooth nie.
- Powiadomienia push na iOS mają warunek. Działają od iOS 16.4 (2023), ale tylko dla PWA dodanej do ekranu głównego (WebKit), a iOS nie podpowiada instalacji tak aktywnie jak Android (użytkownik musi sam wybrać „Dodaj do ekranu początkowego").
- Obecności w App Store nie będzie. Wytyczne Apple wprost odrzucają „przepakowane strony" (Guideline 4.2). Do App Store wejdziesz dopiero hybrydą (o tym za chwilę).
- Gry, AR i ciężkie obliczenia: tu natywna wydajność wciąż wygrywa.
- Dla porządku: po zamieszaniu wokół DMA w 2024 r. Apple ostatecznie utrzymało wsparcie PWA w Unii Europejskiej; status na dziś jest stabilny (Apple).
Zasada kciuka: jeśli Twój produkt to głównie treść, formularze, rezerwacje i transakcje, PWA pokryje 90–100% potrzeb. Jeśli rdzeniem jest sprzęt, tło i offline-first, planuj aplikację natywną od razu, świadomie.
PWA to nie ślepa uliczka: ścieżka migracji
Najczęstsza obawa: „a jak PWA chwyci, to będziemy budować wszystko od nowa?". Nie, i to z dwóch powodów.
Po pierwsze: serce aplikacji już masz. Aplikacja mobilna to z perspektywy użytkownika ekran, ale z perspektywy budżetu ekran jest wierzchołkiem góry lodowej. Pod spodem żyje wszystko, co stanowi o wartości produktu: API, logika biznesowa, baza danych, konta i logowanie, płatności, integracje z systemami zewnętrznymi, panel administracyjny. Budując PWA, budujesz to wszystko, bo PWA jest klientem tego samego zaplecza, którego potrzebowałaby aplikacja natywna. I to zaplecze nie jest prototypem: działa w produkcji, obsłużyło realnych użytkowników, przeszło przez realne przypadki brzegowe.
Konsekwencja jest fundamentalna: ewentualna aplikacja natywna nie jest „budową produktu od nowa", tylko kolejną nakładką na gotowe rozwiązanie. Zespół mobilny nie projektuje logiki biznesowej, nie stawia backendu i nie wymyśla modelu danych. Konsumuje istniejące, udokumentowane, przetestowane API, dokładnie tak jak robi to PWA. Zakres projektu „aplikacja" kurczy się do samego interfejsu, czyli do najmniejszej i najlepiej policzalnej części całości. To dlatego drugi klient tego samego API kosztuje ułamek pierwszego produktu.
Po drugie: sam interfejs też ma ścieżkę migracji, od najtańszej do najgłębszej:
- Google Play od zaraz: technologia Trusted Web Activity pozwala opublikować PWA w sklepie Google praktycznie bez zmian w kodzie (Chrome). Microsoft Store działa analogicznie.
- Oba sklepy z jednym kodem: runtime taki jak Capacitor opakowuje istniejącą aplikację webową w natywną powłokę z dostępem do funkcji systemowych (push, kamera, pliki). To już spełnia wymogi App Store, bo dodaje realną wartość ponad „przepakowaną stronę".
- Natywne moduły tam, gdzie boli: dopiero gdy dane pokażą wąskie gardło (np. wydajność konkretnego ekranu), dopisuje się natywny fragment, zamiast budować od zera dwie pełne aplikacje.
Każdy etap tej drabiny reużywa poprzedni, a wszystkie stoją na tym samym, już zbudowanym sercu. Budżet idzie za dowodami, nie przed nimi.
Checklist: PWA na start czy od razu aplikacja natywna?
Odpowiedz „tak" lub „nie":
- Czy rdzeń produktu wymaga sprzętu poza kamerą, GPS i płatnościami (Bluetooth, NFC, sensory, praca w tle)?
- Czy aplikacja ma działać przede wszystkim offline?
- Czy to gra / AR / intensywna grafika?
- Czy obecność w App Store jest sama w sobie celem biznesowym (prestiż, kanał pozyskania)?
- Czy masz już zweryfikowane na danych, że użytkownicy będą wracać codziennie?
0–1 „tak": PWA prawdopodobnie wystarczy na długo, może na zawsze. 2–3 „tak": zacznij od PWA, planuj hybrydę (Capacitor) po walidacji. 4–5 „tak": aplikacja natywna od początku, ale wtedy robisz to świadomie, znając koszt tej decyzji.
Podsumowanie
Aplikacja mobilna to najdroższy możliwy sposób przetestowania pomysłu: dwa codebase'y, prowizje sklepów, cykl review i użytkownicy, z których statystycznie trzech na czterech znika w trzy dni. PWA odwraca kolejność: najpierw działający produkt w tygodnie zamiast kwartałów, za ułamek kosztów, z pełną analityką realnych zachowań. Potem, jeśli dane to uzasadnią, ten sam kod trafia do sklepów. A czasem, jak pokazuje MishiPay, dane mówią, że sklepy nie są potrzebne wcale.
„Kiedy klient przychodzi do nas z pomysłem na aplikację mobilną, pierwsze pytanie nie brzmi »iOS czy Android«, tylko »czego jeszcze nie wiemy o użytkownikach«. Zwykle nie wiemy prawie niczego i właśnie dlatego zaczynamy od PWA. Za jedną trzecią budżetu dostajemy produkt, który zarabia, i dane, które projektują resztę roadmapy. Najdroższe aplikacje, jakie widziałem, to te zbudowane na wyobrażeniach."
Łukasz Jurys, CTO calmfox.pl sp. z o.o.
