Mobilalkalmazás, webes alkalmazás vagy PWA? Döntési útmutató cégeknek

„Kéne egy app” — sok projekt így indul, és a mondat mögött nagyon különböző igények állhatnak: a terepen dolgozó kollégák munkalapja, egy ügyfeleknek szóló foglalófelület vagy egy hűségprogram. A jó döntéshez nem a technológiából, hanem a felhasználókból érdemes kiindulni: kik, milyen eszközön, milyen körülmények között és milyen gyakran fogják használni. Ebből az útmutatóból kiderül, mikor elég a böngésző, mikor éri meg a PWA, és mikor kell valódi mobilalkalmazás.

A lehetőségek röviden

• Webes alkalmazás: böngészőben fut, telepítés nélkül, bármilyen eszközön. Egy kódbázis, azonnali frissítés — minden felhasználó mindig a legújabb verziót látja.
• PWA (progresszív webalkalmazás): webes technológiával készül, de az MDN meghatározása szerint telepíthető az eszközre, offline is működhet, és integrálódhat az eszközzel. A kezdőképernyőről indul, mint egy app — alkalmazásbolt nélkül.
• Cross-platform app (például React Native): egy közös kódbázisból készül iOS-re és Androidra. A React Native a platform natív felületi elemeit használja, így a felhasználó szemében natív alkalmazásként viselkedik.
• Natív app: külön fejlesztés iOS-re (jellemzően Swift) és Androidra (jellemzően Kotlin). A legmélyebb platformintegrációt adja, de két kódbázist jelent, két fejlesztési és karbantartási vonallal.

Belső céges eszköz vagy ügyfeleknek szóló app?

Ez a legfontosabb elágazás. Belső eszköznél — munkalap, raktári leltár, helyszíni felmérés, jóváhagyások — a felhasználók köre ismert, a bevezetést te irányítod, és senkinek sem kell egy alkalmazásboltban rátalálnia. Itt gyakran a webes alkalmazás vagy a PWA a leggyorsabb és legegyszerűbben fenntartható út, különösen, ha a mobilos felület egy nagyobb egyedi szoftver része. Érdemes azt is tisztázni, hogy a kollégák céges eszközt vagy saját telefont használnak: saját telefonnál a böngészős megoldás kisebb belépési küszöb, mert semmit nem kell telepíteni.

Ügyfeleknek szóló alkalmazásnál más a helyzet. Ha az ügyfeleid alkalmazásboltban keresnek, ha a megbízható push értesítés üzleti kérdés (időpont-emlékeztető, rendelési státusz), vagy ha a márkádnak fontos az áruházi jelenlét, a natív vagy cross-platform app lehet a jobb választás. Tedd fel őszintén a kérdést: tényleg letöltik és megtartják az ügyfeleid az appot, vagy elég nekik egy gyors, mobilbarát weboldal?

Eszközfunkciók: mit tud a böngésző, és mit nem?

A webes technológia sokat fejlődött, de a képességek böngészőnként és platformonként eltérnek. Ezt mindig a ténylegesen használt eszközökön kell ellenőrizni, nem általánosságban.

Az MDN a böngészős NFC- és Bluetooth-támogatást kísérleti, korlátozott elérhetőségű technológiaként jelöli (Web NFC, Web Bluetooth). Ha a munkafolyamat NFC-címkék olvasására, mérőeszközökhöz vagy hordozható nyomtatókhoz való Bluetooth-kapcsolatra épül, és iPhone-on is működnie kell, a böngésző nem lesz elég.

Push értesítés és offline működés — a két gyakori döntő érv

Sokáig az volt a natív app egyik legerősebb érve, hogy webről nem lehetett push értesítést küldeni iPhone-ra. Ez megváltozott: a WebKit bejelentése szerint iOS és iPadOS 16.4 óta a kezdőképernyőre telepített webalkalmazások is kérhetnek engedélyt értesítések küldésére. A feltétel viszont lényeges: a felhasználónak előbb a kezdőképernyőre kell tennie a webappot. Belső eszköznél ezt egy betanításon meg lehet mutatni; ügyfeleknél, ahol az értesítés üzletileg kritikus, a natív vagy cross-platform app kiszámíthatóbb.

Az offline működés terepi munkánál — pincében, ipari csarnokban, külterületen — gyakran nem extra, hanem alapkövetelmény. PWA-ban service workerrel, natív és React Native appban helyi adattárolással oldható meg. A nehéz rész mindkét esetben ugyanaz: mi történik, ha két kolléga offline ugyanazt az adatot módosítja, és később szinkronizálnak? Ezt az ütközéskezelést már a tervezésnél le kell írni, mert utólag beépíteni sokkal drágább.

Alkalmazásboltok: fiókok, díjak, felülvizsgálat

Ha natív vagy cross-platform app mellett döntesz, az áruházak szabályai is a projekt részévé válnak:

• Apple App Store: a közzétételhez Apple Developer Program-tagság kell, amely az Apple oldala szerint éves díjas (99 USD/év). Minden alkalmazást és frissítést az App Review ellenőriz az áruházi irányelvek alapján. Az Apple szerint a beküldések 90%-át átlagosan 24 órán belül elbírálják — egy elutasítás és javítás azonban plusz kört jelenthet, ezt az ütemezésben érdemes tartalékolni.
• Google Play: a fejlesztői regisztrációnak a Google súgója szerint egyszeri, 25 USD-s díja van. A 2023. november 13. után létrehozott személyes fejlesztői fiókoknál éles közzététel előtt zárt tesztet is kell futtatni: legalább 12 tesztelővel, 14 napon át folyamatosan.
• Fiók a céged nevére: céges appot érdemes eleve a céged nevére szóló szervezeti fejlesztői fiókból közzétenni, nem a fejlesztő vagy egy munkatárs magánfiókjából. Erről a Kié a forráskód? cikkünkben részletesebben is írtunk.

Karbantartás: egy app sosem kész

Mobilalkalmazásnál a karbantartás nem opció. Az operációs rendszerek rendszeresen új verziót kapnak, a felhasznált könyvtárakhoz biztonsági frissítések jönnek, az áruházak pedig időről időre szigorítanak. A Google Play például cél-API-szint követelményeket ír elő: az új alkalmazásoknak és frissítéseknek egy friss Android-verziót kell célozniuk, a régóta nem frissített appok pedig az újabb eszközökön elérhetetlenné válhatnak az új felhasználók számára.

Webes alkalmazásnál és PWA-nál ez a teher kisebb: egy frissítés a szerveren azonnal minden felhasználóhoz eljut, áruházi jóváhagyás nélkül. A böngészők változásait azonban itt is követni kell. Bármelyik utat választod, az ajánlatban külön tételként szerepeljen az üzemeltetés és a karbantartás — a háttérrendszer, a szerverek és a mentések felügyeletét pedig az IT-üzemeltetés is lefedheti.

Mi mozgatja a ráfordítást?

Konkrét árat csak felmérés után lehet felelősen mondani, de a költséget mozgató tényezők minden mobilprojektnél ugyanazok. Ha ajánlatokat hasonlítasz össze, ezeket nézd meg tételesen:

• Platformok száma: egy webes felület, egy közös kódbázis két platformra, vagy két külön natív alkalmazás — ez a legnagyobb szorzó.
• Offline működés és szinkronizálás: a helyi adattárolás és az ütközéskezelés önálló fejlesztési feladat.
• Háttérrendszer és integrációk: az app ritkán áll meg önmagában. A felhasználókezelés, az adatbázis és a számlázó, CRM vagy ügyviteli rendszer felé vezető kapcsolatok gyakran több munkát jelentenek, mint maguk a képernyők.
• Eszközfunkciók: kamera, helymeghatározás, NFC vagy Bluetooth — mindegyiket több eszközön, valós körülmények között kell tesztelni.
• Áruházi adminisztráció: fejlesztői fiókok, adatvédelmi tájékoztató, áruházi leírások és felülvizsgálati körök.
• Karbantartás: visszatérő tétel, amelyet már az első ajánlatban érdemes látni.

A mobilalkalmazás-fejlesztési munkánk is felméréssel indul: előbb a felhasználókat és a folyamatot értjük meg, és csak utána döntünk a technológiáról.

Döntési táblázat

Mobilra jellemzően React Nativeval dolgozunk, a háttérrendszerhez .NET-et vagy Node.js-t és PostgreSQL-t használunk — de a technológiát a feladathoz választjuk, nem fordítva. Ha a felmérés azt mutatja, hogy egy PWA vagy egy webes alkalmazás is elég, azt javasoljuk, és a döntés indokait írásban is rögzítjük.

Ha az app egy nagyobb rendszer része, az egyedi szoftverfejlesztés oldalunkon a teljes munkamenetet bemutatjuk, a fejlesztőpartner kiválasztásához pedig a Szoftverfejlesztő cég választása: 12 kérdés cikkünk ad támpontot.