Natív vagy cross-platform mobilalkalmazás?

A Mesterséges Intelligencia Központ Kft. budapesti szoftverfejlesztő cég szerint natív app akkor kell, ha az alkalmazás mélyen használja a készüléket; ha a két platformon ugyanaz a funkció, egy közös kódbázis egyszerűbben fenntartható.

Lényeg: A döntés a funkciókon múlik, nem a divaton: mennyire mélyen kell az appnak a készülékhez nyúlnia, mekkora a teljesítményigénye, és ki fogja évekig karbantartani. Ha az áruházi jelenlét és a mély készülék-hozzáférés nem fontos, egy webes alkalmazás (PWA) is elég lehet. Bármelyik utat választja, a háttérrendszer, az áruházi szabályok és a rendszeres operációsrendszer-frissítések a munka jelentős részét adják.

Mit jelent a natív, a cross-platform és a webes alkalmazás?

Egy mobilalkalmazás háromféleképpen készülhet: platformonként külön, a platform saját eszközeivel; egy közös kódbázisból, amely mindkét platformra lefordul; vagy webes technológiával, böngészőben futva. Mindhárom út működő alkalmazást ad; a különbség a hozzáférésben, a karbantartásban és abban van, kinek a szabályai szerint frissül az app.

Natív alkalmazás

Natív alkalmazásnál az iOS- és az Android-változat külön készül, a platform saját nyelvén és felületi eszközeivel. iOS-en ez ma jellemzően a Swift nyelv és a SwiftUI: az Apple szerint a SwiftUI deklaratív szintaxissal, a Swift nyelvre építve teszi lehetővé a felület megépítését az Apple összes platformján (Apple: SwiftUI). Androidon a Kotlin és a Jetpack Compose: a Google a Jetpack Compose-t az Android ajánlott, modern eszközkészletének nevezi a natív felület építéséhez (Android Developers: Jetpack Compose), és új Android-alkalmazáshoz a Kotlinnal való indulást javasolja (Android Developers: Kotlin-first). A natív út előnye, hogy a platform minden új lehetősége az első naptól közvetlenül elérhető; a hátránya, hogy két kódbázist kell fejleszteni és karbantartani.

Cross-platform keretrendszerek

A cross-platform keretrendszerekkel egy közös kódbázisból készül az iOS- és az Android-alkalmazás. Négy gyakori megközelítés:

Flutter: Dart nyelvű keretrendszer. A dokumentáció szerint a Flutter minden felületi elemet saját maga valósít meg ahelyett, hogy a rendszer elemeit használná, és a rajzoláshoz az Impeller nevű motort használja; a platform saját kódját úgynevezett platformcsatornán keresztül lehet meghívni (Flutter: Architectural overview).
React Native: React és JavaScript alapú; a projekt megfogalmazása szerint JavaScriptben íródik, de natív kóddal jelenik meg, mert az alapelemei a platform natív felületi építőköveire képeződnek le (React Native). A 0.76-os verziótól az úgynevezett új architektúra alapértelmezett, amely az aszinkron hidat a JavaScript Interface-szel (JSI) váltja fel (React Native: New Architecture).
Kotlin Multiplatform: a JetBrains nyílt forrású technológiája, amellyel a kód megosztható Android, iOS, asztali, webes és szerveroldali célok között. Megosztható csak az üzleti logika, natív felülettel, vagy a Compose Multiplatformmal a felület is (Kotlin: Kotlin Multiplatform). A Kotlin dokumentációja szerint a Compose Multiplatform iOS-en is stabil szintű (Kotlin: platformok stabilitása, ellenőrizve: 2026. október 17.).
.NET MAUI: a Microsoft keretrendszere C# és XAML nyelven, amellyel Androidra, iOS-re, macOS-re és Windowsra lehet alkalmazást fejleszteni egyetlen közös kódbázisból; a Xamarin.Forms továbbfejlesztése. Az iOS- és macOS-alkalmazások fordításához Mac szükséges (Microsoft Learn: Mi az a .NET MAUI?).

Progresszív webalkalmazás (PWA)

A PWA böngészőben futó webalkalmazás, amely telepíthető a kezdőképernyőre, és fokozatosan bővülő funkciókkal (progressive enhancement) megbízhatóbb élményt ad. A web.dev összefoglalója szerint a platformalkalmazások a képességekben, a webalkalmazások az elérésben a legerősebbek: egyetlen kódbázis bárkit, bármilyen eszközön elér (web.dev: Progressive Web Apps). iOS-en és iPadOS-en a 16.4-es verzió óta a kezdőképernyőre tett webalkalmazás is kérhet engedélyt push-értesítésre (WebKit: Web Push for Web Apps). Egy fontos korlát: az App Store irányelveinek 4.2-es pontja szerint az alkalmazásnak többet kell nyújtania egy újracsomagolt weboldalnál, így egy weboldalt pusztán appba csomagolva nem érdemes az áruházba vinni (Apple: App Store Review Guidelines).

Összehasonlítás egy táblázatban

Szempont	Natív (Swift, Kotlin)	Cross-platform (Flutter, React Native, KMP, .NET MAUI)	PWA
Teljesítmény	a platform eszközeivel közvetlenül optimalizálható	a számításigényes részek natív kódba szervezhetők	a böngésző és a webes technológia szabja meg
Készülék-hozzáférés	minden platformfunkció, az első naptól	a keretrendszeren vagy bővítményen át; új funkció később vagy kiegészítő natív kóddal	a böngésző által támogatott webes felületekre korlátozódik
Megjelenés és érzet	pontosan a platform saját elemei	Flutternél saját rajzolású elemek, React Native-nél natív elemek	weboldalszerű, a böngészőtől függ
Kódmegosztás	nincs, két külön kódbázis	a logika és többnyire a felület is közös	egy kódbázis minden eszközre
Csapat	iOS- és Android-szakértelem külön	egy csapat, de a natív rétegekhez is kell tudás	webfejlesztői csapat
Karbantartás	két kódbázis követi a rendszeres platformváltozásokat	egy kódbázis, plusz a keretrendszer saját frissítései	nincs áruházi kiadás, a böngészők változását kell követni
Alkalmazásméret	a rendszer saját könyvtáraira épül	a keretrendszer motorja is az alkalmazásba kerül	nincs telepítőcsomag, a böngésző gyorsítótáraz
Áruházi jelenlét	igen	igen	nem szükséges; az áruházba csomagolva a 4.2-es pont korlátja érvényes

A Flutter dokumentációja ki is mondja, hogy a Flutter-alkalmazás csomagja önálló, a futáshoz szükséges összes kódot és erőforrást tartalmazza, ezért a mérete szempont lehet (Flutter: Measuring your app's size). A gyakorlatban a különbség ritkán dönt, de érdemes tudni róla, ha a célközönség régebbi készülékeken vagy gyenge kapcsolattal használja az appot.

Mikor melyik illik?

Natív, ha

az alkalmazás mélyen használja a készüléket: kamera, szenzorok, Bluetooth, háttérben futó feladatok;
nagy a teljesítményigénye, például valós idejű kép- vagy hangfeldolgozás, összetett animáció;
a platform legújabb lehetőségeit azonnal ki kell használni;
csak az egyik platformra kell alkalmazás, vagy a két változat lényegesen eltér.

Cross-platform, ha

a két platformon ugyanaz a funkció, és fontos, hogy a változások egyszerre jelenjenek meg;
az alkalmazás jellemzően űrlapokból, listákból, adatmegjelenítésből és értesítésekből áll (a legtöbb üzleti app ilyen);
egy csapat tartja karban az alkalmazást hosszú távon;
a cég már használja a keretrendszer nyelvét, például webes React-tudással a React Native, .NET-háttérrel a .NET MAUI felé.

PWA vagy webalkalmazás, ha

a felhasználók nem az áruházban keresik az alkalmazást, hanem linkről vagy a honlapról érkeznek;
nincs szükség mély készülék-hozzáférésre;
az alkalmazásnak asztali gépen és telefonon ugyanúgy kell működnie;
a gyors, áruházi felülvizsgálat nélküli frissítés fontosabb, mint a platformfunkciók.

A határok itt sem élesek. Kotlin Multiplatformmal például az üzleti logika közös lehet, a felület pedig natív marad; Flutterben és React Native-ben pedig egy-egy kritikus rész natív kódban is megírható. A saját honlapunk játéka webalkalmazásként működik: telepítés nélkül fut a böngészőben, asztali gépen és telefonon egyformán. A webes útról a Weboldal- és webalkalmazás-fejlesztés oldalon írunk.

A háttérrendszer és az adminfelület

Egy mobilalkalmazás ritkán áll meg önmagában. Amint felhasználói fiókja, megosztott adata vagy értesítése van, szerver kell mögé: ott élnek a fiókok, az adatok és a jogosultságok, és onnan indulnak az értesítések. A push-értesítéseket jellemzően egy erre szolgáló szolgáltatáson keresztül küldi a háttérrendszer; a Firebase Cloud Messaging például platformfüggetlen üzenetküldő megoldás, amelyben egy megbízható szerverkörnyezet állítja össze és küldi az üzeneteket Apple-, Android- és webes alkalmazásoknak (Firebase: Cloud Messaging).

Az adminfelület a háttérrendszer kezelőpultja: böngészőből szerkeszthető a tartalom, kezelhetők a felhasználók és a beállítások, hogy a napi változásokhoz ne kelljen fejlesztő. Ide kötjük be a meglévő céges rendszereket is, például egy ügyfélkezelőt, egy raktárnyilvántartást vagy egy számlázót, hogy az alkalmazás ugyanazokkal az adatokkal dolgozzon, mint a cég többi része. Ha még nincs ilyen rendszer, egyedi szoftverként azt is megépítjük. A natív vagy cross-platform döntés a háttérrendszert nem érinti: ugyanaz a szerver szolgálhat ki egy natív és egy Flutterrel készült alkalmazást is.

Áruházi közzététel: mire figyeljünk 2026 októberében?

Az áruházi szabályok gyakran változnak, ezért az alábbiakat dátummal közöljük (ellenőrizve: 2026. október 17.).

App Store (Apple)

Felülvizsgálati irányelvek: az App Store Review Guidelines legutóbb 2026. október 16-án frissült. A 2.1-es pont szerint felülvizsgálatra kész, teljes változatot kell beküldeni; ha az appban bejelentkezés van, demófiókot kell adni, és a háttérrendszernek a felülvizsgálat alatt is működnie kell. Az 5.1.1-es pont szerint minden alkalmazásnak hivatkoznia kell az adatvédelmi tájékoztatójára, és ha az app lehetővé teszi a fiók létrehozását, a fiók törlését is az alkalmazáson belül kell felkínálnia (Apple: App Store Review Guidelines).
Adatvédelmi adatlap: az App Store Connectben meg kell adni az alkalmazás adatkezelési gyakorlatát, a beépített külső komponensekét (például analitikai SDK-két) is; ez új alkalmazás és frissítés beküldéséhez is szükséges (Apple: App privacy details).
Fejlesztőeszköz-követelmény: 2026. április 28. óta az App Store Connectbe feltöltött alkalmazásokat az Xcode 26-os vagy újabb verziójával, az iOS 26 SDK-val kell fordítani, és 2026. szeptember 9. óta az iOS- és iPadOS-alkalmazásoknak legalább az iOS 13-at kell célozniuk (Apple: Upcoming requirements).
Céges fiók: szervezetként való regisztrációhoz a cégnek jogi személynek kell lennie, és D-U-N-S-számmal kell rendelkeznie, a regisztrálónak pedig jogosultnak kell lennie a cég nevében kötelezettséget vállalni (Apple: Enrollment).
Kereskedői státusz az EU-ban: az Apple kéri, hogy a fejlesztő nyilatkozzon, kereskedőnek minősül-e az uniós jog szerint; a kereskedők elérhetőségei az EU-ban megjelennek az alkalmazás áruházi oldalán (Apple: Digital Services Act trader requirements).

Google Play

Cél-API-szint: 2026. augusztus 31. óta az új alkalmazásoknak és a frissítéseknek telefonon legalább az Android 16-ot (API-szint 36) kell célozniuk; a meglévő alkalmazásoknak legalább az Android 15-öt (API-szint 35) kell célozniuk ahhoz, hogy az újabb Android-verziójú készülékeken az új felhasználók számára is elérhetők maradjanak. A Play Console-ban kért hosszabbítással a határidő 2026. november 1. (Android Developers: Target API level).
Tesztelés személyes fióknál: a 2023. november 13. után létrehozott személyes fejlesztői fiókoknál az éles megjelenés előtt zárt tesztet kell futtatni legalább 12 tesztelővel, akik legalább 14 napja folyamatosan részt vesznek benne (Play Console Súgó: tesztelési követelmények).
Szervezeti fiók: szervezeti fejlesztői fiókot D-U-N-S-szám nélkül nem lehet létrehozni (Play Console Súgó: fiók létrehozása).
Adatbiztonsági űrlap: minden Google Playen közzétett alkalmazáshoz ki kell tölteni, akkor is, ha az app nem gyűjt felhasználói adatot (Play Console Súgó: Adatbiztonság).
Fióktörlés: ha az alkalmazásban fiók hozható létre, a fiók és a kapcsolódó adatok törlését az alkalmazáson belül és egy webes hivatkozáson keresztül is kérhetővé kell tenni (Play Console Súgó: fióktörlési követelmények).

Ezek a szabályok a technológiától függetlenül érvényesek: egy Flutterrel vagy React Native-vel készült alkalmazásnak ugyanazokat a cél-API- és SDK-követelményeket kell teljesítenie, mint egy natívnak; a keretrendszer frissítésének követnie kell őket. Azt javasoljuk, hogy a fejlesztői fiók a megrendelő cégéé legyen: így az alkalmazás az Ön cégének neve alatt jelenik meg, és az áruházi adatlap is a cégé marad.

Akadálymentesség

Mindkét platform beépített képernyőolvasóval működik (iOS-en a VoiceOverrel, Androidon a TalkBackkel), és felületet ad ahhoz, hogy az alkalmazások együttműködjenek ezekkel a segítő technológiákkal (React Native: Accessibility). A Flutter dokumentációja például azt javasolja, hogy a képernyőolvasó minden vezérlőelemet érthetően írjon le, a szöveg és a háttér közötti kontrasztarány legalább 4,5:1 legyen, és minden megérinthető elem legalább 48×48 képpont méretű legyen (Flutter: Accessibility). Az Android dokumentációja a Material Design irányelveit, az Accessibility Scanner eszközt és automatikus ellenőrzéseket ajánl a hibák felderítésére (Android Developers: Accessibility).

Ez nem csak jó gyakorlat: az (EU) 2019/882 irányelv szerint a tagállamoknak 2025. június 28-tól kell alkalmazniuk a fogyasztóknak nyújtott e-kereskedelmi szolgáltatásokra vonatkozó akadálymentességi követelményeket, a mobilalkalmazásokon keresztül nyújtott szolgáltatásokra is (a magyar szabályok az irányelv átültetésén alapulnak); a szolgáltatást nyújtó mikrovállalkozásokat mentesíteni kell (EUR-Lex: (EU) 2019/882). A webáruházakra vonatkozó részleteket a Webshop: bérelt rendszer vagy egyedi fejlesztés? cikk tárgyalja.

Mesterséges intelligencia: a készüléken vagy a felhőben?

Egy mobilalkalmazásban az AI-funkció két helyen futhat: magán a telefonon, vagy egy felhőben futó nagy nyelvi modellnél, a háttérrendszeren keresztül.

A készüléken (Apple): az Apple Foundation Models keretrendszere az iOS 26-tól kezdve hozzáférést ad az Apple Intelligence-hez tervezett, a készüléken és a Private Cloud Compute-on futó modellekhez; szöveggenerálásra, strukturált kimenetre és saját eszközök meghívására is használható, de csak az Apple Intelligence-et támogató készülékeken (Apple: Foundation Models).
A készüléken (Android): a Gemini Nano az Android AICore rendszerszolgáltatásában fut, és az ML Kit GenAI felületein keresztül érhető el, például összefoglalásra, szövegjavításra, átfogalmazásra és képleírásra. A Google szerint hálózat nélkül is működik, és az érzékeny adat a készüléken marad, de a modellnek a tokenkorlát és a készülék hardvere szab határt (Android Developers: Gemini Nano).
A felhőben: az OpenAI (ChatGPT), az Anthropic (Claude) és a Google (Gemini) nagy nyelvi modelljei összetettebb feladatokra: asszisztens a cég saját anyagaiból, dokumentum- és képfeldolgozás, összefoglalás. Az AI-szolgáltatás hozzáférési kulcsa a háttérrendszeren marad, nem a telefonon: így az alkalmazásból nem olvasható ki, és a használat a szerveren szabályozható.

A készüléken futó modell az adatvédelem és az offline működés miatt vonzó, de nem minden felhasználó készülékén érhető el, ezért jellemzően felhős tartalékkal együtt érdemes tervezni. A modellek bekötéséről az AI-integráció oldal szól.

Mitől függ a fenntartás?

Egy mobilalkalmazás az átadás után sem kész: a környezete folyamatosan változik. A fenntartási munkát főként ezek határozzák meg:

Az operációs rendszerek és az áruházak követelményei: az Apple újabb Xcode- és SDK-verziót ír elő a feltöltésekhez, a Google Play pedig újabb cél-API-szintet. A fenti dátumok mutatják, hogy ezek rendszeresen emelkednek.
Az áruházi irányelvek változásai: új adatvédelmi nyilatkozatok, fióktörlési vagy tesztelési szabályok.
A keretrendszer frissítései: cross-platform appnál a Flutter, a React Native vagy a .NET MAUI nagyobb verzióváltása a saját kódban és a használt bővítményekben is munkát jelenthet.
A külső komponensek: fizetési, térképes, analitikai SDK-k, amelyeknek szintén vannak frissítési követelményeik.
A háttérrendszer és az integrációk: a kapcsolódó céges rendszerek és AI-szolgáltatások felületének változásai.
A kódbázisok száma: két natív alkalmazás két helyen igényel módosítást.

Gyakori hibák

A technológiát a csapat megszokása dönti el, nem az alkalmazás funkciói.
A háttérrendszerrel és az adminfelülettel nem számolnak, csak a képernyőkkel.
Egy weboldalt pusztán appba csomagolnak, és az áruház elutasítja.
A fejlesztői fiók a fejlesztő cég nevén van, és az áruházi adatlap később nem vihető tovább.
A fióktörlést, az adatvédelmi adatlapot vagy a demófiókot a beküldés napján pótolják.
Az átadás utáni frissítésekre nincs gazda, és az app egy szabályváltozás után kikerül az új felhasználók elől.

Gyakori kérdések

Natív vagy Flutter/React Native?

Ha az alkalmazás mélyen használja a készüléket (kamera, szenzorok, háttérfolyamatok), vagy nagy a teljesítményigénye, a natív fejlesztés a biztosabb út. Ha a két platformon ugyanaz a funkció, egy Flutterrel vagy React Native-vel készült, közös kódbázisú alkalmazás egyszerűbben karbantartható. Kotlin Multiplatformmal köztes út is járható: közös üzleti logika, natív felület. Az első egyeztetésen a konkrét funkciók alapján javaslunk.

Mikor elég egy webes alkalmazás (PWA)?

Ha a felhasználók linkről vagy a honlapról érkeznek, nincs szükség mély készülék-hozzáférésre, és fontos, hogy asztali gépen és telefonon is ugyanúgy működjön. A kezdőképernyőre telepíthető, és iOS-en is küldhet push-értesítést, de áruházi jelenlétet nem ad, és a készülékfunkciók köre a böngészőn múlik.

Kell hozzá háttérrendszer?

Szinte mindig: amint az alkalmazásnak felhasználói fiókja, megosztott adata vagy értesítése van, szerver kell mögé. Kivétel az az alkalmazás, amely csak a készüléken tárol adatot. A háttérrendszert és az adminfelületet is megépítjük, és bekötjük a meglévő céges rendszerekbe.

Ki teszi fel az alkalmazást az áruházakba?

A közzétételt mi intézzük: elkészítjük az áruházi adatlap anyagait, az adatvédelmi nyilatkozatokat, beküldjük az alkalmazást, és végigkísérjük a felülvizsgálatot. Azt javasoljuk, hogy a fejlesztői fiók az Ön cégéé legyen; szervezeti fiókhoz mindkét áruház D-U-N-S-számot kér, ezért érdemes időben beszerezni.

Mitől függ a fenntartás költsége?

Attól, hány kódbázist kell karbantartani, milyen gyakran változnak az operációs rendszerek és az áruházi követelmények, hány külső komponenst és integrációt használ az app, és mennyi továbbfejlesztés várható. A fejlesztés árát a funkcionális méretből adjuk; a módszert az Árazás oldal írja le.

Hogyan segítünk?

iOS- és Android-alkalmazást fejlesztünk: megépítjük mögé a háttérrendszert és az adminfelületet, bekötjük a mesterséges intelligenciát, és végigvisszük az áruházi megjelenésig. A natív vagy cross-platform döntést a funkciók alapján, közösen hozzuk meg. A szolgáltatás részleteit a Mobilalkalmazás-fejlesztés oldal írja le.

A fejlesztés funkcionális méretét COSMIC funkciópontban mérjük (ISO/IEC 19761), ebből készül az ajánlat és az ütemterv. Az első egyeztetés díjmentes, kérésre titoktartási szerződést (NDA) kötünk, és átadás után az üzemeltetést és a karbantartást is vállaljuk. A forráskódról és a felhasználási jogokról a szerződés rendelkezik. Írja le néhány mondatban az ötletét, és vegye fel velünk a kapcsolatot.