Mobilalkalmazás-fejlesztés Miskolcon

01Valóban app kell, vagy elég egy jó webes felület?

Az első kérdés nem az, hogy iOS vagy Android, hanem az, hogy kell-e egyáltalán telepíthető alkalmazás. Egy mobilra optimalizált weboldal vagy webes ügyfélportál letöltés nélkül elérhető, és jellemzően gyorsabban, kisebb ráfordítással elkészül. Köztes megoldás a PWA (progresszív webalkalmazás): a kezdőképernyőre tehető, részben offline is működik, és iOS-en is fogadhat értesítést — cserébe nem jelenik meg az alkalmazásboltokban, és egyes eszközfunkciókhoz korlátozottabban fér hozzá.

Az app ott hoz valódi pluszt, ahol a felhasználó rendszeresen visszatér, és ahol a telefon képességeire kell építeni. A felmérésen mindhárom utat mérlegeljük, és írásban indokoljuk, melyiket javasoljuk — ha a webes út a jobb választás, azt javasoljuk, akkor is, ha az kisebb megrendelés. A döntéshez a tervezett felhasználók szokásait is megnézzük. Ha az alábbiak közül több is igaz, jó eséllyel megéri a telepíthető alkalmazás:

• a felhasználók hetente többször, rendszeresen használnák;
• terepen, gyenge térerő mellett is működnie kell;
• kamera, vonalkód- vagy QR-olvasás, helymeghatározás kell a munkához;
• a push értesítés fontos eszköz a felhasználók visszahozására;
• az áruházi jelenlét a márka hitelességét is erősíti.

02Natív vagy cross-platform: miért React Native?

Natív fejlesztésnél az iOS- és az Android-változat két külön kódbázisból készül, ami két párhuzamos fejlesztést és karbantartást jelent. Cross-platform megközelítésben egyetlen közös kód fut mindkét rendszeren. Mi jellemzően React Native technológiával dolgozunk: a felhasználói felület a platform saját elemeiből épül fel, így az alkalmazás natív élményt ad, a fejlesztés és a karbantartás viszont egy kódbázisra koncentrálódik. Üzleti és ügyfélalkalmazásoknál ez a megközelítés jellemzően jól bevált.

Ennek a gyakorlatban három előnye van: a két platform egy ütemben kap új funkciót, a hibajavítás egyszer történik meg, és a webes felületeinkkel (React, TypeScript) közös tudásra, sőt közös kódrészekre is építhetünk. Ha egy funkció különleges hardverkapcsolatot vagy platformspecifikus megoldást igényel, azt a felmérésben külön jelezzük, és a technológiai döntést írásban indokoljuk, hogy később is visszakövethető legyen. Így az alkalmazás nem egyetlen fejlesztő tudásán múlik.

03Backend, integrációk és offline működés

Egy alkalmazás ritkán áll meg önmagában: a mögötte futó szerveroldal tárolja az adatokat, kezeli a felhasználókat és küldi az értesítéseket. Ezt a részt is mi építjük — jellemzően Node.js vagy .NET alapon, PostgreSQL adatbázissal, Microsoft Azure felhőben —, és REST API-n keresztül kötjük össze a meglévő rendszereivel, legyen az egyedi CRM, vállalati szoftver vagy webshop. Ha kell, az app gépekhez vagy épületautomatizáláshoz is kapcsolódhat — ezt is egy házon belül oldjuk meg.

Terepen dolgozó felhasználóknál az offline működés kulcskérdés: az app a telefonon tárolja a rögzített adatokat, a kapcsolat visszatérésekor szinkronizál, az ütközéseket pedig előre meghatározott szabályok szerint kezeli. A push értesítések az Apple és a Google értesítési szolgáltatásain keresztül érkeznek; hogy ki, mikor és milyen üzenetet kap, azt a felhasználó beállításaival és hozzájárulásával összhangban tervezzük meg. Az értesítések tartalmát és ütemezését adminfelületről is kezelhetővé tehetjük.

04App Store és Google Play: a megjelenés szabályai

Mindkét alkalmazásbolt átnézi a beküldött appokat, és elutasíthatja azokat, amelyek nem felelnek meg az irányelveinek. Gyakori elutasítási ok a hiányos adatvédelmi tájékoztató, a felülvizsgálónak nem működő bejelentkezés, vagy hogy az alkalmazás nem nyújt érdemben többet egy weboldalnál. Ezeket az irányelveket már a tervezéskor figyelembe vesszük, a felülvizsgálatra pedig időt hagyunk az ütemtervben, hogy az indulás ne csússzon. Egy elutasítás nem végzetes: a kifogásolt pontot javítjuk, és újra beküldjük az appot.

Fontos alapelv, hogy a fejlesztői fiókok (Apple Developer Program, Google Play Console) a megrendelő cégének nevére szóljanak — céges regisztrációhoz mindkét áruház D-U-N-S azonosítót kér, ennek beszerzésében is segítünk. Az áruházak az adatkezelési információkat is kötelezően bekérik, és ha az appban fiók hozható létre, annak törlését is az alkalmazáson belül lehetővé kell tenni. A GDPR-követelményeket — adatkezelési tájékoztató, hozzájárulások, az adatok tárolásának helye — ezért már a tervezésnél rögzítjük.

05Mi történik az indulás után?

Egy mobilalkalmazás nem készül el egyszer s mindenkorra. Az Apple és a Google évente új rendszerverziót ad ki, a Google Play pedig rendszeresen megemeli a kötelezően célzott Android API-szintet — aki ezt nem követi, annak az appjához egy idő után nem tölthető fel frissítés. A felhasznált könyvtárakat, a biztonsági javításokat és az áruházi irányelvek változását is folyamatosan követni kell. A karbantartás tehát nem opcionális extra, hanem az app életben tartásának feltétele.

Az átadás dokumentációval és betanítással történik, utána igény szerint mi gondoskodunk a karbantartásról: frissítések, hibafigyelés, áruházi beküldések és továbbfejlesztés a felhasználói visszajelzések alapján. A szerveroldali futtatókörnyezetet és a céges IT-hátteret IT-üzemeltetési szolgáltatásunk keretében ugyanabban a szerződésben is vállaljuk — így egy partner felel azért, hogy az app és a mögötte futó rendszer együtt működjön. A karbantartás tartalmát — mit, milyen gyakran és milyen reakcióidővel — előre, írásban egyeztetjük.