Aplikacja webowa czy mobilna: jak wybrać po miejscu użycia

Aplikacja webowa czy mobilna — o tym rozstrzyga nie technologia, tylko miejsce, w którym użytkownik sięga po produkt. Aplikacja webowa działa w przeglądarce pod adresem internetowym i nie wymaga instalacji; aplikacja mobilna jest pobierana ze sklepu, ma ikonę na ekranie telefonu i dostęp do funkcji urządzenia. Poniżej znajdziesz kryterium wyboru oparte na sytuacji użytkownika oraz rzecz, którą większość poradników pomija: co zaprojektować dziś, żeby dołożenie wersji mobilnej za rok nie oznaczało przepisywania backendu.

Czym różni się aplikacja webowa od mobilnej w codziennej pracy

Różnica sprowadza się do trzech rzeczy: sposobu dostarczania nowej wersji, dostępu do sprzętu i tego, kto stoi między Tobą a użytkownikiem.

• Wydania. W aplikacji webowej wdrażasz poprawkę i mają ją wszyscy przy następnym odświeżeniu. W aplikacji mobilnej każde wydanie przechodzi przez recenzję sklepu, a potem czekasz, aż użytkownicy zaktualizują je u siebie. Przez jakiś czas w obiegu działa kilka wersji naraz i backend musi to znieść.
• Sprzęt. Przeglądarka obsłuży aparat i podstawową lokalizację, ale praca w tle, ciągły odczyt GPS, NFC, Bluetooth i pełny tryb offline z własną bazą danych to domena aplikacji instalowanej.
• Pośrednik. Aplikacja mobilna żyje w regulaminie Google i Apple. Aplikacja webowa żyje pod Twoją domeną i nikt jej stamtąd nie zdejmie.

Trzecia forma, czyli aplikacja webowa instalowana na ekranie telefonu, ma własne zasady i własne ograniczenia — opisuje je osobny tekst o tym, co potrafi PWA na iOS i Androidzie.

Gdzie fizycznie jest użytkownik w chwili, gdy sięga po aplikację

Miejsce użycia to najmocniejsze kryterium wyboru, bo determinuje wszystko pozostałe: długość sesji, liczbę wolnych rąk, jakość łącza i to, czy użytkownik w ogóle patrzy na ekran. Zanim porównasz technologie, opisz jedną scenę: gdzie stoi ta osoba, co trzyma i ile ma czasu.

Zadaj trzy pytania:

1. Ile trwa jedna sesja? Kilkanaście sekund kilkadziesiąt razy dziennie to profil mobilny. Czterdzieści minut przy jednym zadaniu to profil biurkowy — nikt nie wprowadza danych z faktury na ekranie telefonu, jeśli ma obok monitor.
2. Czy użytkownik ma wolne obie ręce? Magazynier z paczką, technik na drabinie i kierowca przy rozładunku mają jedną rękę i często rękawice. To wymusza duże cele dotykowe, skanowanie kodu zamiast przepisywania i minimum pól.
3. Co się dzieje, gdy nie ma zasięgu? Jeśli odpowiedź brzmi „proces się zatrzymuje i ktoś traci godzinę”, potrzebujesz zapisu lokalnego i synchronizacji po powrocie sieci — a to argument za aplikacją instalowaną.

Druga wersja jest decyzją, którą da się sprawdzić. Pierwsza jest życzeniem i wraca na każdym kolejnym spotkaniu.

Sytuacja użytkownika, rekomendacja i co przygotować na przyszłość

Poniższa tabela łączy typowe sytuacje z rekomendacją i z tym, co warto zabezpieczyć w architekturze, nawet jeśli mobilnej dziś nie budujesz.

Co w architekturze przesądza, że mobilną dołożysz bez przepisywania backendu

Możliwość dołożenia aplikacji mobilnej później przesądzają cztery decyzje podjęte na etapie projektowania weba — wszystkie kosztują niewiele dziś i bardzo dużo, gdy trzeba je nadrabiać.

Wspólne API zamiast backendu renderującego strony. Backend ma oddawać dane w formacie neutralnym dla klienta i trzymać w jednym miejscu reguły biznesowe: kto co widzi, kiedy zamówienie zmienia status, jak liczy się rabat. Jeśli te reguły siedzą w szablonach stron, aplikacja mobilna nie ma z czego korzystać i powstaje druga implementacja tej samej logiki. Ta sama zasada rządzi wymianą danych między systemami, którą opisuję szerzej przy okazji tematu integracji systemów w firmie.

Autoryzacja tokenowa, nie tylko sesja w ciasteczku. Aplikacja mobilna nie ma przeglądarkowej sesji, więc potrzebuje tokenu, który sama przechowa i odświeży. Dołożenie tego mechanizmu po fakcie oznacza przebudowę logowania, uprawnień i wszystkich miejsc, które zakładały obecność ciasteczka.

Wersjonowanie interfejsu. Wydania mobilne trafiają do użytkowników z opóźnieniem, więc backend musi obsługiwać starszą i nowszą wersję naraz. Nadaj adresowi API wersję od początku i przyjmij zasadę: pola się dodaje, a usuwa dopiero po zapowiedzi i okresie przejściowym.

Wspólny system projektowy. Kolory, typografia, odstępy i stany komponentów zapisane jako tokeny, a nie wpisane na sztywno w arkusz stylów strony, pozwalają odtworzyć ten sam produkt na telefonie bez projektowania go od zera.

To zdanie wpisz do briefu i do zakresu prac. Jest krótkie, a rozstrzyga o tym, czy za rok rozmawiasz o nowym kliencie tego samego systemu, czy o drugim projekcie.

Ile realnie kosztuje wejście do sklepów i utrzymanie się w nich

Opłaty za konta są symboliczne: Google Play Console to 25 USD jednorazowo, a Apple Developer Program 99 USD rocznie. Kosztem jest proces, który zaczyna się po opłaceniu konta.

Każde wydanie przechodzi weryfikację: Apple sprawdza aplikacje ręcznie w ramach App Review, Google w większym stopniu automatycznie. Odrzucone wydanie to poprawka i kolejne podejście, więc harmonogram publikacji planuje się z zapasem, a nie na dzień przed kampanią. Do tego dochodzi przymus nadążania za wymaganiami platform — od 31 sierpnia 2026 nowe aplikacje i aktualizacje w Google Play muszą targetować Androida 16 (API 36). To praca, która nie dodaje użytkownikowi żadnej funkcji, a i tak musi być wykonana i opłacona.

Aplikacja webowa nie ma tego składnika w ogóle: wdrażasz, kiedy chcesz, i nikt Ci nie recenzuje wydania. Jeśli chcesz zobaczyć, jak forma aplikacji przekłada się na budżet, rozkładam to na czynniki w tekście o tym, ile kosztuje aplikacja mobilna.

Jedna baza kodu czy dwie aplikacje natywne

Gdy decyzja o wersji mobilnej zapada, drugim pytaniem jest liczba baz kodu. Do wyboru są rozwiązania cross-platform — React Native, Flutter i Kotlin Multiplatform, stabilny od listopada 2023 — albo dwie osobne aplikacje natywne na Androida i iOS.

Wspólna baza kodu ma sens, gdy obie platformy mają robić to samo, a interfejs opiera się na standardowych ekranach, listach i formularzach. Dwie aplikacje natywne wygrywają, gdy produkt mocno korzysta z możliwości konkretnego systemu, ma nietypowe animacje albo integruje się ze sprzętem w sposób, dla którego nie istnieje gotowy most między technologiami.

To pytanie zadaj dopiero po ustaleniu miejsca użycia i zakresu. Kolejność jest ważna, bo decyzja o technologii wynika z listy funkcji, a nie odwrotnie — dlatego najpierw domyka się zakres pierwszej wersji aplikacji, a dopiero potem wybiera stos. Pozostałe etapy, od projektu po wdrożenie, prowadzi przewodnik o tym, jak stworzyć aplikację mobilną.

Jeśli chcesz uporządkować te decyzje przed pierwszą rozmową z wykonawcą, przejdź przez sześć kroków w kreatorze briefu — opiszesz w nim, kto i gdzie będzie korzystał z produktu, a to jest dokładnie ten materiał, z którego wychodzi rekomendacja formy aplikacji.