# 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](https://developer.apple.com/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](https://developer.android.com/compose)), és új Android-alkalmazáshoz a Kotlinnal való indulást javasolja ([Android Developers: Kotlin-first](https://developer.android.com/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](https://docs.flutter.dev/resources/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](https://reactnative.dev/)). 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](https://reactnative.dev/architecture/landing-page)).
- **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](https://kotlinlang.org/docs/multiplatform/kmp-overview.html)). A Kotlin dokumentációja szerint a Compose Multiplatform iOS-en is stabil szintű ([Kotlin: platformok stabilitása](https://kotlinlang.org/docs/multiplatform/supported-platforms.html), 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?](https://learn.microsoft.com/hu-hu/dotnet/maui/what-is-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](https://web.dev/learn/pwa/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](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)). 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](https://developer.apple.com/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](https://docs.flutter.dev/perf/app-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](https://www.mestersegesintelligenciakozpont.hu/hu/szolgaltatasok/weboldal-keszites) 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](https://firebase.google.com/docs/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](https://www.mestersegesintelligenciakozpont.hu/hu/szolgaltatasok/egyedi-szoftverfejlesztes) 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](https://developer.apple.com/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](https://developer.apple.com/app-store/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](https://developer.apple.com/news/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](https://developer.apple.com/programs/enroll/)).
- **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](https://developer.apple.com/help/app-store-connect/manage-compliance-information/manage-european-union-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](https://developer.android.com/google/play/requirements/target-sdk)).
- **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](https://support.google.com/googleplay/android-developer/answer/14151465?hl=hu)).
- **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](https://support.google.com/googleplay/android-developer/answer/13628312?hl=hu)).
- **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](https://support.google.com/googleplay/android-developer/answer/10787469?hl=hu)).
- **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](https://support.google.com/googleplay/android-developer/answer/13327111?hl=hu)).

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](https://reactnative.dev/docs/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](https://docs.flutter.dev/ui/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](https://developer.android.com/guide/topics/ui/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](https://eur-lex.europa.eu/legal-content/HU/TXT/?uri=CELEX:32019L0882)). A webáruházakra vonatkozó részleteket a [Webshop: bérelt rendszer vagy egyedi fejlesztés?](https://www.mestersegesintelligenciakozpont.hu/hu/tudastar/berelt-webshop-vagy-egyedi-fejlesztes) 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](https://developer.apple.com/documentation/foundationmodels)).
- **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](https://developer.android.com/ai/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ó](https://www.mestersegesintelligenciakozpont.hu/hu/szolgaltatasok/ai-integracio) 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](https://www.mestersegesintelligenciakozpont.hu/hu/arazas) 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](https://www.mestersegesintelligenciakozpont.hu/hu/szolgaltatasok/mobilalkalmazas-fejlesztes) 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](https://www.mestersegesintelligenciakozpont.hu/hu/kapcsolat).

## Források

- [Apple: SwiftUI](https://developer.apple.com/swiftui/)
- [Android Developers: Jetpack Compose](https://developer.android.com/compose)
- [Android Developers: Android's Kotlin-first approach](https://developer.android.com/kotlin/first)
- [Flutter: Architectural overview](https://docs.flutter.dev/resources/architectural-overview)
- [Flutter: Measuring your app's size](https://docs.flutter.dev/perf/app-size)
- [Flutter: Accessibility](https://docs.flutter.dev/ui/accessibility)
- [React Native](https://reactnative.dev/)
- [React Native: About the New Architecture](https://reactnative.dev/architecture/landing-page)
- [React Native: Accessibility](https://reactnative.dev/docs/accessibility)
- [Kotlin: Kotlin Multiplatform overview](https://kotlinlang.org/docs/multiplatform/kmp-overview.html)
- [Kotlin: Stability of supported platforms](https://kotlinlang.org/docs/multiplatform/supported-platforms.html)
- [Microsoft Learn: Mi az a .NET MAUI?](https://learn.microsoft.com/hu-hu/dotnet/maui/what-is-maui)
- [web.dev: Progressive Web Apps](https://web.dev/learn/pwa/progressive-web-apps)
- [WebKit: Web Push for Web Apps on iOS and iPadOS](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)
- [Apple: App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)
- [Apple: App privacy details](https://developer.apple.com/app-store/app-privacy-details/)
- [Apple: Upcoming requirements](https://developer.apple.com/news/upcoming-requirements/)
- [Apple: Enrollment](https://developer.apple.com/programs/enroll/)
- [Apple: Digital Services Act trader requirements](https://developer.apple.com/help/app-store-connect/manage-compliance-information/manage-european-union-digital-services-act-trader-requirements/)
- [Android Developers: Target API level requirements for Google Play](https://developer.android.com/google/play/requirements/target-sdk)
- [Play Console Súgó: tesztelési követelmények új személyes fiókoknál](https://support.google.com/googleplay/android-developer/answer/14151465?hl=hu)
- [Play Console Súgó: fejlesztői fiók létrehozásához szükséges adatok](https://support.google.com/googleplay/android-developer/answer/13628312?hl=hu)
- [Play Console Súgó: Adatbiztonság szakasz](https://support.google.com/googleplay/android-developer/answer/10787469?hl=hu)
- [Play Console Súgó: fióktörlési követelmények](https://support.google.com/googleplay/android-developer/answer/13327111?hl=hu)
- [Android Developers: Accessibility](https://developer.android.com/guide/topics/ui/accessibility)
- [EUR-Lex: (EU) 2019/882 irányelv](https://eur-lex.europa.eu/legal-content/HU/TXT/?uri=CELEX:32019L0882)
- [Apple: Foundation Models](https://developer.apple.com/documentation/foundationmodels)
- [Android Developers: Gemini Nano](https://developer.android.com/ai/gemini-nano)
- [Firebase: Cloud Messaging](https://firebase.google.com/docs/cloud-messaging)