Progresywne aplikacje webowe na iOS — jak działają, co potrafią i skąd się wzięły

Tak, progresywne aplikacje webowe działają na iPhonie i iPadzie. Apple wspiera podstawowe technologie PWA w Safari od iOS 11.3, czyli od marca 2018 roku, a od tego czasu wygoda korzystania z nich znacznie się poprawiła.

Największa zmiana przyszła wraz z iOS 16.4 w marcu 2023 roku, kiedy Apple dodało powiadomienia push i plakietki aplikacji dla aplikacji webowych zainstalowanych na ekranie początkowym. Jeśli czytasz starszy poradnik, który twierdzi, że PWA na iOS nie mogą wysyłać powiadomień albo mogą przechowywać w pamięci podręcznej tylko 50 MB, te informacje są już nieaktualne.

PWA na iOS to witryna internetowa, którą użytkownik zapisuje na ekranie początkowym i która działa we własnym oknie, bez paska adresu Safari. Dla zespołów produktowych oznacza to, że jedna baza kodu może obsłużyć iOS, Androida i internet na komputerach — bez publikacji w App Store, bez opłaty platformowej na poziomie 15–30% i bez czekania na review, żeby wdrożyć poprawkę.

Ten kompromis jest realny: iOS nadal daje aplikacjom webowym mniejszy dostęp do sprzętu niż aplikacjom natywnym, a instalacja jest ręczna, zamiast być promowana. Ten przewodnik pokazuje, co PWA mogą, a czego nie mogą zrobić na iOS w 2026 roku, jak do tego doszło i jak ocenić, czy takie rozwiązanie pasuje do twojego produktu.

Jak dziś działają PWA na iOS

PWA łączy dwie technologie webowe, które Safari już wspiera. A service worker to skrypt uruchamiany przez przeglądarkę w tle. Zarządza pamięcią podręczną, udostępnia aplikację, gdy sieć działa wolno albo jest niedostępna, i odbiera wiadomości push. A web app manifest to plik JSON, który określa dla iOS nazwę aplikacji, ikony, kolor motywu i sposób jej uruchamiania. Razem pozwalają witrynie zachowywać się jak zainstalowana aplikacja: mieć własną ikonę, działać w trybie pełnoekranowym i obsługiwać pracę offline.

Na iOS każda aplikacja webowa działa na WebKit, czyli silniku stojącym za Safari. Dotyczy to także innych przeglądarek na iPhonie, takich jak Chrome czy Firefox, ponieważ Apple wymaga, by pod spodem korzystały z WebKit. Gdy witryna trafi na ekran początkowy, potrafi już w 2026 roku więcej, niż większość osób się spodziewa:

• Wysyłać powiadomienia push wyświetlane na ekranie blokady, w Centrum powiadomień i na sparowanym Apple Watchu, ze wsparciem dla trybu Skupienie.

• Wyświetlać plakietkę z liczbą na swojej ikonie za pomocą Badging API.

• Przechowywać znaczną ilość danych offline. Safari 17 zwiększyło limity pamięci do dużej części dostępnej przestrzeni dyskowej dla każdego origin i dodało Persistent Storage API, zastępując dawne sztywne limity.

• Korzystać z Screen Wake Lock, dodanego w Safari 18.4, aby ekran pozostawał aktywny.

W praktyce oznacza to, że dobrze zbudowane PWA na nowoczesnym iPhonie jest dziś zbliżone do lekkiej aplikacji natywnej w zastosowaniach związanych z treściami, handlem i produktywnością.

Jak PWA pojawiły się na iOS

Relacja Apple z aplikacjami webowymi sięga pierwszego iPhone’a, ale instalowalne PWA w znanej nam dziś formie pojawiały się etapami. Ta droga była powolna i tłumaczy, dlaczego tak wiele starszych porad jest dziś błędnych.

2018: cichy start z iOS 11.3

W marcu 2018 roku Apple wdrożyło obsługę Service Worker i Web App Manifest w Safari 11.1 and iOS 11.3. Nie było ogłoszenia skierowanego do deweloperów ani banera instalacyjnego. Można było dodać witrynę do ekranu początkowego i uruchamiać ją offline, ale brakowało funkcji, które Android miał już wcześniej, w tym powiadomień push i synchronizacji w tle.

2018–2022: długi okres stagnacji

Przez kilka lat PWA na iOS pozostawały ograniczone. Aplikacje webowe miały niewielkie limity pamięci, brak push, brak blokady orientacji ekranu, a Safari usuwało nieużywane dane witryn po okresie bezczynności. To właśnie tę epokę opisywała pierwotna wersja tego artykułu i stąd bierze się większość nieaktualnych twierdzeń.

Marzec 2023: iOS 16.4 zmienia reguły gry

iOS and iPadOS 16.4 dodały Web Push dla aplikacji webowych na ekranie początkowym, razem z Badging API. Użytkownik musi najpierw zainstalować aplikację webową i stuknąć przycisk, by przyznać zgodę, ale od tego momentu powiadomienia działają tak jak w każdej innej aplikacji. To jedno wydanie usunęło najczęstszy powód, dla którego zespoły rezygnowały z PWA na iOS.

2024: obawy w UE, a potem wycofanie się z decyzji

Przed terminem wejścia w życie Digital Markets Act na początku 2024 roku Apple ogłosiło, że usunie aplikacje webowe z ekranu początkowego dla użytkowników w Unii Europejskiej, powołując się na obawy dotyczące bezpieczeństwa związane z alternatywnymi silnikami przeglądarek. Po sprzeciwie deweloperów i dochodzeniu regulatora Apple wycofało tę decyzję i zachowało aplikacje webowe, nadal działające na WebKit.

2025 i dalej: stopniowe usprawnienia

Safari 18.4 dodało Declarative Web Push i Screen Wake Lock, a iOS 26 sprawiło, że witryny dodane do ekranu początkowego domyślnie otwierają się jako aplikacje webowe, co usuwa kolejny punkt tarcia.

Jak zainstalować PWA na iPhonie lub iPadzie

Na iOS nie ma automatycznego komunikatu instalacyjnego, tak jak na Androidzie. Użytkownik dodaje aplikację ręcznie, więc strona zwykle musi wyświetlić krótką instrukcję. Kroki są następujące:

1. Otwórz stronę w Safari.

2. Kliknij przycisk Udostępnij (kwadrat ze strzałką skierowaną w górę) na pasku narzędzi.

3. Przewiń w dół i kliknij „Dodaj do ekranu początkowego”.

4. W razie potrzeby zmień nazwę, a potem kliknij „Dodaj”.

Ikona aplikacji pojawi się wtedy na ekranie początkowym, a sama aplikacja uruchomi się we własnym oknie pełnoekranowym. Żeby instalacja działała i dawała natywne wrażenie, witryna musi być dostępna przez HTTPS, mieć zarejestrowanego service workera i udostępniać prawidłowy manifest z ikonami we właściwych rozmiarach. Powiadomienia push są dostępne dopiero po zainstalowaniu aplikacji i udzieleniu zgody przez użytkownika w odpowiedzi na stuknięcie.

Czego PWA nadal nie potrafią na iOS w 2026 roku

PWA na iOS zlikwidowały już większość dawnych luk, ale kilka ograniczeń nadal pozostaje. Weź je pod uwagę, zanim się na nie zdecydujesz:

• Brak Web Bluetooth, Web USB i Web NFC, więc aplikacje mocno zależne od sprzętu odpadają.

• Ograniczona praca w tle. Niezawodna synchronizacja w tle i długotrwałe zadania nadal wypadają słabiej niż w aplikacjach natywnych.

• Tylko WebKit. Na iOS nie da się udostępnić szybszego ani innego silnika renderującego.

• Powiadomienia push wymagają instalacji. Strona otwarta w zwykłej karcie Safari nie może wysyłać powiadomień push — użytkownik musi najpierw dodać ją do ekranu początkowego.

• Brak automatycznego banera instalacyjnego, co oznacza niższy wskaźnik instalacji, jeśli nie pokierujesz użytkownikami.

• Domyślnie brak obecności w App Store, więc tracisz wyszukiwanie w sklepie jako kanał pozyskiwania użytkowników.

Żadne z tych ograniczeń nie blokuje serwisów contentowych, sklepów, dashboardów ani narzędzi do rezerwacji. Wykluczają jednak aplikacje, które zależą od głębokiej integracji z urządzeniem albo intensywnego przetwarzania w tle.

PWA a natywna aplikacja na iOS

Właściwy wybór zależy od tego, z jakimi funkcjami aplikacja ma współpracować i jak chcesz ją dystrybuować. Tabela poniżej porównuje oba podejścia pod kątem czynników, które zwykle o tym decydują.

To, jak PWA tworzy wartość, jest proste: utrzymujesz jedną wersję webową, wdrażasz zmiany od razu, gdy są gotowe, i omijasz zarówno kolejkę do weryfikacji, jak i opłatę sklepu. To skraca czas między poprawką a momentem, w którym użytkownik ją widzi, co zwykle zwiększa konwersję i obniża koszt utrzymania produktów contentowych i e-commerce.

Żeby PWA było właściwym wyborem, musi się zgadzać kilka rzeczy. Funkcje muszą mieścić się w możliwościach WebKit. Jeśli potrzebujesz push, musisz zaprojektować krok instalacji i przekonać do niego użytkownika. Musisz też zaakceptować niższą konwersję instalacji niż w App Store, a potem zrekompensować to zasięgiem w sieci. Jeśli to nie wchodzi w grę, rozwiązanie natywne albo aplikacja cross-platformowa to bezpieczniejsza droga.

Czy warto stworzyć PWA na iOS?

PWA dobrze sprawdza się wtedy, gdy aplikacja jest przede wszystkim nastawiona na treści, transakcje albo realizację konkretnych zadań, a zasięg webowy ma większe znaczenie niż obecność w sklepie. Czytniki newsów, sklepy e-commerce, procesy rezerwacji i zamawiania, narzędzia wewnętrzne oraz dashboardy dobrze działają jako zainstalowane aplikacje webowe na iPhonie. Starbucks prowadzi szeroko opisywane PWA do składania zamówień, a Tinder stworzył takie rozwiązanie, by dotrzeć do użytkowników korzystających ze słabszych urządzeń i mających mało miejsca na dane — w obu przypadkach szybka aplikacja webowa okazała się lepsza niż duży plik do pobrania.

Aplikacja natywna nadal wygrywa, gdy zależysz od sprzętu, do którego web nie ma dostępu, potrzebujesz gwarantowanego przetwarzania w tle albo opierasz pozyskiwanie użytkowników na odkrywalności i zaufaniu związanych z App Store. Wiele zespołów stawia na oba rozwiązania: PWA jako łatwo dostępny pierwszy punkt kontaktu i aplikację natywną dla zaawansowanych użytkowników. Taki model hybrydowy pozwala utrzymać niski koszt pozyskania w kanale webowym, a wysiłek związany z rozwiązaniem natywnym zostawić na funkcje, które rzeczywiście tego wymagają. Jeśli oceniasz nakład prac inżynierskich, warto zestawić tworzenie PWA i tworzenie natywnych aplikacji mobilnych z konkretnymi możliwościami, których potrzebuje twój produkt, zamiast traktować to jako wybór „albo-albo”.