PWA czy aplikacja natywna: co wybrać dla firmy i co działa na iPhonie w 2026 roku

Co to jest PWA i czym różni się od aplikacji natywnej?

PWA (progressive web app) to aplikacja zbudowana z technologii webowych, którą można zainstalować na telefonie i komputerze jak zwykłą aplikację. Aplikacja natywna to osobny program dla iOS i osobny dla Androida, pobierany ze sklepu.

MDN, dokumentacja webowa prowadzona przez Mozillę, opisuje PWA jako aplikację, która jak strona działa na wielu platformach z jednego kodu, a jak aplikacja systemowa daje się zainstalować, działa bez sieci i w tle oraz współpracuje z urządzeniem. W praktyce PWA to Twoja aplikacja webowa z trzema dodatkami: adresem po HTTPS, plikiem manifestu i, prawie zawsze, service workerem. Piszę jako programista z Mikołowa, który buduje aplikacje webowe dla firm zdalnie w całej Polsce, więc patrzę na ten wybór od strony kodu, który ktoś potem musi utrzymać.

Manifest to plik JSON z nazwą, ikonami, adresem startowym i trybem wyświetlania. Według MDN przeglądarki oparte na Chromium, czyli Chrome, Edge i Samsung Internet, proponują instalację dopiero wtedy, gdy manifest zawiera nazwę, ikony 192 i 512 pikseli, adres startowy oraz tryb wyświetlania, a pole prefer_related_applications nie jest włączone. Service worker to skrypt działający między aplikacją a siecią: przechowuje pliki w pamięci podręcznej, odpowiada, gdy nie ma połączenia, i odbiera powiadomienia push. Zarówno instalacja, jak i service worker wymagają HTTPS.

Aplikacja natywna powstaje w narzędziach producenta systemu, osobno dla iPhone’a i dla Androida. Korzysta z funkcji telefonu, które system udostępnia aplikacjom, trafia do ludzi przez App Store i Google Play, a każda jej wersja przechodzi przegląd sklepu. Pomiędzy tymi biegunami leżą frameworki wieloplatformowe, które z jednego kodu budują dwie aplikacje sklepowe; opisuję je w osobnej sekcji.

Warto to rozróżnić od razu: PWA nie jest osobnym produktem obok aplikacji webowej. To ta sama aplikacja, którą pracownik otwiera w przeglądarce na komputerze w biurze, tylko przygotowana do instalacji na telefonie. Dlatego wybór między aplikacją mobilną a webową sprowadza się zwykle do pytania, czy wersja webowa dostanie manifest i service worker, czy obok niej powstanie osobny kod do sklepów. Jeśli dopiero ustalasz, czy potrzebujesz aplikacji, czy wystarczy strona z formularzem, zacznij od przewodnika aplikacja webowa a strona internetowa.

{
  "name": "Zlecenia serwisowe",
  "short_name": "Zlecenia",
  "start_url": "/zlecenia/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0f172a",
  "icons": [
    { "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Jakie funkcje telefonu działają w przeglądarce, a jakie nie?

Aplikacja webowa obsługuje dziś instalację, powiadomienia push, pracę offline, aparat i lokalizację na obu systemach, ale na iPhonie nie połączy się z urządzeniem przez Bluetooth ani nie odczyta tagu NFC. Ograniczenia dotyczą głównie iPhone’a, bo tam przeglądarki działają na silniku Safari.

Powiadomienia push działają we wszystkich głównych przeglądarkach, bo MDN oznacza Push API jako dostępne powszechnie od marca 2023 r. Na iPhonie i iPadzie warunek jest jeden, ale twardy: według WebKitu od iOS i iPadOS 16.4 powiadomienia dostaje tylko aplikacja dodana do ekranu początkowego, a o zgodę może poprosić wyłącznie w reakcji na gest użytkownika. Takie powiadomienia pojawiają się na ekranie blokady, w centrum powiadomień i na sparowanym Apple Watch, a aplikacja może ustawiać licznik na ikonie.

Aparat i lokalizacja działają w przeglądarkach od lat. MDN podaje, że dostęp do kamery i mikrofonu przez getUserMedia jest dostępny we wszystkich głównych przeglądarkach od września 2017 r., a Geolocation API od lipca 2015 r. W obu przypadkach użytkownik musi wyrazić zgodę, a aplikacja musi działać po HTTPS. To wystarcza, żeby technik dołączył zdjęcie usterki do zgłoszenia albo zobaczył na mapie najbliższe zlecenie.

Granica przebiega przy sprzęcie i pracy w tle. WebKit na swojej stronie o ochronie przed śledzeniem wymienia funkcje, których na razie nie wdraża ze względu na ryzyko identyfikowania użytkowników (fingerprinting) i bezpieczeństwo: Web Bluetooth, Web NFC, Web USB, Serial API, WebHID i geolokalizację w tle. Na Androidzie jest lepiej: według dokumentacji Chrome przeglądarka obsługuje tam Web NFC od wersji 89 i część Web Bluetooth, ale MDN oznacza Web Bluetooth jako technologię eksperymentalną, która nie działa w części popularnych przeglądarek. Podobnie jest z synchronizacją w tle: Background Synchronization API nie jest dostępne we wszystkich głównych przeglądarkach, więc nie warto opierać na nim procesu, od którego zależą pieniądze.

Co PWA potrafi na Androidzie i iPhonie w porównaniu z aplikacją natywną, według dokumentacji MDN, WebKit i Apple.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Kiedy aplikacja natywna jest naprawdę potrzebna?

Aplikacja natywna lub wieloplatformowa jest potrzebna, gdy telefon ma zrobić coś, czego przeglądarka nie potrafi albo czego Apple nie udostępnia stronom. Poniżej sześć takich sytuacji; jeśli żadna Cię nie dotyczy, zacznij od wersji webowej.

Formularze, listy zleceń, statusy, zdjęcia z aparatu, mapa z bieżącą pozycją, powiadomienia i logowanie działają w przeglądarce zarówno na Androidzie, jak i na iPhonie. Jeśli Twoje narzędzie składa się tylko z takich elementów, osobny kod do sklepów oznacza drugą bazę kodu do poprawiania przy każdej zmianie, a użytkownik nie dostanie w zamian żadnej nowej funkcji.

A wydajność? W narzędziach firmowych rzadko przesądza o wyborze, bo formularz, lista zleceń czy mapa nie obciążają telefonu. Różnicę widać przy ciężkiej grafice 3D, obróbce wideo i długich, mocno animowanych listach, choć i ta granica się przesuwa: według notatek WebKitu Safari 26 obsługuje na iPhonie WebGPU, czyli dostęp stron do procesora graficznego. Jeśli aplikacja ma głównie pokazywać i zbierać dane, szybkość serwera i ilość przesyłanych danych zmienią więcej niż wybór technologii na telefonie.

Weźmy firmę serwisową: technik odbiera zlecenie, robi zdjęcia, dopisuje użyte części i zamyka zlecenie, czasem w piwnicy bez zasięgu. Wszystko to da się zrobić w przeglądarce, pod warunkiem że dane trafią na serwer zaraz po odzyskaniu sieci. Jeśli jednak technik ma drukować protokół na przenośnej drukarce Bluetooth, a firma wydaje iPhone’y, potrzebna jest warstwa natywna, choćby cienka, przez Capacitor. Szerzej o porządkowaniu pracy takiej firmy piszę w przewodniku automatyzacja firmy instalacyjnej i serwisowej.

• Urządzenia przez Bluetooth, NFC lub USBDrukarki etykiet, czytniki, wagi, czujniki, tagi NFC przy maszynach. Na iPhonie WebKit nie wdraża Web Bluetooth, Web NFC ani Web USB, a na Androidzie MDN wciąż oznacza Web Bluetooth jako eksperymentalne.
• Lokalizacja w tleEwidencja przejazdów czy podgląd floty, gdy aplikacja jest zamknięta. WebKit nie wdraża geolokalizacji w tle, a wersja webowa pobiera pozycję przez Geolocation API po zgodzie użytkownika, tylko w trakcie korzystania z aplikacji.
• Wielodniowa praca bez sieci na iPhonieMagazyn bez zasięgu, budowa, teren. Aplikacja webowa działa offline, ale według WebKitu dane stron domyślnie nie mają gwarancji trwałości, a synchronizacja w tle nie działa we wszystkich przeglądarkach. Przy kilku dniach bez sieci natywna baza na urządzeniu jest bezpieczniejsza.
• Płatności zbliżeniowe z telefonuW Europejskim Obszarze Gospodarczym aplikacje na iPhone’a mogą obsługiwać zbliżeniowe transakcje NFC, ale Apple wymaga do tego uprawnienia HCE, które dostają tylko deweloperzy spełniający wymogi branżowe i regulacyjne. To domena banków, portfeli i operatorów płatności, a przeglądarka tej funkcji nie daje.
• Głęboka integracja z systememWidżety na ekranie, CarPlay, dane zdrowia w HealthKit, akcje dla Siri. Apple udostępnia je przez frameworki WidgetKit, CarPlay, HealthKit i App Intents, z których korzysta kod aplikacji, a nie strona w przeglądarce.
• Sklep jako kanał pozyskaniaJeśli klienci mają znaleźć aplikację, wpisując frazę w App Store lub Google Play, sama strona w sklepie się nie pojawi. Przy narzędziu dla Twoich klientów albo pracowników wystarczy link w mailu, bo oni już wiedzą, czego szukają.

Co wybrać w typowych sytuacjach w firmie?

Panel klienta, aplikację dla techników, rezerwacje i narzędzie wewnętrzne buduję jako PWA. Aplikację natywną lub wieloplatformową wybieram do Bluetooth na iPhonie, lokalizacji w tle i produktu, który ludzie mają znaleźć w sklepie. Tabela rozpisuje to na typowe sytuacje w firmie.

Jeśli w środkowej kolumnie wyszła Ci aplikacja ze sklepu tylko dlatego, że „klienci tego oczekują”, sprawdź to na danych: ilu z nich wraca codziennie, ilu prosi o powiadomienia, ilu dzwoni z pytaniem o status. Aplikację instaluje się po to, żeby do czegoś wracać; jeśli nie ma powodu do codziennego powrotu, ikona na ekranie niczego nie zmieni.

Dwa przypadki z tabeli opisuję w osobnych przewodnikach: panel klienta B2B, w którym odbiorcy sami sprawdzają zamówienia i faktury, oraz system rezerwacji online, gdzie pytanie brzmi zwykle, czy wystarczy gotowe narzędzie.

Typowe sytuacje w firmie i rozsądny punkt wyjścia. Tabela opiera się na możliwościach i zasadach sklepów opisanych w tym przewodniku.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Ile kosztuje aplikacja webowa, a ile mobilna na iOS i Androida?

PWA kosztuje mniej więcej tyle co aplikacja webowa, bo to ta sama aplikacja z dodaną instalacją, trybem offline i powiadomieniami. Aplikacja mobilna to jedna lub dwie aplikacje do zbudowania, dwa procesy wydawnicze i coroczne dostosowania do wymagań sklepów.

Skalę różnicy widać w cenniku, który warszawska firma Twój Software publikuje na swojej stronie: aplikacja webowa lub PWA od 8 000 zł netto w 2–⁠6 tygodni, MVP na Androida od 12 000 zł netto, na iOS od 15 000 zł netto, aplikacja na obie platformy we Flutterze lub React Native 15 000–⁠80 000 zł netto w 2–⁠4 miesiące, a złożony produkt 100 000–⁠250 000 zł netto i więcej. To widełki jednego wykonawcy, a nie oferta; szersze zestawienie cen aplikacji webowych u kilku polskich firm zebrałem w przewodniku ile kosztuje aplikacja webowa.

Ważniejsza od ceny startu jest liczba rzeczy, które trzeba potem utrzymywać. Przy wersji webowej masz jeden kod, jeden serwer i jedno wdrożenie, a poprawka dociera do wszystkich przy kolejnym uruchomieniu. Przy dwóch aplikacjach natywnych każda zmiana powstaje dwa razy, przechodzi dwa przeglądy i czeka, aż użytkownik zaktualizuje aplikację. Niezależnie od wyboru zostaje backend z bazą danych, logiką i uprawnieniami; w obu wariantach to ta sama praca, bo telefon jest tylko oknem do danych.

Nie pomijaj iPhone’ów w rachunku. W Polsce Android odpowiadał we wrześniu 2026 r. za 63,75% wyświetleń stron z urządzeń mobilnych, a iOS za 36,2% według StatCounter. Ponad jedna trzecia mobilnych odsłon pochodzi więc z iPhone’ów, czyli z systemu, na którym przeglądarka ma najwięcej ograniczeń. Przy aplikacji wewnętrznej zamiast statystyk kraju policz telefony, które firma rzeczywiście wydaje pracownikom.

Przy pierwszej wersji radzę ograniczać liczbę kanałów, a nie jakość: jedna dopracowana wersja zamiast trzech na start. Co zostawić w pierwszej wersji, a czego nie wolno wyciąć, opisuję w przewodniku ile kosztuje MVP aplikacji.

Cenniki i przepisy się zmieniają. Linki do źródeł są na dole strony.

Co płacisz na starcie i co wraca co roku przy trzech podejściach. Kwoty z cennika Twój Software i z opłat sklepów; konkretną wycenę daje dopiero opis zakresu.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

React Native, Flutter czy Capacitor: kiedy wybrać drogę pośrednią?

Aplikacja wieloplatformowa to jeden kod, z którego powstają aplikacje do App Store i Google Play. Daje dostęp do sprzętu, którego brakuje przeglądarce, ale zostawia wszystkie koszty, przeglądy i zasady sklepów.

Jeden kod nie oznacza, że płacisz połowę ceny dwóch aplikacji. Obie wersje trzeba testować na urządzeniach, publikować w dwóch sklepach i dostosowywać do corocznych wymagań, a funkcje mocno związane z systemem i tak wymagają fragmentów kodu natywnego. Zyskujesz jedną logikę ekranów, jeden zestaw testów i jedną listę błędów do poprawienia.

Moja reguła wyboru jest prosta. Jeśli aplikacja ma już wersję webową i brakuje jej jednej funkcji telefonu, zaczynam od Capacitora. Jeśli od początku powstaje aplikacja mobilna z rozbudowanym interfejsem i animacjami, rozważam Fluttera albo React Native, zależnie od tego, w czym zespół klienta będzie ją utrzymywał po wdrożeniu. Kod pisany osobno pod iOS i Androida zostawiam funkcjom, których nie da żadna wtyczka.

• React NativeWedług strony projektu Meta wydała ten framework w 2015 roku i od tamtej pory go utrzymuje. Kod piszesz w JavaScripcie z Reactem, a komponenty renderują się natywnymi elementami interfejsu systemu. Naturalny wybór, gdy zespół zna już React z aplikacji webowej.
• FlutterOtwarty framework w języku Dart, który według strony projektu Google wspiera i sam używa. Kompiluje się do kodu maszynowego, z jednego kodu buduje aplikacje na telefony, przeglądarkę i komputery i pozwala kontrolować każdy piksel interfejsu. Dobry wybór, gdy aplikacja ma mieć własny, dopracowany wygląd na obu systemach.
• CapacitorUruchamia istniejącą aplikację webową w natywnym kontenerze. Capacitor dodaje się do gotowego projektu JavaScript, a brakujące funkcje telefonu dokłada się wtyczkami w Swifcie i Javie. Gdy wersji webowej brakuje jednej czy dwóch funkcji urządzenia, to zwykle najkrótsza droga do sklepu.

Czy aplikacje webowe działają na iPhonie w Polsce i w Unii?

Tak. Aplikacje webowe dodane do ekranu początkowego działają na iPhonie w Polsce tak samo jak w reszcie świata, choć na początku 2024 roku Apple zapowiadało ich wyłączenie w Unii.

Przy dostosowaniu iOS 17.4 do aktu o rynkach cyfrowych (DMA) Apple ogłosiło, że usuwa w UE aplikacje webowe z ekranu początkowego, i w wersjach beta systemu otwierały się one jak zwykłe zakładki. Potem firma zmieniła zdanie, powołując się na prośby o zachowanie tej funkcji. W zaktualizowanym komunikacie dla deweloperów napisała, że zachowuje tę funkcję w UE, że takie aplikacje nadal działają bezpośrednio na WebKicie i jego architekturze bezpieczeństwa oraz że wrócą wraz z premierą iOS 17.4 na początku marca 2024 r. Ten epizod pokazuje ryzyko, o którym warto pamiętać: o tym, co aplikacje webowe potrafią na iPhonie, decyduje jeden producent.

Drugie ograniczenie wynika z zasad App Store. Wytyczna 2.5.6 wymaga, żeby aplikacje przeglądające internet korzystały z WebKitu, a inny silnik dopuszcza tylko z osobnym uprawnieniem dla UE i Japonii. Dlatego przeglądarki na iPhonie mają zwykle te same możliwości co Safari i nie da się obejść braku Web Bluetooth, prosząc pracownika o instalację innej przeglądarki.

W iOS i iPadOS 26 Apple poszło w przeciwnym kierunku. WebKit pisze w notatkach do Safari 26, że każda strona dodana do ekranu początkowego otwiera się teraz domyślnie jako aplikacja, nawet bez manifestu; kto woli zwykłą zakładkę, wyłącza tę opcję przy dodawaniu. Jedno się nie zmieniło: użytkownik nadal sam dodaje aplikację z menu udostępniania, bo iOS nie obsługuje zdarzenia beforeinstallprompt, dzięki któremu na Androidzie można pokazać własny przycisk „Zainstaluj”.

Trzeci szczegół dotyczy danych zapisanych na telefonie. Według strony WebKitu o ochronie przed śledzeniem Safari usuwa po 7 dniach bez interakcji z witryną wszystkie dane zapisywane skryptami: IndexedDB, LocalStorage, rejestracje service workera i jego pamięć podręczną. Domena aplikacji dodanej do ekranu początkowego jest z tej reguły wyłączona, a WebKit chętniej przyznaje jej trwały tryb zapisu. Wniosek dla firmy: jeśli pracownik ma zapisywać coś bez sieci, aplikacja musi być zainstalowana, a dane powinny trafiać na serwer przy pierwszej okazji.

1. Wyślij link do aplikacji, nie do strony głównejPracownik albo klient otwiera adres aplikacji w Safari, w Chrome, Edge lub Firefoksie. Link w mailu powitalnym prowadzi prosto do ekranu startowego.
2. Menu udostępniania i dodanie do ekranu początkowegoUżytkownik stuka przycisk udostępniania i wybiera dodanie do ekranu początkowego. Od iOS 26 opcja otwierania jako aplikacja jest domyślnie włączona.
3. Pierwsze uruchomienie z ikonyDopiero aplikacja uruchomiona z ekranu początkowego działa we własnym oknie, ma osobne dane i może prosić o powiadomienia.
4. Prośba o powiadomienia dopiero po dotknięciuAplikacja pokazuje przycisk „Włącz powiadomienia” z jednym zdaniem, o czym będą, i dopiero po jego dotknięciu iOS pyta o zgodę. Wyłączyć je można w Ustawieniach, jak w każdej aplikacji.

Ile kosztuje publikacja w App Store i Google Play i jaką prowizję pobierają sklepy?

Konto w Apple Developer Program kosztuje 99 USD rocznie, a w Google Play jednorazowo 25 USD. Prowizje od sprzedaży cyfrowej w UE zmieniły się w 2026 roku i dla polskich użytkowników nie wynoszą już klasycznych 30 i 15 procent.

Opłaty za konta są stałe i niewielkie: Apple podaje 99 USD za rok członkostwa, w walucie lokalnej tam, gdzie jest dostępna, a Google Play pobiera jednorazowo 25 USD przy rejestracji. Firma zakładająca konto organizacji w Apple potrzebuje numeru D-U-N-S, adresu e-mail w domenie firmy i działającej strony internetowej. Jednoosobowa działalność rejestruje się jako osoba fizyczna, a w App Store jako sprzedawca widnieje wtedy imię i nazwisko właściciela, nie nazwa firmy.

Prowizje dotyczą wyłącznie sprzedaży treści i usług cyfrowych w aplikacji. Według strony Apple o zmianach w UE od 1 października 2026 r. sklepy w Unii mają jednolite warunki: 26% od sprzedaży przez Apple In-App Purchase i 15% dla uczestników App Store Small Business Program, czyli deweloperów z wpływami ze sklepu do 1 mln USD w poprzednim roku kalendarzowym, oraz dla subskrypcji odnawianych po pierwszym roku. Przy alternatywnym operatorze płatności w aplikacji stawki wynoszą 20% i 10%, a link do zakupu na stronie obciąża sprzedaż z 7 dni po kliknięciu prowizją 15% albo 10%. Poza UE Apple podaje standardowo 30%, a w programie dla małych firm 15%.

Według pomocy Play Console Google Play od 30 czerwca 2026 r. liczy opłaty od transakcji z użytkownikami z Europejskiego Obszaru Gospodarczego inaczej niż wcześniej. Pierwszy milion dolarów rocznych przychodów obciąża 10% opłaty serwisowej plus 5% opłaty za rozliczenie, gdy płatność idzie przez Google Play Billing. Powyżej tego progu subskrypcje kosztują nadal 10% plus 5%, inne transakcje od użytkowników, którzy pierwszy raz zainstalowali lub zaktualizowali aplikację od tej daty, 20% plus 5%, a od wcześniejszych instalacji 25% plus 5%. W krajach, do których nowy układ jeszcze nie dotarł, deweloper zapisany do progu 15% płaci dotychczasowe stawki: 15% od pierwszego miliona dolarów rocznie i 30% powyżej.

Dla firm, które sprzedają towary i usługi, ważniejsze jest co innego. Wytyczna 3.1.3(e) App Store wymaga, żeby towary fizyczne i usługi wykonywane poza aplikacją były opłacane innymi metodami niż płatność wewnątrz aplikacji, na przykład Apple Pay albo kartą, a zasady płatności Google Play wprost zakazują używania Google Play Billing przy towarach fizycznych, przejazdach, usługach sprzątania czy biletach na wydarzenia. Przy zamówieniu hurtowym, rezerwacji wizyty, zleceniu serwisowym czy szkoleniu stacjonarnym prowizja sklepu w ogóle się nie pojawia, niezależnie od tego, czy aplikacja jest w sklepie. Realną różnicę robi dopiero przy subskrypcjach, kursach online i dostępie do treści, i wtedy PWA przyjmująca płatność przez zwykłego operatora wychodzi taniej.

Do tego dochodzą wymagania, które kosztują czas zamiast pieniędzy. Osobiste konto w Google Play założone po 13 listopada 2023 r. musi przed publikacją przeprowadzić zamknięty test z co najmniej 12 testerami zapisanymi nieprzerwanie przez 14 dni, a wniosek o dostęp do produkcji Google rozpatruje zwykle w ciągu 7 dni. Od 31 sierpnia 2026 r. nowe aplikacje i aktualizacje w Google Play muszą celować w Android 16 (API 36), więc aplikacja w sklepie wymaga corocznych prac tylko po to, żeby dalej się aktualizować. Wyjątkiem są aplikacje prywatne, udostępniane wyłącznie użytkownikom jednej organizacji. Jak w ogóle przyjmować płatności w aplikacji webowej, opisuję w przewodniku o Stripe dla polskiej firmy.

Koszty i wymagania sklepów w porównaniu z PWA. Prowizje dotyczą wyłącznie sprzedaży treści i usług cyfrowych w aplikacji, sprzedawanych użytkownikom z UE.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Czy PWA można opublikować w Google Play i App Store?

PWA można opublikować w Google Play przez Trusted Web Activity. W App Store przejdzie tylko aplikacja, która daje coś więcej niż opakowana strona, bo wytyczna 4.2 odrzuca przepakowane witryny.

Trusted Web Activity to opisany przez Google sposób otwierania PWA z aplikacji na Androida: aplikacja ze sklepu uruchamia Twoją stronę w przeglądarce użytkownika na pełnym ekranie, a to, że aplikacja i strona należą do tego samego wydawcy, potwierdza się plikiem Digital Asset Links. Treść renderuje przeglądarka, więc zmiany na stronie trafiają do użytkowników bez nowej wersji w sklepie, a sama aplikacja nie ma dostępu do ciasteczek ani pamięci strony. MDN wskazuje też narzędzie PWABuilder, które pakuje PWA do Google Play, Microsoft Store, Meta Quest Store i App Store.

App Store ocenia takie paczki surowiej. Wytyczna 4.2 mówi, że aplikacja ma zawierać funkcje, treści i interfejs, które wynoszą ją ponad przepakowaną stronę internetową, a punkt 4.2.2 wyklucza aplikacje będące głównie materiałem marketingowym, wycinkiem strony, agregatorem treści albo zbiorem linków. Punkt 4.2.6 odrzuca aplikacje z komercyjnych szablonów i generatorów, jeśli nie zgłasza ich sam dostawca treści. Opakowana PWA, która nie robi niczego ponad przeglądarkę, ma więc realne ryzyko odrzucenia.

Jeśli sklep Apple jest Ci potrzebny, rozsądniejszą drogą bywa Capacitor. Ten sam kod webowy działa wtedy w natywnym kontenerze, a tam, gdzie trzeba, sięga do natywnych bibliotek iOS i Androida przez wtyczki pisane w Swifcie i Javie. Do App Store trafia aplikacja, która rzeczywiście robi więcej niż strona, a pracownicy w biurze dalej korzystają z tej samej wersji w przeglądarce.

Jak chronić dane firmy w aplikacji na telefonie?

PWA jest tak bezpieczna jak aplikacja webowa, na której stoi: działa wyłącznie po HTTPS, a dane i uprawnienia chroni serwer. Telefon w obu wariantach trzeba traktować jak urządzenie, które może zginąć.

Adres subskrypcji push jest jednocześnie kluczem do wysyłki: MDN zaleca trzymać go w tajemnicy i zabezpieczyć zapisywanie subskrypcji przed atakami CSRF, bo kto zna ten adres, może wysłać powiadomienie do Twoich użytkowników. Treść powiadomienia szyfruje się kluczem z subskrypcji. Na iPhonie powiadomienia z PWA idą przez Apple Push Notification service, tę samą usługę co w aplikacjach natywnych, i nie wymagają członkostwa w Apple Developer Program; WebKit zaleca tylko dopuścić adresy w domenie push.apple.com, jeśli serwer ma ograniczony ruch wychodzący.

Powiadomienia pojawiają się na zablokowanym ekranie, więc nie umieszczam w nich danych, których nie powinien przeczytać ktoś postronny: kwot, nazwisk klientów, adresów. Wystarczy „Nowe zlecenie w Twoim rejonie”, a szczegóły pokazuje aplikacja po odblokowaniu telefonu i zalogowaniu.

Ważniejsze od wyboru technologii jest to, gdzie leżą dane. Na telefonie trzymam tylko to, co potrzebne do pracy bez sieci, i wysyłam to na serwer przy pierwszej okazji. Serwer przy każdym żądaniu sam ustala, kim jest użytkownik, na podstawie sesji i nie ufa identyfikatorom przysłanym z telefonu. Ta zasada obowiązuje tak samo w aplikacji natywnej, bo jej kod też da się rozebrać, a obowiązki wobec danych osobowych wynikają z tego, co przetwarzasz, a nie z tego, czy aplikacja jest w sklepie.

Jak zacząć od wersji webowej i nie zamknąć sobie drogi do sklepu?

Najbezpieczniej zbudować najpierw dobrą aplikację webową z manifestem i service workerem, sprawdzić ją na prawdziwych użytkownikach i dopiero potem decydować o sklepie. Kod webowy nie przepada, jeśli później okaże się potrzebny Capacitor albo Trusted Web Activity.

Tak buduję aplikacje w JFlow Labs: jeden kod webowy, który działa na komputerze w biurze i na telefonie w terenie, a warstwę natywną dokładam dopiero wtedy, gdy praca na prawdziwych danych pokaże, że jest potrzebna. Prowadzę studio sam, więc projekt interfejsu, backend i decyzja o sklepie powstają w jednej głowie, a Ty rozmawiasz bezpośrednio z osobą, która pisze kod. Zakres takiej współpracy opisuję na stronie aplikacje webowe dla firm.

Jeśli zastanawiasz się, czy Twoja aplikacja zmieści się w PWA, napisz mi, kto będzie z niej korzystał, na jakich telefonach, jakiej funkcji urządzenia nie możesz sobie odpuścić i z jakimi systemami ma się łączyć, na przykład z ERP, CRM albo KSeF. Odpowiadam w ciągu jednego dnia roboczego. Pracuję z Mikołowa na Śląsku, zdalnie z firmami z całej Polski.

1. Spisz funkcje telefonu, których naprawdę potrzebujeszAparat, lokalizacja, push, praca offline, Bluetooth, NFC. Przy każdej zapisz, na jakim systemie i jak często będzie używana. Ta lista rozstrzyga więcej niż porównanie technologii.
2. Policz iPhone’y wśród użytkownikówStatystyki strony albo lista telefonów służbowych. Przy przewadze iPhone’ów przejdź przez tabelę możliwości zdanie po zdaniu, bo to tam PWA ma najwięcej ograniczeń.
3. Zbuduj aplikację webową gotową do instalacjiHTTPS, manifest z ikonami 192 i 512 pikseli, service worker z pamięcią podręczną i czytelnym komunikatem, gdy nie ma sieci.
4. Przygotuj ekran instalacji dla iPhone’aNa Androidzie wystarczy przycisk, na iPhonie trzy kroki z obrazkami. Prośbę o powiadomienia pokaż dopiero po instalacji, z informacją, o czym będą.
5. Sprawdź aplikację na kilku osobach przez dwa tygodniePatrz na instalacje, powroty i zgłaszane problemy. Na iPhonie sprawdź przede wszystkim, czy ludzie wiedzą, że aplikację trzeba dodać do ekranu początkowego, bo bez tego nie dostaną powiadomień.
6. Do sklepu idź dopiero po brakującą funkcjęJeśli brakuje tylko obecności w Google Play, wystarczy Trusted Web Activity. Jeśli brakuje funkcji telefonu na obu systemach, dodaj Capacitor, a kod natywny pisz tylko dla tego, czego nie da żadna wtyczka.

Pytania i odpowiedzi