W latach 2017–2020 PWA było technologicznym hype cycle. Konferencje, wpisy na blogach, oficjalne wsparcie Google i Microsoftu. Potem przyszło rozczarowanie — iOS trzymał kluczowe API zamknięte, prompty instalacyjne okazały się mylące, a marketing aplikacji natywnych był wciąż silniejszy. Społeczność przeszła do Fluttera, React Native i Capacitora.
Po cichu wydarzyło się jednak coś jeszcze. Technologia PWA dalej dojrzewała. Apple w ostatnich latach uzupełnił brakujące API, przeglądarki poprawiły install flow, a specyfikacja service workera się ustabilizowała. I dla zespołów produktowych bez dużego budżetu PWA stało się zaskakująco mocnym rozwiązaniem.
Ten artykuł to uczciwe studium przypadku trefa.app — firmowej ligi typerskiej zbudowanej jako PWA — po roku w produkcji. Co działało, co nie działało i komu poleciłbym dziś PWA.
Kontekst: czym jest trefa.app
Trefa.app to aplikacja webowa do firmowego typowania. Użytkownik loguje się przez Google, zakłada ligę dla swojej firmy, zaprasza współpracowników przez link lub kod QR i wszyscy razem typują wyniki meczów. Aplikacja synchronizuje dane ze sportowych API (NHL, Premier League, mistrzostwa świata) i w czasie rzeczywistym przelicza punkty.
Frontend to Next.js 16 + React 19 + Tailwind, hostowany na Vercelu. Backend to Django 5 + DRF + Channels na Hetznerze. Pomiędzy nimi PostgreSQL na Supabase i Redis do komunikacji w czasie rzeczywistym.
Przyjemny szczegół: nie istnieje żadna natywna aplikacja na iOS ani Androida. PWA to jedyny klient. Użytkownicy na iPhonie, Androidzie, w Windowsie i macOS korzystają dokładnie z tego samego.
Dlaczego wybraliśmy PWA zamiast aplikacji natywnych
Decyzja była w dużej mierze ekonomiczna. Aplikacja natywna oznaczałaby:
- Rozwój dwóch równoległych klientów (iOS Swift + Android Kotlin) albo jakiś framework cross-platform (Flutter, React Native).
- Proces submission do App Store + Google Play — opłaty submission, opóźnienia review, okresowe ponowne publikowanie przy zmianach backendowego API.
- Powiadomienia push przez APNs i FCM, dwie różne infrastruktury, dwa różne procesy certyfikacji.
- Update flow przez sklepy — użytkownik musi aktywnie aktualizować, część zostaje na starszej wersji całymi miesiącami.
Dla produktu o stosunkowo małej grupie docelowej (zespoły firmowe, a nie mass-market) koszty rozwoju natywnego były wyraźnie wyższe niż korzyści. PWA usunęło wszystkie wymienione punkty naraz.
Techniczne zalety, których użytkownicy nie zauważą
To jest część, którą przed wdrożeniem produkcyjnym bym nie docenił. Z perspektywy rozwoju PWA ma szereg konkretnych zalet, które oszczędzają tygodnie pracy rocznie:
Deploy jest natychmiastowy. Push do main → Vercel zbuduje → po 2 minutach nowa wersja jest u wszystkich użytkowników. Żadnego submission, żadnego czekania, żadnego żonglowania kompatybilnością klienta i backendu. Jeśli zrobię breaking change w API, następnego dnia go naprawię i wszyscy mają fix natychmiast.
Jeden kod na wszystko. iOS, Android, Windows, macOS, Linux — wszędzie ta sama aplikacja. Żadnych bugów specyficznych dla platformy ("to psuje się tylko na iPhonie 13 w trybie ciemnym"), żadnej zduplikowanej implementacji.
Krótka droga do użytkownika. Wysyłasz link, klika, jest w aplikacji. Żadnego "pobierz naszą apkę z App Store, zarejestruj się i dopiero potem zaloguj". Dla produktów B2B o niskiej częstotliwości użycia (liga typerska działa tylko podczas turnieju sportowego) jest to ogromna korzyść konwersyjna.
Powiadomienia push działają nawet bez instalacji. Service worker rejestruje push subscription. Gdy użytkownik kliknie "Zezwól na powiadomienia", zaczyna dostawać alerty przed meczami niezależnie od tego, czy dodał aplikację na ekran główny, czy tylko od czasu do czasu otwiera ją w Safari.
Czego PWA nie potrafi (uczciwa sekcja)
Tutaj szczerość jest ważniejsza niż marketing. PWA ma realne ograniczenia, na które natknęliśmy się w produkcji.
Powiadomienia push na iOS mają swoją specyfikę. Apple Web Push istnieje od iOS 16.4, ale działa tylko wtedy, gdy użytkownik doda PWA na ekran główny. Jeśli korzysta z aplikacji przez karty Safari, push subscription się nie zapisze. To friction, którego aplikacja natywna nie ma.
Brak obecności w App Store. Dla niektórych buyer persona (działy HR, menedżerowie IT w korporacjach) "nie mam tego w App Store" jest równoznaczne z "to nie jest poważne". Subiektywne, ale realne.
Niektóre API systemowe są niedostępne. Bluetooth Low Energy, NFC, pełny dostęp do systemu plików — dla zwykłej aplikacji to nie problem, ale jeśli potrzebujesz tych funkcji, PWA cię ogranicza.
Tryb offline jest możliwy, ale nie automatyczny. Service worker musisz ustawić ręcznie, wymyślić strategię cache'owania, zaimplementować kolejki synchronizacji. Dla w pełni offline-first aplikacji jest to więcej pracy, niż wyobrażają sobie deweloperzy.
Benchmark wydajności vs. natywna: PWA jest wolniejsza o ~15–25% przy pierwszym ładowaniu (z powodu parsowania bundle'a JS) i o ~5–10% w zwykłej interakcji. Dla większości aplikacji różnica niezauważalna, dla hardcore'owego gamingu albo edycji wideo to dealbreaker.
Wyniki po roku w produkcji
Konkretne dane z trefa.app po roku działania:
- Stabilność cross-platform — zespół deweloperski złożony z 1 osoby utrzymuje aplikację na wszystkich systemach operacyjnych bez specyficznych bugów. Ten sam cykl testowania dla wszystkich.
- Częstotliwość deployów — średnio 3–5 deployów tygodniowo przez Vercel. Żaden z nich nie rozwiązuje opóźnień submission do App Store.
- Powiadomienia push — aktywnych ~70% użytkowników, push delivery rate ~95% na Androidzie, ~85% na iOS (z powodu wymogu instalacji na ekranie głównym).
- Żadnych opłat App Store — zaoszczędzone ok. 70 USD rocznie na konta deweloperskie + ok. 30% prowizji od transakcji (która inaczej groziłaby przy in-app purchase).
Główna korzyść biznesowa ostatecznie nie była techniczna. Była nią szybkość iteracji. Jeśli klient napisał "ta funkcja by mi się przydała", zwykle zaczynałem ją tego samego dnia i w ciągu tygodnia była w produkcji. Tego przy aplikacji natywnej po prostu się nie da.
Komu poleciłbym dziś PWA
PWA się sprawdza, jeśli spełnione są przynajmniej dwa z poniższych punktów:
- Masz ograniczone zasoby i nie możesz sobie pozwolić na dwie aplikacje natywne plus wersję webową.
- Twoi użytkownicy korzystają z aplikacji od czasu do czasu (nie codziennie), więc niski friction przy pierwszym otwarciu jest ważny.
- Twoja aplikacja nie potrzebuje hardcore'owych API systemowych (Bluetooth, NFC, pełny system plików).
- Chcesz deployować bez bramek sklepów z aplikacjami.
- Twoja grupa docelowa jest mieszana — iOS i Android, mobile i desktop.
I odwrotnie, PWA prawdopodobnie nie będzie właściwym wyborem, jeśli:
- Twoja aplikacja działa codziennie, po kilka godzin dziennie, a użytkownicy intensywnie z niej korzystają (media społecznościowe, messaging).
- Potrzebujesz zaawansowanych integracji systemowych.
- Twoi kupujący oczekują obecności w App Store.
- Wydajność jest krytyczna (gaming, wideo, AR).
Podsumowanie
Hype wokół PWA może i się skończył, ale technologia po cichu dorosła do punktu, w którym dla wielu produktów jest lepszym wyborem niż rozwój natywny. Trefa.app stoi na PWA już rok i nie widzę powodu, żeby to zmieniać. Wręcz przeciwnie — gdybym dziś zaczynał od nowa, wszedłbym w to szybciej.
Jeśli rozważasz dla swojego projektu wybór między PWA a aplikacją natywną, weź pod uwagę jedną rzecz ponad argumentami technicznymi: PWA szybciej dowiezie cię do produkcji. A na wcześniejszym etapie szybkość iteracji jest cenniejsza niż cokolwiek innego.
Swoją drogą, trefa.app możesz sam wypróbować — żadnej instalacji, po prostu klik i typujesz.