PWA — co to jest, jak działa i kiedy zastąpi aplikację ze sklepu

PWA to strona internetowa, która w trzech miejscach zachowuje się jak aplikacja: ma ikonę na ekranie telefonu, działa bez zasięgu i może wysyłać powiadomienia. Brzmi jak sposób na aplikację bez sklepu, bez dwóch baz kodu i bez przeglądu każdej wersji przez Apple i Google — i często nim jest.

Jest jednak jeden warunek, który w rozmowach o PWA umyka najczęściej. We wszystkich trzech miejscach możliwości wyznacza przeglądarka systemu, a nie wykonawca. Na Androidzie Chrome robi prawie wszystko, czego PWA potrzebuje. Na iPhonie wszystkie przeglądarki opierają aplikacje z ekranu początkowego na silniku WebKit Apple, a WebKit części funkcji nie obsługuje i nie zamierza. Dlatego o tym, czy PWA wystarczy, decyduje iPhone, a nie Android — i ten tekst pokazuje, gdzie dokładnie przebiega ta granica.

Jeśli zastanawiacie się dopiero, czy w ogóle potrzebujecie aplikacji — strony, PWA czy aplikacji ze sklepu — zacznijcie od tekstu o tym, czym jest aplikacja mobilna i kiedy ma sens w firmie. Tutaj zakładamy, że PWA jest na stole, i sprawdzamy, co naprawdę potrafi.

Co to jest PWA (progressive web app)

PWA, czyli progressive web app — po polsku progresywna aplikacja internetowa — to strona zbudowana tak, żeby dało się ją zainstalować na urządzeniu i używać jak aplikacji. Otwiera się z ikony, bez paska adresu przeglądarki, może działać bez połączenia z internetem i odbierać powiadomienia. Pod spodem nadal jest jednak stroną: ma adres, aktualizuje się w chwili, w której wgracie nową wersję na serwer, i nie przechodzi przez żaden sklep.

Warto odróżnić ją od dwóch pojęć, które pojawiają się obok. Aplikacja natywna jest pisana osobno dla każdego systemu, w narzędziach Apple i Google, i trafia do użytkownika przez sklep. Aplikacja hybrydowa to zwykle strona zamknięta w natywnym „opakowaniu” — okienku przeglądarki wbudowanym w aplikację — i też jest dystrybuowana przez sklep. Aplikacje wieloplatformowe w rodzaju React Native czy Fluttera to jeszcze co innego: jeden kod, ale natywne elementy interfejsu. Pełne porównanie tych dróg, z ich kosztami w sklepach, jest w tekście o aplikacjach mobilnych.

PWA różni się od wszystkich trzech tym, że nie ma nic do zainstalowania ze sklepu. To zaleta — nie ma przeglądu wersji, opłat za konta ani czekania na akceptację — i zarazem źródło wszystkich ograniczeń, o których niżej.

Jak działa PWA: manifest i service worker

Z technicznego punktu widzenia PWA to zwykła strona z dwoma dodatkami. Nie trzeba znać ich od strony kodu, ale warto wiedzieć, za co odpowiadają, bo to od nich zależy, co PWA potrafi.

Manifest to niewielki plik z opisem aplikacji: jej nazwa, ikony w kilku rozmiarach, kolor paska, adres, od którego ma się otwierać, i sposób wyświetlania — na przykład na pełnym ekranie, bez elementów przeglądarki. To dzięki niemu system wie, jak pokazać PWA na ekranie początkowym i jak ją uruchomić.

Service worker to skrypt, który działa w tle, pomiędzy aplikacją a siecią. Może zapisać na urządzeniu potrzebne pliki i dane, żeby aplikacja otworzyła się bez zasięgu, a potem zsynchronizować zmiany, kiedy połączenie wróci. Odbiera też powiadomienia push, kiedy aplikacja nie jest otwarta. Obsługują go obie główne platformy — Safari na iPhonie od iOS 11.3 (WebKit, 2018).

Praca offline nie dzieje się jednak sama. Service worker robi to, co mu zaprogramowano: które ekrany mają działać bez sieci, co zapisać lokalnie i co zrobić z danymi wprowadzonymi bez połączenia. To jest decyzja projektowa, którą warto podjąć razem z wykonawcą na etapie briefu, a nie odkryć po wdrożeniu.

Instalacja: Android i „Do ekranu początkowego” na iPhonie

Tu zaczynają się różnice między systemami. Na Androidzie przeglądarka Chrome sama proponuje instalację, kiedy strona spełnia kryteria: działa przez HTTPS, ma manifest z nazwą, ikonami i adresem startowym, a użytkownik spędził na niej chwilę (web.dev, Install criteria). Od wersji 108 na Androidzie Chrome nie wymaga już do tego service workera (Chrome for Developers).

Na iPhonie żadna podpowiedź się nie pojawia. Instalacja jest ręczna: w Safari trzeba otworzyć menu Udostępnij i wybrać „Do ekranu początkowego” (Apple, Podręcznik użytkownika iPhone'a). Użytkownik musi więc wiedzieć, że może to zrobić — i to jest zadanie dla Was: krótka instrukcja na stronie albo w pierwszym mailu do klienta.

W iOS 26, zapowiedzianym w czerwcu 2025 roku, Apple zmienił przy tym jedną rzecz na korzyść PWA. Każda strona dodana do ekranu początkowego domyślnie otwiera się jako aplikacja webowa, a nie jako zakładka w przeglądarce; użytkownik może to wyłączyć (WebKit, WWDC25). Sama instalacja nadal jest jednak krokiem, który trzeba wykonać świadomie.

Powiadomienia push na iPhonie

Przez lata brak powiadomień na iPhonie był głównym argumentem przeciw PWA. To się zmieniło w 2023 roku: od iOS i iPadOS 16.4 aplikacje webowe mogą wysyłać powiadomienia push (WebKit, 16.02.2023). Na Androidzie przeglądarka Chrome obsługuje powiadomienia z sieci od wersji 42, czyli od 2015 roku.

Na iPhonie jest jednak warunek, który zmienia rachunek. Powiadomienia działają wyłącznie dla aplikacji dodanej do ekranu początkowego — nie dla strony otwartej w przeglądarce. Zanim użytkownik dostanie pierwsze powiadomienie, musi więc najpierw ręcznie zainstalować PWA, a potem zgodzić się na powiadomienia. Każdy z tych kroków część osób pominie.

Z tego wynika praktyczna reguła. Jeśli powiadomienia są dodatkiem — przypomnieniem o wizycie, informacją o statusie zamówienia, które można też wysłać mailem — PWA na iPhonie wystarczy. Jeśli są rdzeniem produktu, a większość Waszych użytkowników ma iPhone'y, zanim zdecydujecie się na PWA, sprawdźcie na małej grupie, ilu z nich przejdzie przez instalację i zgodę.

Unia Europejska i DMA — kiedy Apple ogłosił usunięcie PWA z iPhone'ów

Jest też powód, dla którego o PWA na iPhonie warto myśleć jak o zależności od jednej firmy. Na początku 2024 roku, dostosowując iOS do unijnego Aktu o rynkach cyfrowych (DMA), Apple ogłosił, że w Unii Europejskiej usuwa aplikacje webowe z ekranu początkowego — w komunikacie dla deweloperów napisał wprost, że „aby spełnić wymogi DMA, musieliśmy usunąć funkcję aplikacji webowych na ekranie początkowym w UE”.

Po fali krytyki decyzja została odwrócona. W zaktualizowanej wersji tego samego komunikatu Apple zapowiedział, że będzie nadal oferować tę funkcję w Unii i że wróci ona wraz z iOS 17.4 na początku marca 2024 roku (Apple, archiwum strony z 5.03.2024). W tym samym komunikacie Apple zaznaczył, że aplikacje z ekranu początkowego nadal są budowane bezpośrednio na WebKit i jego architekturze bezpieczeństwa — także w Unii, gdzie inne przeglądarki mogą już używać własnych silników.

Dla firmy wniosek jest prosty. PWA działa na iPhonie dlatego, że Apple na to pozwala, i zakres tego pozwolenia może się zmienić jedną aktualizacją systemu. Nie jest to powód, żeby z PWA rezygnować — ale jest powód, żeby nie budować na niej funkcji, bez których Wasza firma przestaje działać, i żeby mieć plan na wypadek zmiany.

PWA w sklepie z aplikacjami

Czasem PWA ma trafić do sklepu — bo klienci szukają tam aplikacji albo wymaga tego zamawiający. Na Androidzie jest na to oficjalna droga: Trusted Web Activity, czyli technika Google, która otwiera PWA wewnątrz aplikacji ze sklepu bez paska przeglądarki. Wymaga potwierdzenia, że aplikacja i strona należą do tego samego właściciela (plik Digital Asset Links na serwerze), a paczkę do Google Play można przygotować narzędziem Bubblewrap (Chrome for Developers, Trusted Web Activity).

W App Store takiej drogi nie ma. Wytyczne Apple mówią wprost, że aplikacja powinna zawierać funkcje, treści i interfejs, które wykraczają poza „przepakowaną stronę internetową” (App Store Review Guidelines, 4.2). Samo opakowanie PWA w aplikację na iOS najczęściej nie przejdzie przeglądu — a jeśli dołożycie do niego natywne funkcje, to budujecie już aplikację hybrydową, z przeglądem każdej wersji i kosztami, o których piszemy w tekście o tworzeniu aplikacji mobilnych.

Kiedy PWA ma sens w firmie

Z macierzy możliwości wynika kilka wzorców, w których PWA sprawdza się dobrze — i kilka, w których z góry przegrywa.

Narzędzie dla własnych pracowników. Serwisanci w terenie, magazyn, przedstawiciele handlowi. To najlepszy przypadek dla PWA: użytkowników jest kilkudziesięciu, a nie kilkadziesiąt tysięcy, więc instalację na iPhonie da się przeprowadzić z instrukcją albo na szkoleniu. Praca offline rozwiązuje problem słabego zasięgu, a aktualizacja trafia do wszystkich w chwili wgrania, bez czekania na przegląd w sklepie. Granica: jeśli narzędzie ma się łączyć z drukarką, czytnikiem albo wagą przez Bluetooth, na iPhonie tego nie zrobi.

Panel dla stałych klientów. Klient B2B, który zamawia co tydzień, sprawdza status zlecenia albo pobiera dokumenty, wraca regularnie — i dla niego ikona na ekranie telefonu jest wygodą, a nie barierą. Powiadomienia o statusie mogą być dodatkiem, bo ta sama informacja może pójść mailem.

Produkt dla szerokiej publiczności, który ma być znaleziony. Tu PWA zwykle przegrywa. Użytkownik, który Was nie zna, szuka aplikacji w sklepie, a nie instaluje strony z menu Udostępnij. Jeśli odkrywanie w App Store i Google Play jest częścią planu dotarcia do klientów, potrzebna jest aplikacja ze sklepu.

Płatności w aplikacji i subskrypcje. Jeśli model biznesowy opiera się na płatnościach wewnątrz aplikacji na iPhonie, PWA nie jest właściwą drogą — ta ścieżka prowadzi przez sklep i jego zasady.

Co PWA zmienia w budżecie i harmonogramie

Najważniejsza oszczędność w PWA nie leży w stawce za godzinę, tylko w liczbie rzeczy, które trzeba zrobić dwa razy albo wcale. Jest jedna baza kodu zamiast dwóch aplikacji, jedna publikacja zamiast dwóch przeglądów w sklepach i żadnego konta deweloperskiego do utrzymywania. Każda poprawka trafia do użytkowników w chwili wgrania na serwer, a nie po kilku godzinach albo dniach przeglądu.

Druga różnica jest mniej oczywista. Aplikacja ze sklepu i tak potrzebuje serwera z danymi i interfejsu, przez który będzie się z nim komunikować. W regułach, według których planujemy projekty, samo przygotowanie API dla aplikacji mobilnej to dodatkowe trzy do sześciu tygodni. PWA korzysta z tego samego zaplecza co strona albo aplikacja webowa, więc tej pozycji po prostu nie ma — o ile PWA powstaje zamiast aplikacji ze sklepu, a nie obok niej.

Nie podajemy tu kwot, bo różnica zależy od zakresu, a nie od technologii. Z czego składa się cena aplikacji i jak czytać wyceny, rozpisujemy w tekście ile kosztuje stworzenie aplikacji. Uczciwe porównanie PWA i aplikacji natywnej to zawsze ten sam zakres funkcji wyceniony w obu wariantach — i sprawdzenie, czy wszystkie funkcje z tego zakresu są w macierzy po stronie „tak”.

O co zapytać wykonawcę, który proponuje PWA

PWA bywa proponowana jako „aplikacja taniej”, i często słusznie. Pięć pytań pozwala sprawdzić, czy wykonawca myśli o niej jak o aplikacji, czy jak o stronie z ikoną.

1. Które ekrany będą działać bez zasięgu i co stanie się z danymi wprowadzonymi offline? Dobra odpowiedź wymienia konkretne ekrany i mówi, kiedy dane zostaną wysłane. „Będzie działać offline” bez szczegółów znaczy, że nikt tego jeszcze nie zaprojektował.
2. Jak użytkownik iPhone'a dowie się, że może dodać aplikację do ekranu? Skoro Safari tego nie podpowiada, ktoś musi przygotować instrukcję albo ekran z podpowiedzią — i to powinno być w zakresie projektu.
3. Na których wersjach iOS i Androida będziecie testować? Powiadomienia działają na iPhonie od iOS 16.4, a sposób otwierania z ekranu zmienił się w iOS 26. Test na jednym telefonie wykonawcy to za mało.
4. Jak aktualizacja trafi do użytkowników, którzy mają aplikację zainstalowaną? Service worker przechowuje pliki na urządzeniu, więc źle skonfigurowany potrafi przez długi czas podawać starą wersję. Wykonawca powinien wiedzieć, jak to kontrolować.
5. Czy któraś z zamówionych funkcji wymaga Bluetooth, NFC albo sklepu? Jeśli tak, a aplikacja ma działać na iPhonie, lepiej usłyszeć to przed podpisaniem umowy niż przy odbiorze.

Czego PWA nie zrobi

Najważniejsze ograniczenia dotyczą iPhone'a i dostępu do sprzętu. WebKit, silnik Safari, oficjalnie sprzeciwia się dwóm technologiom, które na Androidzie działają: Web Bluetooth — łączeniu strony z urządzeniami przez Bluetooth, dostępnemu w Chrome na Androidzie — i Web NFC — odczytywaniu tagów zbliżeniowych, dostępnemu w Chrome na Androidzie od wersji 89. Jako powód WebKit podaje prywatność, bezpieczeństwo i niezależność od konkretnego sprzętu (WebKit, standards positions). Jeśli Wasza aplikacja ma łączyć się z drukarką etykiet, czytnikiem, wagą albo odczytywać tagi NFC na magazynie, PWA na iPhonie tego nie zrobi.

Dla części innych technologii WebKit nie zajął stanowiska. Przykładem jest synchronizacja w tle, która pozwala dokończyć wysyłkę danych, kiedy aplikacja jest już zamknięta — na iPhonie nie można na niej polegać. W praktyce oznacza to, że dane wprowadzone bez zasięgu wyślą się wtedy, gdy użytkownik znów otworzy aplikację, a nie w tle.

Zostaje też cała reszta tego, co daje sklep: obecność w wyszukiwarce App Store, płatności w aplikacji i zaufanie części użytkowników do „prawdziwej aplikacji”. Jeśli któraś z tych rzeczy jest dla Was warunkiem, PWA nie jest właściwą drogą — niezależnie od tego, ile kosztuje.

PWA, aplikacja natywna czy hybrydowa — jak wybrać

Po tej liście wybór zwykle rozstrzygają dwa pytania. Pierwsze: czy musicie być w sklepie — bo to kanał dystrybucji, wymóg klienta albo potrzebujecie płatności w aplikacji? Jeśli tak, potrzebna jest aplikacja natywna albo wieloplatformowa. Drugie: czy potrzebujecie działania bez zasięgu, funkcji urządzenia i powiadomień, a użytkownik wraca codziennie? Jeśli tak — PWA, z zastrzeżeniami z tego tekstu. Jeśli nie — wystarczy dobrze zrobiona aplikacja webowa w przeglądarce, która jest też najkrótszą drogą do pierwszej wersji produktu.

Jeśli wybieracie między PWA a aplikacją natywną, dołóżcie do tych pytań jedno sprawdzenie: jaki odsetek Waszych użytkowników ma iPhone'y i czy funkcja, na której Wam najbardziej zależy, jest w macierzy powyżej po stronie „tak”. Jeśli tak — PWA da Wam jedną bazę kodu, aktualizacje bez przeglądu i brak opłat za konta. Jeśli nie — lepiej wiedzieć to przed budową niż po niej.

Nie masz pewności, co wybrać w swoim przypadku? Quiz: strona, aplikacja webowa czy mobilna prowadzi przez kilka pytań o klientów, budżet i sposób korzystania — i kończy się konkretną rekomendacją zamiast listy „to zależy".