PWA na iOS i Androidzie: co działa, a czego nie zrobisz

PWA to aplikacja webowa, którą użytkownik dodaje do ekranu początkowego telefonu bez pośrednictwa sklepu — uruchamia się z własną ikoną i pełnym ekranem, ale pod spodem jest stroną internetową. Na Androidzie zachowuje się niemal jak aplikacja natywna. Na iOS wchodzi w zestaw ograniczeń, o których polskie poradniki milczą, a które potrafią wywrócić cały pomysł. Ten tekst jest o tej drugiej połowie: czego aplikacja webowa na iPhonie nie zrobi i kiedy to przesądza o decyzji.

Czym jest PWA i jakie ma techniczne minimum

PWA to strona internetowa spełniająca trzy warunki techniczne: ma service workera, plik manifestu i działa po HTTPS. To całe minimum — nie ma tu żadnej osobnej technologii ani osobnego języka programowania.

• Service worker to skrypt pośredniczący między aplikacją a siecią. Odpowiada za pamięć podręczną, czyli za to, że aplikacja pokazuje cokolwiek przy słabym zasięgu, i za odbiór powiadomień.
• Plik manifestu opisuje nazwę, ikony, kolor i tryb wyświetlania. To on decyduje, jak aplikacja wygląda po dodaniu do ekranu początkowego i czy uruchamia się bez paska adresu.
• HTTPS jest warunkiem koniecznym: bez szyfrowanego połączenia service worker się nie zarejestruje.

Wszystko poza tą trójką — powiadomienia, praca offline, dostęp do aparatu — jest opcjonalne i zależy od systemu, na którym aplikacja działa. To jest źródło całego zamieszania: nie jest to jedna funkcja, którą się „ma” albo „nie ma”, tylko zestaw możliwości włączanych osobno na każdej platformie. Decyzja, czy w ogóle potrzebujesz wydania mobilnego, jest wcześniejsza i rozkłada się na inne kryteria — opisuję ją w tekście o tym, aplikacja webowa czy mobilna.

Co PWA daje na Androidzie

Na Androidzie aplikacja webowa dostaje niemal komplet zachowań, których użytkownik oczekuje od aplikacji ze sklepu. Instaluje się z poziomu przeglądarki, ma własną ikonę, uruchamia się na pełnym ekranie i działa przy braku zasięgu na tyle, na ile zaplanujesz pamięć podręczną.

Powiadomienia push działają bez dodatkowych warunków wstępnych. Dostępny jest też Background Sync, czyli mechanizm dosyłania danych po odzyskaniu połączenia — użytkownik wypełnia formularz w piwnicy magazynu, zamyka aplikację, a dane wychodzą, kiedy telefon złapie sieć.

Do tego dochodzi rzecz, której nie da się kupić w wydaniu ze sklepu: aktualizacja jest natychmiastowa. Wgrywasz poprawkę na serwer i użytkownik ma ją przy następnym uruchomieniu, bez procedury recenzji i bez czekania, aż zaktualizuje aplikację.

Co PWA robi na iPhonie, a czego nie zrobi

Na iOS aplikacja webowa działa, ale w węższym zakresie i pod jednym twardym warunkiem: kluczowe funkcje włączają się dopiero po dodaniu jej do ekranu początkowego. Apple dodało obsługę Web Push dla aplikacji webowych dodanych do ekranu początkowego w iOS 16.4, w marcu 2023. Powiadomienia działają wyłącznie dla aplikacji zainstalowanej przez Safari, menu Udostępnij i opcję Dodaj do ekranu początkowego. W zwykłej karcie przeglądarki Push API nie jest dostępne.

Konsekwencja jest operacyjna, nie techniczna. Użytkownik, który dostanie od Ciebie link i po prostu go otworzy, nie dostanie żadnego powiadomienia — i nie dowie się, dlaczego. Trzy dotknięcia ekranu, które go dzielą od działającej instalacji, musisz mu wytłumaczyć sam, w treści strony albo w wiadomości.

Reszta ograniczeń jest mniej widoczna, ale bywa groźniejsza. Aplikacja webowa na iOS ma węższy dostęp do sprzętu niż na Androidzie, ciaśniejsze limity pamięci offline i ograniczone przetwarzanie w tle. Brakuje między innymi Background Sync, więc scenariusz „zapisz teraz, wyślij, gdy wróci zasięg” trzeba na iOS zaprojektować inaczej albo z niego zrezygnować. Aplikacje webowe na iPhonie działają na silniku WebKit.

Czy Apple usunęło aplikacje webowe w Unii Europejskiej

Nie usunęło. 1 marca 2024 Apple wycofało się z zapowiedzianego wcześniej usunięcia aplikacji webowych z ekranu początkowego w Unii Europejskiej. Funkcja pozostała w iOS 17.4 i działa dalej, nadal oparta na WebKit. Zdanie „Apple wyłączyło PWA w Unii” krąży po polskim internecie do dziś i jest po prostu nieprawdziwe.

Wniosek na przyszłość jest inny niż ten, który zwykle się z tej historii wyciąga. Nie chodzi o to, że platforma jest niestabilna — chodzi o to, że zakres funkcji aplikacji webowej zależy od decyzji dostawcy systemu, a nie od Twojego kodu. Jeśli ma ona obsługiwać proces, którego firma nie może stracić, trzymaj w zanadrzu scenariusz awaryjny: kanał zapasowy dla powiadomień i dane, które da się wyeksportować bez aplikacji.

Kiedy PWA wystarczy zamiast aplikacji ze sklepu, a kiedy nie

PWA wystarcza wtedy, gdy wartość produktu leży w danych i formularzach, a nie w sprzęcie telefonu, a użytkownik trafia do Ciebie z linku, nie z wyszukiwarki sklepu. Cztery typowe sytuacje, w których to się spina:

• narzędzie wewnętrzne dla pracowników, którzy dostają link od działu IT,
• panel dla klientów albo kontrahentów, logujących się do własnych danych,
• produkt, który wydajesz często i nie chcesz czekać na recenzję przy każdej poprawce,
• aplikacja, w której powiadomienia są przydatne, ale nie krytyczne.

PWA nie wystarczy, gdy powiadomienia push są rdzeniem produktu — dyspozycje dla kierowców, alarmy serwisowe, dyżury — bo część użytkowników iOS nigdy nie dodaje aplikacji do ekranu początkowego i nigdy ich nie zobaczy. Nie wystarczy też, gdy potrzebujesz pracy w tle albo szerokiego dostępu do czujników, a także wtedy, gdy obecność w sklepie jest warunkiem zakupowym po stronie klienta.

Jeśli nie wiesz, które funkcje są naprawdę krytyczne, rozstrzygnij to najpierw na poziomie zakresu pierwszej wersji — dopiero potem sprawdzaj, czy iOS je udźwignie.

Koszt utrzymania: jeden kod czy dwa wydania

PWA to jedna baza kodu i jedno wdrożenie, a aplikacja ze sklepu to dwa wydania i dwa cykle publikacji — ale różnica w utrzymaniu nie sprowadza się do liczby repozytoriów. Przy jednym kodzie poprawka trafia do wszystkich użytkowników naraz i nie musisz utrzymywać zgodności ze starymi wersjami zainstalowanymi na telefonach. To jest realna, powtarzalna oszczędność w każdym miesiącu życia produktu.

Aplikacja webowa przenosi jednak koszt w dwa inne miejsca. Pierwsze to wydajność: nie ma tu paczki pobranej ze sklepu, więc każde uruchomienie oznacza wczytanie zasobów z sieci albo z pamięci podręcznej, a Core Web Vitals opisują tu realny komfort pracy, nie tylko pozycję w wyszukiwarce. Drugie to wsparcie użytkowników iOS — instrukcja dodania do ekranu początkowego, pytania o brakujące powiadomienia i wyjaśnienia, dlaczego u kolegi z Androidem działa inaczej.

Jak rozstrzygnąć to w tydzień, zamiast dyskutować pół roku

Decyzję o PWA podejmuje się na liście funkcji, nie na porównaniu technologii. Pięć kroków, które da się przejść w kilka dni:

1. Wypisz osobno funkcje wymagające powiadomień, pracy w tle i dostępu do sprzętu. Reszta funkcji nie ma tu znaczenia, bo zadziała wszędzie.
2. Sprawdź w analityce własnej strony, jaka część Twoich użytkowników korzysta z iOS. Twoje dane, nie ogólne statystyki rynku.
3. Przy każdej funkcji z punktu pierwszego zaznacz, czy działa na iOS, czy tylko na Androidzie.
4. Dla funkcji, które na iOS nie zadziałają, wybierz jedno z trzech: rezygnacja, obejście (e-mail albo SMS zamiast powiadomienia) albo wydanie ze sklepu.
5. Zapisz decyzję razem z uzasadnieniem, żeby nie wracała na każdym kolejnym spotkaniu.

Jeśli po tym rachunku wychodzi, że wydanie ze sklepu jest konieczne, kolejne kroki — technologia, testy, publikacja — opisuję w przewodniku o tym, jak stworzyć aplikację mobilną. A jeśli chcesz spisać te ustalenia w formie gotowej do rozmowy z wykonawcą, przejdź przez sześć kroków w kreatorze briefu i wróć z listą funkcji, przy których platforma naprawdę robi różnicę.