hackarthon

Jasno, praktycznie i na temat

Porównania i wybór

Aplikacja PWA czy natywna: wybór przewodnika dla muzeum

Wybór między PWA a aplikacją natywną dla muzeum zaczyna się nie od technologii, lecz od zachowania zwiedzających.

Aplikacja PWA czy natywna: wybór przewodnika dla muzeum

Jeśli przewodnik ma uruchomić się przy wejściu, po zeskanowaniu kodu QR, każda dodatkowa przeszkoda ma znaczenie: przejście do sklepu, wyszukanie właściwej aplikacji, zgoda na instalację, oczekiwanie na pobranie i dopiero potem dostęp do treści.

Progresywna aplikacja webowa, czyli PWA, skraca tę ścieżkę do przeglądarki i adresu internetowego. Aplikacja natywna daje z kolei szerszy dostęp do sprzętu telefonu, lepiej nadaje się do zaawansowanej rzeczywistości rozszerzonej, mikrolokalizacji i rozbudowanych funkcji działających bezpośrednio w systemie. Odpowiedź na pytanie, aplikacja PWA czy natywna dla muzeum, zależy więc przede wszystkim od tego, czy muzeum buduje szybki przewodnik po wystawie, czy cyfrową warstwę ekspozycji wymagającą głębokiej integracji z urządzeniem.

Pierwsza decyzja: jak zwiedzający ma dostać się do przewodnika

W muzeum technologia konkuruje o uwagę z samą wystawą. Zwiedzający nie przychodzi po to, by konfigurować oprogramowanie. Chce zobaczyć obiekt, odsłuchać komentarz, przeczytać tłumaczenie albo uruchomić dodatkową treść. Im dłuższa droga do przewodnika, tym większe ryzyko, że użytkownik zrezygnuje, zanim zobaczy pierwszą informację.

W przypadku PWA punkt wejścia może być bardzo prosty:

1. Zwiedzający skanuje kod QR umieszczony przy wejściu, na bilecie lub obok eksponatu.

2. Strona otwiera się w przeglądarce telefonu.

3. Użytkownik otrzymuje dostęp do przewodnika bez pobierania aplikacji ze sklepu.

4. Przy kolejnej wizycie może dodać skrót do ekranu głównego, jeśli muzeum przygotowało odpowiedni manifest aplikacji.

To rozwiązanie dobrze pasuje do wystaw czasowych, wydarzeń jednorazowych i instytucji, które chcą szybko uruchomić wielojęzyczny przewodnik. Nie trzeba przekonywać odbiorcy do instalowania programu, który być może będzie mu potrzebny tylko przez godzinę.

Aplikacja natywna ma inną logikę dystrybucji. Zwiedzający musi znaleźć ją w App Store lub Google Play, pobrać, zainstalować i niekiedy zaakceptować dodatkowe uprawnienia. Z punktu widzenia muzeum oznacza to również przygotowanie dwóch ścieżek publikacji i utrzymania: dla systemu iOS oraz dla Androida. Sama obecność aplikacji w sklepie może budować długoterminowy kanał komunikacji, ale przy krótkiej wizycie bywa niepotrzebnym tarciem.

Nie chodzi przy tym o prosty podział: PWA jest zawsze wygodniejsza, a natywna zawsze bardziej profesjonalna. Wygoda zależy od sytuacji. Przy stałej ekspozycji, regularnych odwiedzinach i rozbudowanym programie lojalnościowym instalacja może mieć sens. Przy wydarzeniu, festiwalu albo ekspozycji odwiedzanej przez turystów przewagę zyskuje natychmiastowy dostęp przez kod QR.

Najlepszy przewodnik to nie ten z najdłuższą listą funkcji, lecz ten, który zwiedzający uruchomi bez zastanawiania się, co właściwie ma zainstalować.

PWA i aplikacja natywna — różnica w pierwszym kontakcie

ObszarPWAAplikacja natywna
UruchomieniePrzez przeglądarkę, kod QR lub adres URLPrzez sklep z aplikacjami i instalację
Liczba bazowych wersjiJeden kod źródłowy dla iOS i AndroidaZwykle osobne rozwiązania dla obu platform
Dostęp do treściMoże rozpocząć się natychmiast po otwarciu stronyZaczyna się po pobraniu i instalacji
AktualizacjeWprowadzane po stronie serweraZależne od procesu publikacji i aktualizacji aplikacji
Integracja ze sprzętemOgraniczona przez możliwości przeglądarki i systemuSzerszy dostęp do API oraz podzespołów telefonu
Przewodnik offlineMożliwy dzięki pamięci podręcznej i skryptom Service WorkersNaturalny element architektury aplikacji
Rozszerzona rzeczywistość i mikrolokalizacjaMożliwe w określonym zakresie, zależnie od systemu i przeglądarkiLepsze warunki dla zaawansowanych funkcji sprzętowych

PWA nie jest zwykłą stroną internetową

Najczęstsze nieporozumienie polega na traktowaniu PWA jak responsywnej witryny z przyciskiem dodanym na ekran główny. Progresywna aplikacja webowa ma własną architekturę. Jej podstawą jest manifest aplikacji, który opisuje między innymi nazwę, ikonę i sposób uruchamiania, oraz skrypty Service Workers odpowiedzialne za obsługę zasobów zapisanych w pamięci podręcznej.

Dla muzeum oznacza to możliwość przygotowania przewodnika, który po pierwszym uruchomieniu zachowa wybrane treści w urządzeniu. Zwiedzający może wtedy przejść przez część ekspozycji przy słabym zasięgu albo bez bieżącego połączenia z internetem. Nie jest to jednak automatyczna obietnica, że cała aplikacja będzie działała offline. Trzeba zaprojektować, które elementy zostaną pobrane, kiedy nastąpi synchronizacja i jak aplikacja zareaguje na brak aktualnych danych.

W praktyce warto rozdzielić treści na kilka grup:

  • teksty opisowe i napisy do obiektów, które zwykle można przechowywać lokalnie;
  • miniatury oraz zoptymalizowane zdjęcia, których rozmiar nie powinien niepotrzebnie obciążać pamięci telefonu;
  • nagrania audio, wymagające świadomego zarządzania pobieraniem ze względu na objętość;
  • materiały wideo i modele trójwymiarowe, które mogą znacząco zwiększyć wymagania dotyczące transferu i pamięci;
  • dane zmienne, takie jak komunikaty o zamknięciu sali, harmonogram wydarzeń czy informacje organizacyjne.

Dobrze przygotowane wdrożenie przewodnika multimedialnego nie polega na zapisaniu wszystkiego na urządzeniu. Chodzi o to, by użytkownik otrzymał dostęp do tych treści, których rzeczywiście potrzebuje, w momencie, w którym ich potrzebuje. Inaczej PWA stanie się ciężką stroną internetową, a nie sprawnym narzędziem zwiedzania.

Warunkiem technicznym działania PWA jest bezpieczne połączenie HTTPS. Certyfikat SSL nie jest dodatkiem poprawiającym wizerunek muzeum, tylko elementem niezbędnym do prawidłowej rejestracji Service Workers i obsługi kluczowych mechanizmów aplikacji. Bez szyfrowanego połączenia architektura offline oraz część funkcji instalacyjnych nie będzie działać poprawnie.

To ma również konsekwencje organizacyjne. Muzeum potrzebuje stabilnego hostingu, sprawnej administracji domeną, kontroli wersji treści i procedury aktualizacji. PWA upraszcza dystrybucję, ale nie zwalnia z utrzymania zaplecza. Jeśli ktoś zmieni opis eksponatu, plik audio albo wersję językową, aktualizacja musi trafić do systemu treści, pamięci podręcznej i urządzeń użytkowników w sposób przewidywalny.

Co PWA może zrobić dobrze w muzeum

PWA szczególnie dobrze sprawdza się jako:

  • przewodnik po wystawie stałej lub czasowej;
  • audioprzewodnik uruchamiany kodem QR;
  • katalog obiektów z filtrowaniem i wyszukiwaniem;
  • wielojęzyczna warstwa informacyjna dla turystów;
  • narzędzie do obsługi gry miejskiej lub ścieżki edukacyjnej;
  • przewodnik rodzinny z uproszczonymi opisami i zadaniami;
  • interaktywna mapa sal, wydarzeń i punktów dostępności;
  • cyfrowy dodatek do biletu lub programu wystawy.

W tych zastosowaniach największą zaletą nie jest sama technologia offline, lecz połączenie szybkiego dostępu, jednego kodu źródłowego i łatwiejszej aktualizacji. Muzeum może rozwijać treści bez konieczności każdorazowego budowania osobnych wersji dla dwóch systemów mobilnych.

Kiedy aplikacja natywna wygrywa

Aplikacja natywna ma przewagę wtedy, gdy przewodnik powinien intensywnie korzystać z funkcji telefonu. Jest tworzona z użyciem technologii przeznaczonych dla konkretnych platform: na iOS stosuje się między innymi Swift lub Objective-C, a na Androidzie Kotlin albo Java. Dzięki temu aplikacja otrzymuje bardziej bezpośredni dostęp do systemowych interfejsów programistycznych i sprzętu.

W muzealnictwie szczególne znaczenie mają trzy obszary.

Mikrolokalizacja

Bluetooth Beacons mogą służyć do rozpoznawania położenia zwiedzającego w konkretnej sali lub przy określonym obiekcie. Przewodnik może wtedy zaproponować odpowiedni komentarz, wskazać najbliższy punkt albo zmienić kolejność prezentowanych treści.

To rozwiązanie wymaga jednak nie tylko aplikacji, lecz także infrastruktury rozmieszczonej w budynku, kalibracji i testów w realnych warunkach. Grube ściany, metalowe elementy, tłum ludzi i zmienny układ ekspozycji wpływają na jakość sygnału. Sama deklaracja obsługi mikrolokalizacji nie oznacza jeszcze, że system będzie precyzyjnie wskazywał pozycję w każdym miejscu.

Jeśli lokalizacja ma być jedynie dodatkiem, kod QR może okazać się rozsądniejszy i tańszy organizacyjnie. Jeżeli natomiast stanowi podstawę narracji wystawy, aplikacja natywna daje większe możliwości kontrolowania tego mechanizmu.

Rozszerzona rzeczywistość

Przewodnik AR może nakładać na obraz z kamery dodatkowe informacje, animacje, rekonstrukcje albo modele obiektów. W prostym scenariuszu wystarczy uruchomienie kamery i rozpoznanie znacznika. Bardziej zaawansowane doświadczenia wymagają jednak stabilnego śledzenia przestrzeni, płynnego renderowania oraz dostępu do funkcji urządzenia, których przeglądarka nie zawsze obsługuje w takim samym zakresie.

Dlatego PWA może być dobrym wyborem dla lekkich elementów rozszerzonej rzeczywistości, ale nie należy zakładać, że zastąpi aplikację natywną we wszystkich projektach AR. Gdy wystawa opiera się na precyzyjnych modelach 3D, interakcji w czasie rzeczywistym i pracy z kamerą, rozwiązanie natywne zapewnia bezpieczniejszą podstawę techniczną.

Długotrwałe korzystanie i funkcje systemowe

Aplikacja natywna może lepiej wykorzystać powiadomienia, pracę w tle, integrację z systemowym audio, określone mechanizmy dostępności czy bardziej rozbudowane przechowywanie danych. Jeżeli muzeum chce budować stałą relację z użytkownikiem, informować o kolejnych wydarzeniach i rozwijać konto zwiedzającego, aplikacja instalowana na urządzeniu daje więcej narzędzi.

Trzeba jednak odróżnić potencjał od rzeczywistej potrzeby. Funkcja dostępna technicznie nie zawsze poprawia doświadczenie zwiedzania. Powiadomienia mogą informować o nowych wystawach, ale mogą też stać się kolejnym źródłem komunikacyjnego szumu. Rozbudowany profil użytkownika nie będzie atutem, jeśli większość odbiorców odwiedza muzeum raz podczas pobytu w mieście.

PWA kontra aplikacja natywna na iPhonie

Wybór technologii dla muzeum często komplikuje sytuacja na urządzeniach Apple. Obsługa PWA pojawiła się w systemie iOS od wersji 11.3, ale nie wszystkie zaawansowane możliwości webowe są dostępne w przeglądarkowym silniku WebKit w takim samym zakresie jak w środowisku natywnym.

Z perspektywy muzeum oznacza to konieczność testowania nie tylko na jednym modelu telefonu, lecz także w różnych konfiguracjach systemowych. Przewodnik może działać poprawnie jako katalog tekstów i nagrań, a jednocześnie mieć ograniczenia przy obsłudze określonego trybu kamery, lokalizacji albo pracy w tle.

Nie należy przy tym sprowadzać sprawy do tezy, że PWA na iOS jest rozwiązaniem nieużytecznym. Dla podstawowego mobilnego przewodnika po muzeum PWA może być wystarczająca również na urządzeniach Apple. Trzeba po prostu zaprojektować funkcje zgodnie z realnymi możliwościami środowiska, zamiast przenosić do przeglądarki założenia stworzone pierwotnie dla aplikacji natywnej.

Przed wdrożeniem warto sprawdzić przede wszystkim:

  • czy przewodnik otwiera się poprawnie po zeskanowaniu kodu QR;
  • czy najważniejsze treści są dostępne po utracie połączenia;
  • czy pliki audio nie zatrzymują się przy blokadzie ekranu;
  • czy aplikacja zachowuje stan zwiedzania po zamknięciu karty;
  • czy dodanie skrótu do ekranu głównego jest zrozumiałe dla użytkownika;
  • czy funkcje kamery, lokalizacji i odtwarzania multimediów działają w używanych wersjach systemu;
  • czy projekt pozostaje czytelny na starszych telefonach i przy słabszym połączeniu.

Testy powinny odbywać się w salach wystawowych, nie tylko przy biurku zespołu projektowego. W muzeum występują odbicia światła, grube mury, zatłoczone galerie, ograniczony zasięg i użytkownicy korzystający z telefonów o bardzo różnej wydajności.

PWA upraszcza wejście do przewodnika, aplikacja natywna poszerza granice doświadczenia. Spór między nimi rozstrzyga nie moda, lecz wymagania wystawy.

Koszt wdrożenia to także koszt późniejszych zmian

Jedna z najważniejszych różnic między PWA a aplikacją natywną dotyczy nie tylko pierwszego etapu budowy, lecz całego cyklu życia produktu. PWA może korzystać z jednego kodu źródłowego dla iOS i Androida. To zwykle ogranicza zakres prac przy wdrożeniu oraz późniejszym utrzymaniu w porównaniu z tworzeniem dwóch osobnych aplikacji natywnych.

Nie oznacza to, że PWA jest z definicji tania. Zakres może obejmować system zarządzania treścią, nagrania audio, tłumaczenia, mapę, wyszukiwarkę, dostępność cyfrową, analitykę, tryb offline, materiały wideo i integrację z biletem. Koszt zależy od liczby ekranów, obiektów, języków oraz poziomu interakcji. Nie da się uczciwie podać jednej uniwersalnej kwoty dla przewodnika muzealnego bez opisania tych elementów.

Aplikacja natywna generuje dodatkową pracę związaną z platformami. Nawet jeśli część funkcji jest wspólna, trzeba brać pod uwagę różnice systemowe, publikację w sklepach, proces aktualizacji i testy na urządzeniach. Pojawiają się również koszty organizacyjne: przygotowanie materiałów do kart aplikacji, obsługa procesu zatwierdzania oraz reagowanie na zmiany wymagań platform.

PWA ma tu przewagę operacyjną. Aktualizacja treści odbywa się po stronie serwera, więc muzeum może poprawić opis, zmienić harmonogram albo dodać nową wersję językową bez oczekiwania, aż użytkownik pobierze aktualizację ze sklepu. Trzeba tylko prawidłowo obsłużyć pamięć podręczną. Zbyt agresywne przechowywanie starych plików może sprawić, że zwiedzający zobaczy nieaktualny materiał, mimo że zespół redakcyjny już go zmienił.

W przypadku aplikacji natywnej aktualizacje są bardziej formalne, ale mogą zapewniać większą kontrolę nad wersją programu zainstalowaną na urządzeniu. To bywa istotne przy wystawach, w których treści są ściśle powiązane z konkretną wersją systemu lub urządzeniem dodatkowym.

Jak porównać rozwiązania przed decyzją

Zamiast pytać wyłącznie o cenę budowy, muzeum powinno zestawić oba warianty według sposobu użytkowania:

1. Czas wizyty — przy krótkiej wizycie i wydarzeniu czas instalacji działa na niekorzyść aplikacji natywnej.

2. Powtarzalność odwiedzin — stała publiczność może zaakceptować instalację, jeśli otrzyma funkcje wykorzystywane przy kolejnych wizytach.

3. Rodzaj treści — tekst, audio i zdjęcia dobrze pasują do PWA; zaawansowane 3D i AR częściej przemawiają za rozwiązaniem natywnym.

4. Zależność od internetu — oba rozwiązania mogą pracować offline, ale w PWA wymaga to starannie zaprojektowanych Service Workers i pamięci podręcznej.

5. Integracja z budynkiem — beacony, urządzenia dodatkowe i mikrolokalizacja zwiększają sens wyboru aplikacji natywnej.

6. Tempo aktualizacji — przy często zmienianym programie wystawy wygoda aktualizacji po stronie serwera jest mocnym argumentem za PWA.

7. Zespół utrzymania — rozwiązanie powinno odpowiadać nie tylko możliwościom wykonawcy, lecz także temu, kto będzie później zarządzał treścią i awariami.

8. Dostępność — przewodnik musi działać z powiększeniem tekstu, czytnikami ekranu, napisami i alternatywnymi opisami, niezależnie od wybranej technologii.

Takie porównanie często prowadzi do rozwiązania mieszanego. Podstawowy przewodnik może działać jako PWA, a osobna aplikacja natywna może obsługiwać wybrane doświadczenia wymagające AR, mikrolokalizacji lub bardziej intensywnej pracy sprzętu. Nie zawsze trzeba wtłaczać wszystkie funkcje do jednego produktu.

Jaki wariant wybrać dla konkretnego typu muzeum

Małe muzeum i wystawa czasowa

Dla małej instytucji, która nie ma rozbudowanego zespołu technicznego, PWA zwykle będzie prostszym punktem wyjścia. Kod QR przy wejściu i przy eksponatach może prowadzić do opisów, nagrań oraz materiałów w kilku językach. Zespół redakcyjny aktualizuje treści w jednym środowisku, a zwiedzający nie musi szukać aplikacji w sklepie.

Wystawa czasowa dodatkowo przemawia za krótszym cyklem wdrożenia. Jeśli przewodnik ma działać przez kilka miesięcy, budowanie dwóch aplikacji natywnych może być nieproporcjonalne do okresu ich wykorzystania. PWA pozwala też zachować stronę jako archiwum wystawy, jeśli muzeum chce udostępnić część materiałów po jej zakończeniu.

Duża instytucja z programem lojalnościowym

Muzeum, które prowadzi rozbudowany program wydarzeń, sprzedaje bilety online i chce regularnie komunikować się z odbiorcami, może rozważyć aplikację natywną. Jej sens rośnie, gdy użytkownik ma powód, by wracać do niej poza pojedynczą wizytą: przechowywać bilety, śledzić kolekcję, odbierać spersonalizowane rekomendacje albo korzystać z funkcji dostępnych podczas wielu ekspozycji.

W takim przypadku aplikacja nie jest już tylko przewodnikiem. Staje się kanałem obsługi relacji z publicznością. To większy projekt, ale również inny rodzaj wartości. Sama obecność w sklepie nie wystarczy; aplikacja musi oferować doświadczenie, którego nie da się wygodnie zastąpić stroną internetową.

Muzeum eksperymentalne i wystawa immersyjna

Jeśli główną atrakcją są rekonstrukcje 3D, śledzenie ruchu, reagowanie na położenie zwiedzającego i rozbudowana praca z kamerą, rozwiązanie natywne będzie bezpieczniejszym wyborem. W tym scenariuszu aplikacja dla zwiedzających muzeum jest częścią instalacji artystyczno-technologicznej, a nie tylko warstwą informacyjną.

Trzeba jednak zaplanować sprzęt, kompatybilność i obsługę użytkownika. Im bardziej doświadczenie zależy od konkretnej funkcji telefonu, tym większe znaczenie ma lista wspieranych urządzeń oraz sposób postępowania w przypadku telefonu niespełniającego wymagań. Dobrą praktyką może być zapewnienie równoległej ścieżki: podstawowego opisu lub nagrania dostępnego przez PWA oraz pełnego doświadczenia natywnego dla osób, które mogą z niego skorzystać.

Najrozsądniejszy model wdrożenia: zacząć od rdzenia

W wielu projektach muzealnych nie trzeba podejmować decyzji o wszystkich funkcjach jednocześnie. Można zacząć od rdzenia przewodnika: struktury treści, kodów QR, nagrań, wersji językowych, wyszukiwarki i trybu ograniczonego dostępu offline. Taki etap pozwala sprawdzić, czy zwiedzający w ogóle korzystają z cyfrowej warstwy wystawy i które elementy są dla nich rzeczywiście użyteczne.

Dopiero później warto dodawać funkcje wymagające głębszej integracji. Jeśli dane z użytkowania pokażą, że odbiorcy potrzebują mikrolokalizacji albo rozbudowanej warstwy AR, można zaprojektować aplikację natywną jako osobny moduł. Jeśli natomiast największym problemem okaże się brak tłumaczeń, słaba jakość audio lub nieczytelna nawigacja, zmiana technologii nie rozwiąże sprawy.

Technologia nie naprawi źle opracowanej narracji. Przewodnik powinien mieć jasną strukturę, krótkie komunikaty, logiczne przejście między obiektami i alternatywy dla osób, które nie mogą lub nie chcą korzystać z dźwięku. PWA i aplikacja natywna są nośnikami treści. Nie zastąpią kuratorskiej selekcji, redakcji ani projektowania doświadczenia zwiedzającego.

Dla instytucji planującej wdrożenie przewodnika multimedialnego punktem wyjścia powinien być opis trasy użytkownika, a nie lista modnych funkcji. Trzeba zapisać, co zwiedzający robi przed wejściem, przy pierwszym obiekcie, w miejscu bez zasięgu, po zmianie sali i po zakończeniu wizyty. Dopiero wtedy widać, czy potrzebna jest instalowana aplikacja, czy szybki przewodnik uruchamiany z kodu QR.

Werdykt: PWA jako domyślny wybór, natywna technologia dla konkretnych potrzeb

Jeśli muzeum potrzebuje dostępnego od ręki przewodnika z opisami, audio, zdjęciami, mapą i kilkoma wersjami językowymi, PWA jest zwykle bardziej racjonalnym rozwiązaniem. Ogranicza barierę wejścia, korzysta z jednego kodu źródłowego dla iOS i Androida, pozwala aktualizować treści po stronie serwera i może obsługiwać tryb offline dzięki Service Workers. Warunkiem jest HTTPS oraz dobrze zaprojektowana pamięć podręczna.

Aplikacja natywna ma przewagę wtedy, gdy jej funkcje wymagają bezpośredniego dostępu do sprzętu: mikrolokalizacji Bluetooth Beacons, zaawansowanej rzeczywistości rozszerzonej, rozbudowanej pracy w tle albo silnej integracji z systemem telefonu. Wtedy dodatkowy etap instalacji może być uzasadniony jako cena za bogatsze doświadczenie.

W praktyce wybór nie powinien brzmieć: PWA albo aplikacja natywna za wszelką cenę. Trafniejsze pytanie brzmi: które elementy przewodnika muszą być dostępne natychmiast, a które rzeczywiście wymagają aplikacji instalowanej na urządzeniu? Najczęściej odpowiedź prowadzi do PWA jako podstawy i technologii natywnej tam, gdzie wystawa potrzebuje możliwości, których przeglądarka nie zapewnia wystarczająco dobrze.

Najczęściej zadawane pytania

Czym różni się PWA od zwykłej strony internetowej?
PWA posiada własną architekturę opartą na manifeście aplikacji oraz skryptach Service Workers, co pozwala na przechowywanie wybranych treści w pamięci urządzenia i pracę w trybie offline.
Czy PWA wymaga połączenia z internetem w muzeum?
Nie zawsze. Dzięki odpowiedniemu zaprojektowaniu pamięci podręcznej i skryptom Service Workers, PWA może działać w miejscach o słabym zasięgu lub bez dostępu do sieci, po wcześniejszym pobraniu wybranych zasobów.
Dlaczego aplikacja natywna jest lepsza do rzeczywistości rozszerzonej (AR)?
Aplikacje natywne zapewniają bardziej bezpośredni dostęp do sprzętu i interfejsów systemowych, co jest kluczowe dla stabilnego śledzenia przestrzeni i płynnego renderowania zaawansowanych doświadczeń AR.
Czy PWA działa na telefonach iPhone?
Tak, PWA działa na urządzeniach Apple, jednak ze względu na ograniczenia silnika WebKit, funkcje takie jak obsługa kamery czy lokalizacji mogą mieć inne ograniczenia niż w środowisku natywnym.
Co jest niezbędne do poprawnego działania PWA w muzeum?
Kluczowym wymogiem technicznym jest bezpieczne połączenie HTTPS, które jest niezbędne do rejestracji Service Workers i obsługi mechanizmów offline.