Krótka odpowiedź
Jeśli z narzędzia mają korzystać Twoi pracownicy albo stali klienci firmy, w większości przypadków zacząłbym od aplikacji webowej — najlepiej takiej, którą da się zainstalować na telefonie jak zwykłą aplikację, czyli PWA. Działa na każdym urządzeniu z przeglądarką, aktualizujesz ją w jednym miejscu i nie czekasz na akceptację w sklepach z aplikacjami.
Aplikacja mobilna instalowana z App Store lub Google Play ma sens wtedy, gdy potrzebujesz pełnego dostępu do funkcji telefonu, pracy w tle, niezawodnego działania bez internetu albo obecności w sklepie, w którym klienci szukają takich usług. Poniżej rozkładam ten wybór na części, żebyś mógł zdecydować na podstawie swojej sytuacji, a nie mody.
Aplikacja webowa, PWA i aplikacja natywna — czym się różnią
Słowo „aplikacja” obejmuje dziś kilka różnych rzeczy. Zanim zaczniesz porównywać oferty, warto nazwać je po imieniu:
- Aplikacja webowa działa w przeglądarce. Użytkownik wchodzi pod adres, loguje się i pracuje — na komputerze, tablecie albo telefonie. Przykłady z codzienności to bankowość internetowa, panel firmy kurierskiej czy program do faktur w przeglądarce.
- PWA, czyli progresywna aplikacja webowa, to aplikacja webowa z dodatkowymi możliwościami. Można ją dodać do ekranu telefonu, otwiera się w osobnym oknie bez paska adresu, może częściowo działać bez internetu i wysyłać powiadomienia.
- Aplikacja natywna powstaje osobno dla systemów iOS i Android albo w technologii wieloplatformowej, takiej jak Flutter czy React Native, z jednym kodem na oba systemy. Instaluje się ją ze sklepu z aplikacjami.
Między tymi rozwiązaniami nie ma przepaści. Ta sama logika i te same dane mogą obsługiwać panel w przeglądarce dla biura i aplikację na telefon dla pracowników w terenie. Kluczowe pytanie brzmi więc nie „co jest lepsze”, tylko „kto, gdzie i jak często będzie z tego korzystać”.
| Kryterium | Aplikacja webowa | PWA | Aplikacja natywna |
|---|---|---|---|
| Jak trafia do użytkownika | Link otwierany w przeglądarce | Link, a potem ikona na ekranie telefonu | Sklep App Store i Google Play |
| Aktualizacje | Od razu dla wszystkich | Od razu dla wszystkich | Nowa wersja przechodzi weryfikację sklepu i musi trafić na telefony użytkowników |
| Praca bez internetu | Zwykle nie | Częściowo, jeśli tak ją zaprojektujesz | Tak, w zakresie zaprojektowanym przez wykonawcę |
| Powiadomienia | E-mail, SMS, powiadomienia przeglądarki z ograniczeniami | Powiadomienia web push, także na iPhonie po dodaniu do ekranu | Pełne powiadomienia systemowe |
| Dostęp do funkcji telefonu | Podstawowy: aparat, lokalizacja, pliki | Jak w przeglądarce, plus instalacja i tryb offline | Najszerszy: praca w tle, Bluetooth, NFC, czujniki |
| Wersje do utrzymania | Jedna | Jedna | Dwie platformy plus zaplecze |
Tabela upraszcza — szczegóły zależą od konkretnego projektu oraz od tego, jak zmieniają się przeglądarki i systemy. Traktuj ją jako listę rzeczy do sprawdzenia, a nie gotowy werdykt.
Kiedy wystarczy aplikacja webowa
Aplikacja w przeglądarce sprawdza się wszędzie tam, gdzie praca odbywa się głównie przy komputerze albo użytkownik loguje się od czasu do czasu. Typowe przykłady w małej i średniej firmie:
- panel do obsługi zamówień, zleceń lub zgłoszeń,
- narzędzie dla biura: grafik, kartoteki klientów, dokumenty, raporty,
- panel klienta, w którym kontrahent sprawdza status zamówienia i pobiera faktury,
- formularze i konfiguratory, z których klient korzysta raz czy dwa razy w roku.
Klient, który zamawia u Ciebie kilka razy w roku, raczej nie zainstaluje dodatkowej aplikacji. Link w mailu, który otwiera jego konto w przeglądarce, jest dla niego wygodniejszy. Dla Ciebie to jedna wersja do utrzymania i zmiany widoczne od razu po publikacji.
Aplikacja webowa musi przy tym dobrze działać na telefonie. Układ dopasowany do małego ekranu, duże przyciski i krótkie formularze to dziś standard, a nie dodatek — zwłaszcza gdy część użytkowników otwiera link z wiadomości na smartfonie.
PWA: aplikacja z przeglądarki, którą można zainstalować
PWA to często najrozsądniejszy kompromis. Technicznie to wciąż aplikacja webowa, ale użytkownik może dodać ją do ekranu telefonu i uruchamiać jak każdą inną aplikację. Na Androidzie przeglądarka Chrome może sama zaproponować instalację. Na iPhonie robi się to z menu udostępniania w Safari, wybierając dodanie do ekranu początkowego.
Co daje PWA w praktyce:
- ikonę na ekranie i osobne okno — bez paska adresu, więc wygląda i działa jak aplikacja,
- pracę przy słabym zasięgu — część ekranów i danych może być dostępna offline, a zmiany mogą trafić na serwer po odzyskaniu połączenia, jeśli tak to zaprojektujesz,
- powiadomienia — także na iPhonie, bo Apple dodało obsługę powiadomień web push dla aplikacji dodanych do ekranu początkowego w iOS i iPadOS 16.4,
- brak pośrednika — nie publikujesz aplikacji w sklepie, nie czekasz na weryfikację i nie zakładasz kont deweloperskich.
Są też ograniczenia, o których warto wiedzieć przed startem. Powiadomienia na iPhonie działają dopiero po dodaniu aplikacji do ekranu i po zgodzie użytkownika, więc nie każdy je włączy. Część funkcji urządzenia jest w przeglądarce dostępna tylko na wybranych systemach — na przykład obsługa NFC z poziomu strony działa w Chrome na Androidzie, ale nie na iPhonie. Praca w tle i głęboka integracja z systemem to wciąż domena aplikacji natywnych.
PWA dobrze sprawdza się w narzędziach dla pracowników. W modułowym systemie StackERP, z którym współpracuję przy systemach dla firm, jednym z modułów są dostawy, a w nich aplikacja kierowcy działająca jako PWA — obok tras, przydziałów, statusów dostaw i rozliczeń. Taka aplikacja nie wymaga publikacji w sklepach, a kierowca uruchamia ją z ikony na telefonie.
Kiedy naprawdę potrzebujesz aplikacji mobilnej
Aplikacja natywna albo wieloplatformowa jest uzasadniona, gdy któraś z poniższych rzeczy jest dla Ciebie kluczowa, a nie tylko „miła”:
- Intensywne korzystanie z funkcji telefonu — skanowanie dużej liczby kodów, łączenie z urządzeniami przez Bluetooth, NFC, śledzenie lokalizacji w tle.
- Niezawodna praca offline — na przykład u pracowników, którzy przez kilka godzin są w miejscach bez zasięgu, a dane muszą się potem poprawnie zsynchronizować.
- Codzienne korzystanie przez klientów — aplikacja, którą klient otwiera regularnie, z kartą lojalnościową, zamówieniami i powiadomieniami, które muszą docierać pewnie.
- Obecność w sklepie — gdy klienci szukają usług, wpisując nazwę w App Store lub Google Play, a obecność tam jest częścią marki.
Pamiętaj, że sklepy mają swoje zasady. Wytyczne Apple wprost wymagają, żeby aplikacja oferowała coś więcej niż przepakowana witryna — strona zamknięta w aplikacji, bez własnych funkcji, może nie przejść weryfikacji. W Google Play konta osobiste deweloperów założone po 13 listopada 2023 r. muszą przed publikacją przeprowadzić test zamknięty z co najmniej 12 testerami przez 14 dni. To nie są przeszkody nie do pokonania, ale wpływają na harmonogram.
Do tego dochodzą koszty, których w aplikacji webowej nie ma: konta deweloperskie, dwie platformy do testowania i dostosowywanie aplikacji do kolejnych wersji iOS i Androida. Rozpisałem je szerzej w artykule o tym, ile kosztuje aplikacja dla firmy.
Sześć pytań, które rozstrzygają wybór
- Kto będzie z tego korzystać? Pracownicy, którym możesz przekazać link i instrukcję, czy klienci, których trzeba przekonać do instalacji?
- Jak często? Codziennie, kilka razy w tygodniu czy kilka razy w roku? Im rzadziej, tym mocniej przemawia to za przeglądarką.
- Gdzie? Przy biurku, w sklepie, w samochodzie, na budowie? Słaby zasięg i praca jedną ręką to inne wymagania niż biuro.
- Jakich funkcji telefonu potrzebujesz? Aparat i lokalizacja zwykle wystarczą w przeglądarce. Bluetooth, NFC czy pracę w tle sprawdź przed decyzją.
- Jak ważne są powiadomienia? Jeśli muszą docierać do każdego bez wyjątku, porównaj powiadomienia web push, aplikację natywną i zwykły SMS lub e-mail.
- Kto będzie to utrzymywać? Każda dodatkowa platforma to kolejne testy, aktualizacje i koszty przez cały okres działania aplikacji.
Jeśli na większość pytań odpowiadasz „pracownicy, w biurze lub w terenie, aparat i lokalizacja wystarczą”, aplikacja webowa albo PWA prawie na pewno będzie dobrym startem. Jeśli w odpowiedziach pojawia się praca w tle, specjalistyczny sprzęt i codzienne korzystanie przez dużą grupę klientów, warto policzyć aplikację natywną.
O czym pamiętać niezależnie od wyboru
Forma aplikacji nie zwalnia z podstaw. W każdym wariancie trzeba zadbać o:
- bezpieczeństwo logowania i danych — szyfrowane połączenie, role i uprawnienia, kopie zapasowe,
- RODO — jeśli aplikacja przetwarza dane klientów lub pracowników, musisz wiedzieć, gdzie są przechowywane i kto ma do nich dostęp,
- dostępność — czytelne kontrasty, odpowiednią wielkość przycisków i obsługę czytników ekranu; w części firm to także obowiązek prawny,
- eksport danych — dane należą do Ciebie i powinno dać się je pobrać, jeśli kiedyś zmienisz rozwiązanie.
Warto też od początku zaprojektować zaplecze aplikacji — bazę danych, logikę i interfejs API — tak, żeby mogło obsłużyć kolejne warstwy. Wtedy wybór między przeglądarką a telefonem nie jest decyzją na zawsze.
Jak podchodzę do tego wyboru
Przy systemach dla firm pracuję z partnerem technicznym, StackERP. Najpierw sprawdzam, jak wygląda praca: kto co robi, w jakim miejscu i na jakim urządzeniu. Forma aplikacji wynika z tych odpowiedzi, a nie odwrotnie.
Najczęściej proponuję start od aplikacji webowej lub PWA, która obsługuje najważniejszy proces. Taka pierwsza wersja szybciej trafia do ludzi i pokazuje, czego naprawdę potrzebują. Jeśli po kilku tygodniach okaże się, że brakuje funkcji dostępnych tylko w aplikacji natywnej, zaplecze i dane zostają, a dochodzi nowa warstwa na telefonie. Więcej o takim podejściu piszę w artykule o tym, jak zbudować pierwszą wersję systemu.
Zakres i cenę takiego narzędzia ustalamy po rozmowie, gdy wiadomo, kto będzie z niego korzystał i z jakimi systemami ma się połączyć.