Miért kavarodik össze annyi mindenki fejében az app fogalma?
Írd be a keresőbe, hogy “mi az app”, és tucatnyi cikket kapsz, amelyek három sorban letudják a témát: “az app az application rövidítése”.
Kész.
Vége.
Ez technikailag igaz, de gyakorlatilag használhatatlan.
Nem derül ki belőle, hogy miben más egy mobilalkalmazás és egy mobilbarát weboldal, hogy miért kér a zseblámpa-app hozzáférést a névjegyzékedhez, vagy hogy a saját appötleted valóban appot igényel-e egyáltalán.
Ez a cikk két rétegben halad.
Az első felében a teljes alapokat tisztázzuk: mi az app, mi a különbség az alkalmazás, a program és a weboldal között, milyen típusok léteznek, és hogyan töltsd le őket biztonságosan.
A második felében üzleti nézőpontra váltunk.
Ha van egy appötleted, végigvezetünk azon, hogy mikor éri meg egyáltalán fejleszteni, hogyan zajlik egy MVP folyamat, és mennyi idő meg pénz kell hozzá.
A cikk végére nemcsak azt fogod tudni, hogy mi az app, hanem azt is, hogy neked kell-e egyáltalán.
Mi az app egyszerűen elmagyarázva?
Az app egy program, amit egy konkrét feladat elvégzésére terveztek.
Nem többre, nem kevesebbre.
Amikor megnyitod a banki appot, egyetlen dolgot akarsz: pénzt utalni vagy megnézni az egyenleged. Amikor a Spotify-t nyitod meg, zenét hallgatnál.
Ez a fókuszáltság az app lényege, és ez különbözteti meg egy általános célú szoftvertől.
Az app, az alkalmazás és a program ugyanaz?
Az “app” az angol application szó rövidítése, ami magyarul alkalmazást jelent. Tehát az app és az alkalmazás pontosan ugyanaz, csak az egyik rövidebb és köznyelvibb.
A “program” viszont szélesebb kategória.
Minden app program, de nem minden program app.
Gondolj rá így: a “jármű” egy általános fogalom.
Beletartozik a vonat, a targonca és a versenyautó is.
Az app olyan, mint egy konkrét autótípus, amit egy adott célra építettek: a kisteherautót cipekedésre, a családi kombit hosszú utakra.
Egy operációs rendszer (Windows, Android, iOS) is szoftver, de nem app.
Egy nyomtatóillesztő program sem app.
Ezek a háttérben működnek, nincs saját ikonjuk, nem azért nyitod meg őket, hogy valamit elvégezz velük.
A gyakorlatban a szoftveralkalmazás kifejezés a formálisabb változat, ezt látod szerződésekben és szakmai dokumentumokban. Az “app” a hétköznapi szó, ami a 2008-as App Store indulásával robbant be a köztudatba.
Van még egy fontos alkategória: az asztali alkalmazás.
Ez a számítógépre telepített program, mint a Word, a Photoshop vagy a Steam. Ugyanaz a logika, csak nagyobb kijelzőre és egérrel-billentyűzettel való használatra tervezve.
App vagy weboldal: hol a határ?
A legegyszerűbb választóvíz: hogyan érsz hozzá?
Egy weboldalhoz kell böngésző és egy URL.
Beírod a címet, betölt a tartalom, és amint elveszted az internetkapcsolatot, gyakorlatilag semmi nem működik.
A weboldal a szerveren él, te csak megnézed.
Egy apphoz ikon kell a főképernyőn, előtte pedig telepítés.
Az app kódja és adatainak egy része fizikailag ott van a készülékeden.
Ezért képes olyanokra, amikre egy sima weboldal nem.
Példa: a Google Térkép appban letöltheted Budapest teljes térképét, és aztán a metrón, jel nélkül is navigálhatsz.
A böngészőben megnyitott térkép ezt nem tudja megtenni.
Az app közvetlenül eléri a telefon hardverét is: kamerát, GPS-t, gyorsulásmérőt, ujjlenyomat-olvasót, NFC-chipet. Tud push értesítést küldeni, akkor is, amikor éppen nem használod.
Ez a legnagyobb üzleti előnye: emlékeztetheti a felhasználót magára.
És itt jön a csavar.
A határ az utóbbi években elmosódott.
Egy modern webalkalmazás ma már képes offline működni, értesítést küldeni és a főképernyőre kirakható ikonként viselkedni. Ezt hívják progresszív webalkalmazásnak (PWA).
Ilyenkor a felhasználó azt hiszi, appot használ, valójában egy okos weboldal fut a háttérben.
Ez a különbség nem akadémikus kérdés.
Ha vállalkozóként dönteni kell, több millió forint múlik rajta.
Appok típusai és mi van a felszín alatt
Az összes app, amit valaha megnyitottál, négy nagy technológiai kategória valamelyikébe tartozik.
Kívülről nem látszik a különbség.
Költségben, sebességben és fejlesztési időben viszont óriási.
Natív, cross-platform, hibrid és webapp
Íme a négy megközelítés, és hogy mikor melyik a logikus választás:
- Natív alkalmazás. Egy adott platformra, annak saját nyelvén készül: iOS-re Swift nyelven, Androidra Kotlinban. Ez adja a legjobb teljesítményt és a legmélyebb hardveres hozzáférést, viszont két platformhoz két külön kódbázist és gyakorlatilag két fejlesztőcsapatot igényel. Akkor éri meg, ha a teljesítmény maximuma a lényeg: 3D-játékok, videószerkesztők, hardverközeli mérőalkalmazások.
- Cross-platform fejlesztés. Egyetlen kódbázisból készül el az iOS és az Android verzió is, jellemzően Flutter vagy React Native keretrendszerrel. A modern cross-platform appok natívra fordulnak, tehát nem lassabbak és nem “gyengébbek”, csak egyszer kell megírni őket. A legtöbb üzleti app, marketplace, foglalási rendszer és belső céges eszköz ide tartozik, mert 40 és 50 százalék közötti költség- és időmegtakarítást ad a kettős natív fejlesztéshez képest.
- Hibrid app. Alapvetően weboldal, amit egy natív “burokba” csomagolnak, hogy telepíthető legyen és bekerülhessen az appáruházba. Cordova és Ionic tipikus képviselői. Gyors és olcsó megoldás egyszerű tartalmi appokra, de animációknál és összetett gesztusoknál érezhetően akadozik, és a felhasználók ezt észreveszik.
- Progresszív webalkalmazás (PWA). Böngészőben fut, de főképernyőre kitehető, offline is működik, és képes értesítést küldeni. Nincs áruházi jóváhagyás, nincs 15 vagy 30 százalékos platformjutalék, és a frissítés azonnal mindenkinél megjelenik. Hátránya, hogy nem található meg a Google Play és az App Store keresőjében, és az iOS-en néhány funkció mind a mai napig korlátozott.
Egy konkrét példa a cross-platform előnyről: egy Flutter-alapú edzéskövető app egyetlen kódbázisból fut Androidon és iPhone-on, ugyanazzal a felülettel, ugyanazokkal az animációkkal. Ha holnap változtatni kell egy gombon, egy helyen módosítod, és mindkét platformon megjelenik.
Natív úton ugyanez két külön munka, két külön tesztelés, két külön hibalista.
Felület, backend és adatbázis: hogyan kapcsolódnak?
Egy app olyan, mint egy étterem.
Amit vendégként látsz, az csak a történet egyharmada.
- Felhasználói felület (frontend). Ez az étterem vendégtere: az asztalok, a menü, a pincér. Minden, amit látsz és megérintesz az appban. Itt dől el, hogy a felhasználó három másodperc után kilép-e, vagy megérti, mit kell tennie. Ezért van külön szakma a UX és UI tervezés mögött.
- Backend. Ez a konyha. A felhasználó soha nem látja, mégis itt történik a munka java: itt fut a logika, amikor bejelentkezel, itt számol az árat a rendszer, itt dől el, hogy jogosult vagy-e megnyitni egy fizetős tartalmat.
- Adatbázis. Ez a raktár és a hűtőkamra. Itt tárolódnak a felhasználói fiókok, a rendelések, az üzenetek, a fotók. Ha az adatbázis megsérül, minden más hiába működik tökéletesen.
- API. Ez a felszolgáló és a rendelési blokk. Az API a szabályozott átjáró a vendégtér és a konyha között: a felület kérést küld (“mutasd a rendeléseimet”), a backend válaszol, mindig ugyanabban a formátumban. Ez tartja rendben az egészet.
És van egy réteg, amiről a felhasználók szinte soha nem beszélnek, mégis ezen bukik el a legtöbb app:
- Autentikáció. A bejelentkezés, jelszó-visszaállítás, kétfaktoros hitelesítés. Látszólag apró funkció, valójában az app biztonsági alapja.
- Szinkronizálás. Ha telefonon írsz egy jegyzetet, és az öt másodperc múlva megjelenik a laptopodon, az egy komoly technikai megoldás eredménye, nem magától értetődő dolog.
- Push értesítések. Ehhez szerveroldali infrastruktúra kell, ami tudja, kinek mikor mit küldjön. Ez az egyik legerősebb visszahívó eszköz, és egyben a leggyorsabb módja annak, hogy a felhasználó törölje az appot, ha túlzásba viszed.
- Alkalmazásfrissítés. Az app nem kész projekt, hanem élő szolgáltatás. Az iOS és az Android évente ad ki nagy verziót, és ami tavaly működött, ma hibát dobhat.
Biztonságos appok: letöltés, engedélyek és offline működés
Évente több ezer kártékony appot távolítanak el a nagy áruházakból.
Nem azért, mert a szűrés nem működik, hanem mert a próbálkozók száma óriási.
A jó hír: néhány egyszerű szokással a rizikó nagy részét kiszűrheted.
Fejlesztő és értékelések ellenőrzése letöltés előtt
Harminc másodperc ellenőrzés, és a legtöbb átverést elkerülöd:
- Csak hivatalos appáruházból telepíts. Androidon a Google Play, iPhone-on az App Store. Az internetről letöltött APK-fájlok a fertőzések fő forrásai, még akkor is, ha a weboldal profinak tűnik.
- Nézd meg a fejlesztő nevét. Kattints rá. Ha egy “banki” appot egy háromnapos, egyetlen appot kiadó fejlesztő tett közzé, azonnal lépj vissza. A valódi cégeknek portfóliójuk van, működő weboldaluk és felismerhető nevük.
- A letöltésszám többet mond, mint a csillagok. Egy 50 letöltéses app 5,0-es átlaga semmit nem jelent. Egy 10 millió letöltéses app 4,3-a viszont valódi információ.
- Olvasd el a szöveges véleményeket, ne csak a pontszámot. Az egycsillagos értékeléseknél derül ki, hogy az app váratlanul fizetőssé vált, kifagy, vagy reklámokkal van tele. Ha tíz vélemény szinte azonos szavakkal dicséri, az gyanús: vásárolt értékelés.
- Ellenőrizd a legutóbbi frissítés dátumát. Ha két éve nem nyúltak hozzá, ott már senki nem javít biztonsági hibát. Az elhanyagolt alkalmazás-életciklus önmagában is kockázat.
- Fusd át az adatvédelmi összefoglalót. Mind az App Store, mind a Google Play kötelezően megjelenít egy adatkezelési kártyát. Ha egy jegyzetelő app “hirdetési célú helyadatot” gyűjt, tudod, hol keresi a pénzét.
Mit jelentenek az appengedélyek valójában?
Az appengedélyek döntik el, hogy egy app mihez férhet hozzá a telefonon. Az alapszabály egyszerű: az engedélynek logikai kapcsolatban kell lennie az app funkciójával.
- Helyadat. Térkép-, futás- vagy időjárás-appnál teljesen indokolt. Zseblámpa- vagy számológép-appnál nincs rá magyarázat. Androidon és iOS-en is választhatod a “csak app használata közben” opciót, ami szinte mindig elég.
- Kamera. Indokolt QR-olvasónál, videóhívásnál, dokumentumszkennernél. Egy hírolvasó appnak semmi keresnivalója a kamerádnál.
- Mikrofon. Hangüzenetnél és hangfelismerésnél szükséges. Ha egy játék kéri, gondold végig, miért.
- Kontaktlista. Ez a legérzékenyebb, mert nem csak a saját adataidat adod át, hanem az összes ismerősödét is. Csak akkor engedélyezd, ha az app fő funkciója az ismerősök megtalálása.
- Fájlok és fotók. Modern rendszereken megadhatod, hogy csak kiválasztott képekhez férhessen hozzá az app, ne az egész galériához. Használd ezt.
- Értesítések. Nem biztonsági, hanem életminőségi kérdés. Kapcsold ki mindennél, ami nem sürgős, és az appok azonnal kevesebbet zaklatnak.
A megtagadott engedélyeket bármikor visszaadhatod a beállításokban.
Ha egy app kifagy nélküle, akkor tényleg kellett neki.
Ha simán működik tovább, akkor nem.
Minden apphoz kell internet?
Nem.
Ez az egyik legelterjedtebb félreértés az appokról.
Három csoport létezik.
A teljesen offline működésre képes appok mindent a készüléken végeznek: jegyzetelők, számológépek, egyszerűbb fotószerkesztők, offline szótárak. Ezek repülőn, alagútban és nyaraláson roaming nélkül is működnek.
A részben offline appok az igazán érdekesek.
Egy zenelejátszó a letöltött számokat lejátssza jel nélkül, de az új albumokat csak online találja meg. Egy térkép-app előre letöltött területen navigál, de forgalmi adatot nem kap.
A harmadik csoport internet nélkül használhatatlan: banki appok, közösségi média, videóstreaming, azonnali üzenetküldés. Itt az adat mindig a szerveren van, az app csak megjeleníti.
Vállalkozói szempontból ez tervezési döntés.
Ha az appot terepen, raktárban vagy pincében fogják használni, az offline működést az első naptól be kell építeni.
Utólag hozzátenni drága és fájdalmas.
Az ötlettől a kész appig: üzleti nézőpont
A legdrágább app az, amit senki nem használ.
És a leggyakoribb ok nem a rossz kód, hanem az, hogy eleve nem kellett volna appot fejleszteni.
Mikor éri meg saját appot fejleszteni?
Négy konkrét jel mutat arra, hogy valóban appra van szükséged.
Az első a push értesítés.
Ha az üzleti modelled azon áll, hogy visszahívod a felhasználót (edzésemlékeztető, licitfigyelés, szállítási státusz), akkor kell app. Weboldalról ezt nem lehet megbízhatóan megtenni, különösen iPhone-on.
A második az offline elérés.
Ha a felhasználó olyan helyen dolgozik, ahol nincs stabil hálózat, weboldal nem opció.
A harmadik a hardveres integráció.
Kamerával történő szkennelés, folyamatos GPS-követés, Bluetooth-eszközök, ujjlenyomatos beléptetés, NFC-fizetés.
Ezekhez natív vagy cross-platform app kell.
A negyedik az áruházi jelenlét mint hitelesség.
B2C területen sok felhasználó ma azt ellenőrzi, hogy egy szolgáltatás megtalálható-e az App Store-ban.
A jelenlét önmagában bizalmi jel.
Ha viszont csak információt kell megjelenítened (szolgáltatások, árlista, blog, kapcsolatfelvétel), akkor egy jól megépített mobilbarát weboldal vagy PWA jobb választás. Gyorsabb, olcsóbb, keresőből azonnal elérhető, és nem kell letöltésre bírnod senkit.
Egy appot le kell tölteni. Egy weboldalt csak meg kell nyitni. Ez a legdrágább különbség a kettő között, és nem forintban mérik.
Ötlettől az élesindulásig: az MVP folyamata
Az MVP (minimum viable product) a lehető legkisebb működő verzió, ami megoldja a fő problémát.
Nem félkész app, hanem szűk, de teljes.
A folyamat jellemzően így épül fel: probléma pontos meghatározása, wireframe és prototípus, MVP-fejlesztés, tesztelés valós felhasználókkal, áruházi publikálás, majd karbantartás és folyamatos alkalmazásfrissítés.
A publikálás nem a projekt vége, hanem a kezdete.
Az App Store átvizsgálása jellemzően egy-három napot vesz igénybe, és elutasítás esetén javítani és újra beküldeni kell.
A monetizáció négy fő modellre bontható.
Az egyszeri vásárlás egy összegért adja az appot, kiszámítható, de nem hoz ismétlődő bevételt. Az előfizetés havi vagy éves díjat kér, ez a legstabilabb modell, de folyamatos értékadást igényel.
A freemium ingyenes alapfunkciókat ad, és fizetős csomagban nyitja meg a haladó részt. Az alkalmazáson belüli vásárlás pedig konkrét elemeket árul az appon belül: extra tartalmat, kreditet, reklámmentességet.
Az áruházak ezekből 15 vagy 30 százalékos jutalékot vonnak le, amivel az árazásnál számolni kell.
Gyakorlati példaként érdemes megnézni, hogyan működik ez a CompletApp esetében. A fejlesztés Flutter alapon, cross-platform fejlesztéssel zajlik, tehát egyetlen kódbázisból készül el az Android és az iOS verzió is, natív minőségben.
Az MVP-folyamat jellemzően négy hetes, fix áras és fix scope-ú. Ez azt jelenti, hogy a projekt indulásakor tudod a végösszeget és a szállítási dátumot, nem óradíjas nyitott számlát kapsz.
Két további elem érdemel figyelmet.
Az első mérföldkő után walk-away garancia van, tehát ha a látott irány nem megfelelő, kiléphetsz. A teljes kifizetés után pedig a kódtulajdon átkerül hozzád, így nem ragadsz be egyetlen szolgáltatóhoz.
Az app csak egy eszköz, ami problémát old meg
Az app nem az ikon a képernyőn.
Az ikon csak a bejárat.
Mögötte ott van a felhasználói felület, amit valaki megtervezett, a backend, ami a döntéseket hozza, az adatbázis, ami emlékszik, és a folyamatos karbantartás, ami életben tartja.
Ezek nélkül csak egy szép kép van a telefonon.
A döntés pedig egyszerűbb, mint gondolnád.
Ha csak tartalmat mutatnál be, weboldal elég.
Ha egyedi funkcióra, offline elérésre, hardveres integrációra vagy áruházi jelenlétre van szükséged, akkor app kell.
És a legjobb következő lépés nem a fejlesztő keresése, nem is a technológia kiválasztása. Egyetlen mondatban megfogalmazni, milyen konkrét problémát oldasz meg, kinek, és miért fájna neki, ha nem létezne a megoldás.
Ha ez a mondat megvan, a kód már csak részletkérdés.
