PWA w 2026 - kiedy warto, a kiedy lepiej natywna aplikacja

Zbudowałem PlateMate jako PWA. Instalacja w 10 sekund, działa offline, wygląda jak natywna apka. Użytkownik otwiera stronę w przeglądarce, klika "Dodaj do ekranu głównego" i ma pełnoekranową aplikację do planowania posiłków - bez wizyty w App Store, bez 99 dolarów rocznie za konto developerskie Apple.

Ale PWA nie jest dla każdego projektu. Są scenariusze, w których natywna aplikacja wygra z PWA pod każdym względem. Ten artykuł to praktyczny przewodnik - co PWA potrafi w 2026, gdzie ma ograniczenia i jak podjąć decyzję dla konkretnego projektu.

Czym jest PWA w 2026

Progressive Web App to aplikacja webowa, która spełnia trzy warunki: działa przez HTTPS, ma plik manifestu (web app manifest) opisujący ikonę, kolory i tryb wyświetlania, oraz posiada service worker - skrypt przechwytujący zapytania sieciowe i umożliwiający pracę offline.

W 2026 PWA to dojrzała technologia, nie eksperyment. Starbucks podwoił liczbę dziennych aktywnych użytkowników po wdrożeniu PWA. Pinterest odnotował 40% wzrost czasu spędzonego w aplikacji i 44% wzrost przychodów z reklam. Twitter Lite (teraz X Lite) - 65% wzrost stron na sesję i 75% wzrost wysłanych tweetów.

Co się zmieniło od 2024:

• Firefox 143 (wrzesień 2025) dodał obsługę PWA na Windowsie - przypinanie do paska zadań, okna bez interfejsu przeglądarki
• Safari na iOS utrzymał wsparcie dla PWA w UE po interwencji Komisji Europejskiej (DMA)
• Declarative Web Push pozwala na otrzymywanie powiadomień push bez aktywnego service workera
• 78% organizacji priorytetowo traktuje PWA dla aplikacji skierowanych do klientów

Możliwości PWA w 2026 - co działa, a co nie

Zanim podjmiesz decyzję, musisz wiedzieć co konkretnie PWA potrafi na poszczególnych platformach. Poniżej stan na luty 2026.

Praca offline i cache

Obsługa: pełna na wszystkich platformach.

Service worker przechwytuje zapytania HTTP i serwuje zasoby z cache'u gdy sieć jest niedostępna. Cztery strategie cache'owania:

• Cache-first - statyczne zasoby (CSS, JS, obrazy) serwowane z cache, sieć jako fallback
• Network-first - dynamiczne dane (API) pobierane z sieci, cache jako fallback
• Stale-while-revalidate - natychmiastowa odpowiedź z cache, aktualizacja w tle
• Cache-only - zasoby, które nigdy się nie zmieniają

W PlateMate stosuję cache-first dla szablonów i grafik, network-first dla danych o posiłkach. Efekt: użytkownik może przeglądać swój plan posiłków i przepisy w sklepie bez zasięgu.

Ograniczenie na iOS: limit cache około 50 MB i automatyczne czyszczenie danych po kilku tygodniach nieużywania aplikacji.

Powiadomienia push

Android (Chrome, Edge, Firefox): pełna obsługa. Push działa identycznie jak w natywnych aplikacjach.

iOS: obsługa od wersji 16.4, ale z warunkami. Push działa wyłącznie gdy PWA jest zainstalowana na ekranie głównym (dodana przez "Udostępnij" > "Dodaj do ekranu głównego"). Powiadomienia push w samym Safari na iOS nie działają. To oznacza, że musisz przekonać użytkownika do zainstalowania aplikacji zanim w ogóle będziesz mógł wysyłać mu powiadomienia.

Desktop: Chrome i Edge - pełna obsługa. Firefox od wersji 143 na Windowsie. Safari na macOS - obsługa od Ventura 13.

Kamera, GPS, sensory

Kamera i mikrofon: pełna obsługa na wszystkich platformach przez MediaDevices API. Wystarczy na skanowanie kodów QR, robienie zdjęć, wideorozmowy.

GPS (Geolocation API): pełna obsługa. Mapy, lokalizacja, geofencing - bez problemu.

Akcelerometr, żyroskop: obsługa przez Generic Sensor API na Chrome i Edge. Safari wymaga jawnej zgody użytkownika.

Background sync

Jednorazowa synchronizacja w tle (Background Sync API) - obsługa na Chrome i Edge. Przydatna gdy użytkownik wykona akcję offline (np. wyśle formularz), a synchronizacja nastąpi gdy sieć wróci.

Periodic Background Sync - obsługa wyłącznie na Chromium. Firefox i Safari nie wspierają. Dodatkowo przeglądarka sama decyduje o częstotliwości synchronizacji na podstawie tego, jak często użytkownik otwiera aplikację. Nie można polegać na precyzyjnych interwałach.

Dostęp do systemu plików

File System Access API: obsługa na Chrome i Edge. Pozwala na odczyt i zapis plików bezpośrednio na dysku użytkownika. Safari i Firefox: brak wsparcia.

Origin Private File System (OPFS): szersza obsługa, w tym na Androidzie. Prywatny system plików dla aplikacji, niewidoczny dla użytkownika.

Płatności

Payment Request API: obsługa na Chrome, Edge, Safari. Integracja z Apple Pay i Google Pay. Działa w PWA tak samo jak na zwykłej stronie.

Bluetooth i NFC

Web Bluetooth: obsługa na Chrome i Edge. Komunikacja z urządzeniami Bluetooth Low Energy. Safari: brak.

Web NFC: wyłącznie Chrome na Androidzie. Odczyt i zapis tagów NFC w zasięgu do 10 cm. iOS: brak wsparcia.

Obecność w sklepach z aplikacjami

Google Play: PWA można opublikować jako Trusted Web Activity (TWA). Lekki wrapper natywny delegujący renderowanie do przeglądarki. Narzędzia: PWABuilder lub Bubblewrap. Aplikacja musi mieć manifest, HTTPS, service worker i plik Digital Asset Links.

Apple App Store: oficjalnie PWA nie są dopuszczone. Można próbować opakować PWA w natywny wrapper (np. przez PWABuilder), ale Apple zastrzega sobie prawo do odrzucenia aplikacji, które są "zwykłymi stronami w ramce". Niektórym się udaje, ale to ryzyko.

Microsoft Store: pełna obsługa. PWA można publikować bezpośrednio.

PWA vs natywna aplikacja - porównanie

Kryterium	PWA	Natywna (iOS + Android)
Wydajność	Dobra dla 90% zastosowań. Luka zamykana przez HTTP/2, cache, optymalizację renderowania	Lepsza dla grafiki 3D, animacji 60fps, złożonych obliczeń
Dostęp do sprzętu	Kamera, GPS, akcelerometr - tak. Bluetooth, NFC - tylko Chromium	Pełny dostęp do wszystkich API systemowych
Dystrybucja	Link + instalacja z przeglądarki. Brak pośrednika	App Store / Google Play. Review process, prowizja 15-30%
Koszt developmentu	1 codebase, 3 platformy. $15k-80k	2 osobne codebase'y (iOS + Android). $50k-300k+
Utrzymanie	1 zespół, 1 deployment	2 zespoły lub cross-platform (Flutter, RN)
Aktualizacje	Natychmiastowe, bez review	App Store review 1-7 dni
SEO	Pełna indeksacja przez Google	Brak (content w aplikacji nieindeksowany)
Rozmiar instalacji	Kilkaset KB do kilku MB	Dziesiątki do setek MB
Tryb offline	Tak (service worker)	Tak (natywny storage)
Push na iOS	Tak, ale wymaga instalacji na home screen	Tak, standardowo

Kiedy PWA wygrywa

Aplikacje oparte na treści

Serwisy newsowe, bazy przepisów, dokumentacja, katalogi produktowe. Washington Post wdrożył PWA i odnotował 23% wzrost powracających użytkowników z wyszukiwania mobilnego oraz 88% poprawę czasu ładowania dla powracających.

Treść jest indeksowana przez Google - natywna aplikacja tego nie oferuje. Dla biznesów, gdzie SEO to kanał pozyskiwania użytkowników, PWA daje przewagę, której natywna apka nie da.

Narzędzia B2B

Dashboardy, panele administracyjne, systemy CRM, narzędzia projektowe. Użytkownicy B2B korzystają z aplikacji na desktopie i mobile, często na urządzeniach firmowych z ograniczeniami instalacji. PWA nie wymaga zgody działu IT na instalację z App Store.

MVP i startupy

Jeden codebase, trzy platformy (web, Android, iOS). Czas do rynku: tygodnie zamiast miesięcy. Budżet: ułamek kosztu natywnej aplikacji. Jeśli walidacja pomysłu wymaga szybkiego prototypu dostępnego na telefonach - PWA to sensowny wybór na start.

Projekty z ograniczonym budżetem

Przy budżecie $15k-50k PWA pozwala na dostarczenie działającej aplikacji mobilnej. Za tę kwotę natywna aplikacja na obie platformy jest nierealna - sam koszt developera iOS w Europie Zachodniej to $70-150/h.

PlateMate - PWA w produkcji

PlateMate (plate-mate.pl) to planer posiłków zbudowany w Laravel 12 z Livewire 3, działający jako PWA. Co działa dobrze:

• Instalacja: użytkownik skanuje QR kod lub wchodzi na stronę, klika "Dodaj do ekranu głównego". 10 sekund.
• Offline: przepisy i plan posiłków dostępne bez internetu. Service worker cache'uje szablony i dane.
• Wygląd: pełny ekran, bez paska przeglądarki, splash screen przy uruchomieniu. Większość użytkowników nie odróżnia od natywnej apki.
• Aktualizacje: deploy na serwer i wszyscy mają nową wersję. Bez czekania na review Apple.
• Koszt dystrybucji: zero. Brak opłaty developerskiej, brak prowizji od transakcji.

Co sprawia problemy:

• Instalacja na iOS wymaga wyjaśnienia. "Kliknij ikonę udostępniania, potem Dodaj do ekranu głównego" - to 4 tapnięcia, nieoczywiste dla wielu użytkowników.
• Cache na iOS czyszczony po kilku tygodniach nieużywania. Użytkownik, który wraca po miesiącu, musi ponownie załadować dane.
• Brak obecności w App Store. Część użytkowników szuka aplikacji w sklepie, a nie w przeglądarce.

Kiedy natywna aplikacja wygrywa

Gry i grafika

Wszystko co wymaga GPU - gry 3D, edytory wideo, aplikacje AR/VR. WebGL i WebGPU robią postępy, ale natywny Metal (iOS) i Vulkan (Android) dają 2-5x lepszą wydajność w złożonych scenach. Jeśli twoja aplikacja renderuje cokolwiek bardziej wymagającego niż wykresy - natywna.

Głęboka integracja z systemem

Widgety na ekranie głównym, Siri Shortcuts, integracja z Zdrowiem (HealthKit), odczyt SMS-ów, zaawansowany Bluetooth (nie tylko BLE), NFC na iOS, dostęp do kontaktów z pełnymi uprawnieniami. Jeśli twoja aplikacja potrzebuje czegokolwiek z tej listy - natywna albo cross-platform (Flutter, React Native).

App Store jako kanał marketingowy

Dla aplikacji konsumenckich (fitness, finanse, social media) obecność w App Store i Google Play to kanał odkrywania. Użytkownicy szukają "planer treningów" w sklepie. PWA tego kanału nie ma. Jeśli organiczne wyszukiwanie w App Store to twoja strategia pozyskiwania użytkowników - potrzebujesz natywnej apki (lub przynajmniej TWA na Google Play).

Aplikacje z wymaganiami czasowymi

Nawigacja samochodowa, aplikacje medyczne monitorujące parametry w tle, komunikatory z niezawodnymi powiadomieniami. Background execution w PWA jest ograniczony i niespójny między platformami. Natywna aplikacja daje pełną kontrolę nad procesami w tle.

Problem z Apple

Apple ma skomplikowaną relację z PWA. Z jednej strony od iOS 16.4 wspiera web push dla zainstalowanych PWA. Z drugiej - ogranicza możliwości na kilka sposobów.

WebKit jako jedyny silnik na iOS. Wszystkie przeglądarki na iOS (Chrome, Firefox, Edge) używają pod spodem WebKit. To oznacza, że nawet jeśli Chrome na Androidzie wspiera Web Bluetooth, na iOS - nie, bo tam to nie jest prawdziwy Chrome, tylko skin na Safari.

Unia Europejska naciskała na zmianę przez Digital Markets Act (DMA). W lutym 2024 Apple ogłosiło, że w iOS 17.4 zdegraduje PWA w UE do zwykłych zakładek - bez offline, bez push. Po fali krytyki Apple wycofało się z tej decyzji w marcu 2024 i przywróciło pełną obsługę PWA.

Limit storage 50 MB. Cache API na iOS ma limit około 50 MB. Dla aplikacji z dużą ilością grafik lub danych offline - to poważne ograniczenie.

Automatyczne czyszczenie danych. iOS może wyczyścić dane PWA (Cache, IndexedDB) jeśli aplikacja nie była używana przez kilka tygodni. Apple narzuca 7-dniowy limit na dane zapisywane przez skrypty. W praktyce oznacza to, że PWA na iOS musi być regularnie otwierana, żeby zachować dane offline.

Instalacja wymaga 4 tapnięć. Android pokazuje baner "Zainstaluj aplikację" automatycznie. iOS wymaga: Safari > ikona Udostępnij > przewiń > "Dodaj do ekranu głównego". Konwersja instalacji na iOS jest niższa.

Czy to się zmieni? DMA wymaga od Apple otwarcia ekosystemu, ale postępy są powolne. Na 2026 trzeba projektować z tymi ograniczeniami, nie zakładać że znikną.

Realne koszty - PWA vs natywna

Poniższe szacunki dotyczą aplikacji średniej złożoności (autoryzacja, profil użytkownika, lista elementów, CRUD, powiadomienia, tryb offline). Kwoty w dolarach, stawki europejskie.

Pozycja	PWA	Natywna (iOS + Android)
Development	$15k-50k	$50k-150k (dwie platformy)
Czas realizacji	6-12 tygodni	12-24 tygodnie
Konto developerskie	$0	$99/rok (Apple) + $25 jednorazowo (Google)
Utrzymanie roczne	$3k-8k (1 codebase)	$10k-30k (2 codebase'y)
Infrastruktura	Hosting web ($20-100/mies.)	Hosting web + build pipeline ($50-200/mies.)
Prowizja od transakcji	0% (własny payment)	15-30% (in-app purchases)

Cross-platform (Flutter, React Native) zmniejsza lukę: $30k-80k za obie platformy z jednego codebase'u. Ale to nadal droższe niż PWA i wymaga developerów znających te frameworki.

Dla startupów i małych firm różnica jest prosta: za budżet jednej natywnej aplikacji na iOS możesz zbudować PWA i mieć pieniądze na marketing.

Implementacja PWA - podstawy techniczne

Service worker

Skrypt JS zarejestrowany przez aplikację, który działa jako proxy między przeglądarką a siecią. Przechwytuje zapytania, serwuje z cache, umożliwia push i background sync.

// Rejestracja service workera
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

// W sw.js - cache-first dla statycznych zasobów
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(cached => cached || fetch(event.request))
  );
});

Web App Manifest

Plik JSON opisujący metadane aplikacji. Przeglądarka używa go do instalacji i wyświetlania.

{
  "name": "PlateMate - Planer posiłków",
  "short_name": "PlateMate",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#10b981",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Pole display: "standalone" jest wymagane, żeby PWA wyglądała jak natywna apka (bez paska adresu) i żeby push notifications działały na iOS.

HTTPS

Obowiązkowe. Service worker wymaga bezpiecznego kontekstu. W 2026 to nie jest problem - Let's Encrypt daje certyfikaty za darmo, a większość hostingów ma HTTPS domyślnie.

Frameworki do budowy PWA w 2026

Next.js (React) - wbudowane wsparcie PWA, SSR i SSG, silne SEO. Moduł next-pwa konfiguruje service worker i manifest automatycznie.

Nuxt (Vue) - moduł @vite-pwa/nuxt obsługuje manifest, ikony i service worker z minimalną konfiguracją.

SvelteKit (Svelte) - 20-40% mniejsze bundle'e niż React/Vue. Plugin @vite-pwa/sveltekit do integracji PWA. Dobry wybór gdy rozmiar aplikacji ma znaczenie (a na mobile zawsze ma).

Astro - najszybszy dla stron content-heavy. Statyczny HTML domyślnie, JavaScript ładowany selektywnie. Do 2x szybszy niż inne frameworki dla treści.

Laravel + Livewire - to stack PlateMate. Nie typowy wybór dla PWA, ale działa. Service worker i manifest konfigurowane ręcznie lub przez pakiet laravel-pwa. Cała logika w PHP, zero JS frameworka na froncie.

Vite Plugin PWA - narzędzie niezależne od frameworka, które generuje service worker i manifest. Integruje się z Next.js, Nuxt, SvelteKit, Astro i innymi. Jeśli używasz Vite (a w 2026 większość frontendowych narzędzi go używa) - to najprostsza ścieżka.

Ścieżka migracji - zacznij od PWA

Często najrozsądniejsza strategia to: zacznij od PWA, dodaj natywną aplikację później jeśli będzie potrzebna.

PWA to aplikacja webowa. Cały backend, API, logika biznesowa - to samo co dla natywnej apki. Jeśli za pół roku okaże się, że potrzebujesz dostępu do HealthKit albo obecności w App Store, budujesz natywny frontend (lub cross-platform w Flutter/RN) na tym samym backendzie.

Odwrotna ścieżka (natywna -> PWA) jest trudniejsza. Natywna aplikacja często ma logikę wbudowaną w klienta, bez osobnego API. Migracja wymaga wydzielenia backendu.

Praktycznie: PWA jako MVP, zbieranie feedbacku, walidacja modelu biznesowego. Natywna aplikacja gdy masz product-market fit i konkretny powód (feature albo kanał dystrybucji).

Jak podjąć decyzję - framework decyzyjny

PWA jeśli:

• Twoja aplikacja opiera się na treści, formularzach, listach, dashboardach
• Budżet poniżej $50k na wszystkie platformy
• SEO to kanał pozyskiwania użytkowników
• Szybki czas do rynku (poniżej 3 miesięcy)
• Natychmiastowe aktualizacje bez review App Store
• Nie potrzebujesz głębokiej integracji z OS (widgety, HealthKit, NFC na iOS)
• Twoi użytkownicy są na Androidzie lub desktopie
• B2B - użytkownicy uruchamiają aplikację z linka, nie szukają w sklepie

Natywna jeśli:

• Gry, grafika 3D, AR/VR, edycja wideo
• Wymagasz NFC, Bluetooth Classic, HealthKit, widgetów
• App Store to twój kanał pozyskiwania użytkowników
• Niezawodne procesy w tle (nawigacja, monitoring zdrowia)
• Twoja grupa docelowa to użytkownicy iOS, którzy nie zainstalują PWA
• Masz budżet $100k+ i zespół do utrzymania dwóch platform

Rozważ cross-platform (Flutter / React Native) jeśli:

• Potrzebujesz natywnych API, ale nie chcesz dwóch codebase'ów
• Budżet $30k-80k
• Akceptujesz kompromis między wydajnością a kosztem

Moje doświadczenie z PlateMate

Po kilku miesiącach PlateMate jako PWA w produkcji - podjąłbym tę samą decyzję ponownie. Aplikacja do planowania posiłków nie potrzebuje HealthKit, Bluetooth ani 60fps animacji. Potrzebuje szybkiego ładowania, pracy offline (żeby sprawdzić przepis w sklepie) i niskiego kosztu utrzymania.

Co bym zrobił inaczej: lepszy onboarding instalacji na iOS. Baner z instrukcją "krok po kroku" zamiast zakładania, że użytkownik wie co to "Dodaj do ekranu głównego". I bardziej agresywne precache'owanie - żeby pierwsze uruchomienie offline miało więcej danych.

PWA w 2026 to nie kompromis. To świadoma decyzja architektoniczna, która dla wielu projektów daje lepszy stosunek możliwości do kosztów niż natywna aplikacja. Ale "dla wielu" to nie "dla wszystkich" - i dlatego trzeba znać ograniczenia przed podjęciem decyzji, a nie po.

Buduję aplikacje webowe i PWA - jeśli zastanawiasz się nad architekturą dla swojego projektu, zajrzyj na stronę backend development.