React Native vs Native (Swift/Kotlin) 2026-ban: mikor melyiket válaszd

A „native vs cross-platform" vita 2026-ban már nem fekete-fehér. A React Native sokat lépett előre az új architektúrával (Fabric + TurboModules + JSI), a Swift és Kotlin pedig stabil platformok. A döntés ma már nem ideológiai, hanem konkrét trade-off-ok mátrixa: time-to-market, performance-igény, platform-specifikus feature-szükséglet, csapat-skill, hosszú távú TCO.

Ebben a cikkben performance benchmark-okat, developer experience-t, ecosystem-állapotot és 5 konkrét use case-ajánlást nézünk. A számok 2026 Q1-es állapotot tükröznek; a piac gyorsan változik, érdemes a hivatalos benchmark-okat (React Native release notes, WWDC) is utánaolvasni.

Mi változott 2024-2026 között?

A „native vs cross-platform" diskurzus 2018-2020-ban hard fronton állt. 2024-2026-ra mindkét oldal sokat finomított:

React Native — New Architecture (Fabric + TurboModules)

A 2024-es 0.76 release-ben default-tá vált az új architektúra:

• Fabric — új renderer, ami a UI threadon dolgozik (a régi Bridge async-volt). Jelentősen kisebb commit-latency.
• TurboModules — natív module-hívások synchronous-ra váltottak. JSON-serialization eliminálva.
• JSI (JavaScript Interface) — direkt C++ binding a JS engine és a natív kód között.
• Hermes — Facebook JS engine, default RN-en, kisebb memory footprint, gyorsabb startup.

Az új architektúra real-world impact-je: 30-40%-os javulás cold start-on és list rendering-en a régi Bridge-architektúrához képest.

Swift és Kotlin — érettebb tooling

• Swift 6 (2024) — strict concurrency, jobb compile-time error-detection.
• Kotlin Multiplatform Mobile (KMM) — natív iOS + Android közös business logic. Konkurens megoldás a React Native-nek.
• Jetpack Compose Multiplatform — Compose nem csak Android-ra, iOS-re és desktopra is. Még béta, de gyorsan érik.

Az alternatívák

A „native vs RN" mellé felzárkózott:

• Flutter — Google saját cross-platform stack. Dart nyelven, saját renderer (Skia). Performance kiváló, ecosystem kisebb.
• KMM — code-sharing csak az üzleti logikára, UI natív. Több boilerplate, de a UI-kontroll teljes.
• Expo (RN-rétegként) — managed workflow, App Store-deployment 1 paranccsal, OTA-update.

A cikkben most a React Native és native pár-vitára fókuszálunk, mert ez a magyar piacon a legjellemzőbb választás. A Flutter és KMM külön cikket érdemelne.

Performance benchmark-ok — konkrét számok

A 2026-os new architecture (React Native 0.76+) érdemben csökkentette a JS bridge overhead-et. Egy közepes komplexitású app-en (FlashList-tel renderelt 500-elemes lista, képek, részletoldal-navigáció):

Metrika	React Native 0.76+	Native Swift / Kotlin
Cold start (mid-range device)	1.4-2.1s	0.8-1.4s
Cold start (high-end device)	0.9-1.4s	0.5-0.9s
Scroll FPS (60Hz)	58-60	60
Scroll FPS (120Hz)	110-118	118-120
Memory footprint (idle)	70-110 MB	45-80 MB
Memory footprint (active list, 500 item)	140-180 MB	90-130 MB
Bundle size (release)	12-18 MB	5-15 MB
TTI (Time to Interactive)	2.5-3.5s	1.5-2.5s
Animation jank (% frames > 16.6ms)	1-3%	0-1%

A különbség észlelhető, de a felhasználók többsége nem érzi. A cold-start-különbség 0.5-1s, ami high-end eszközön (iPhone 15+, Pixel 8+) nem zavar — alacsonyabb kategórián viszont igen. A 120Hz-es animation-FPS-en a native nyer, de a 60Hz-en gyakorlatilag azonos.

Egy konkrét benchmark — list-rendering

A FlashList (Shopify maintained, RN-re optimalizált) vs SwiftUI's LazyVStack 1000 elemes lista:

Cold render to interactive:
  FlashList (RN 0.76 Hermes):   1850ms
  SwiftUI LazyVStack:           1100ms
  Difference:                    750ms (RN +68%)

Smooth scroll (10s test, 60fps target):
  FlashList:                    99.2% on-target
  SwiftUI:                      99.8% on-target
  Difference: marginal

Memory growth (scrolling 100 → 1000 items):
  FlashList:                    +35 MB
  SwiftUI:                      +18 MB

Ezek mid-range devicen (iPhone 13, Pixel 6) mért számok. High-end deviceen mindkettő szinte az ideális rátához tapad.

Mikor érzi a felhasználó a különbséget?

• Alacsony árú devicen (RAM < 4 GB). Itt a RN-app érezhetően „lustább".
• Real-time animáció / játék. 60fps-en megjelenő particle-effect, gesture-driven animation — itt a RN néha frame-eket dob.
• Hosszú listák (1000+ elem). Memory-footprint különbség érződik.
• Camera / media-processing. A bridge overhead itt drámai (RN Camera vs AVFoundation direkt).

A „mindennapi" use case-ek (lista, detail-view, form, push-receive) — felhasználó NEM érzi a különbséget.

Developer experience részletesen

React Native erősségei

• Hot reload (Fast Refresh) sebesség. Tipikus iter-cycle: kód-mentés → app-frissítés 0.3-0.8s. Native: 3-15s build.
• Web-fejlesztők gyors onboarding-ja. React tudás transferable. Egy senior React-fejlesztő 1-2 hét alatt productive RN-en.
• Egy kódbázis két platformra. Tipikus code-sharing: 60-80% (UI-flow 60-70%, üzleti logika 80-95%).
• Expo EAS Update — OTA bug-fix store submission nélkül. Egy eas update paranccsal a fix 5 perc múlva minden user-en. Native: 24-48 órás Apple/Google review.
• TypeScript native support. Type-safety első naptól.
• Cross-team kollaboráció. Frontend-web és RN-fejlesztők együtt dolgozhatnak ugyanazon a komponens-stílusú gondolkodáson.

Native erősségei

• IDE-tooling érettebb. Xcode és Android Studio profiler, debugger, memory-graph. RN-en egy crash debug 2-3x annyi idő.
• Platform-API-k azonnali elérése, nem kell wait native module-ra. Új iOS-feature (ARKit 8, Vision API frissítések) day-1 elérhetők.
• Hivatalos Apple/Google docs és sample code mindenre. Stack Overflow-on minden problémára van válasz.
• Build-pipeline tisztább (single language, single dependency manager). Nincs Pod + npm + Gradle hármas.
• No "second layer" debugging. Egy RN-bug lehet RN-issue, lehet natív module-issue, lehet JS-issue — három különböző debugging-stack.
• Long-term stability. Apple és Google maintainol mindent, nincs „abandoned library" probléma.

Részletes DX-mátrix

Kritérium	React Native	Native (iOS/Android)
Initial setup	30 perc (Expo)	1-2 óra
Hot reload	< 1s	3-15s
Type safety	TypeScript	Swift / Kotlin
Platform-API access	Day-7 to month-2	Day-1
Debugging tools	Reactotron, Flipper	Xcode, Android Studio
OTA update	Yes (Expo)	No
App size optimization	Limited (Hermes helps)	Excellent
Threading model	JS thread + UI thread	Free-form (Grand Central Dispatch / Coroutines)

Ecosystem és library

A React Native ecosystem-je 2026-ban érett, de nem minden library aktívan karbantartott. A kritikus library-k stabilak:

• react-native-reanimated — ML Kit-szerű animációk, jól karbantartott (Software Mansion).
• react-native-screens — natív navigációs primitív, Software Mansion.
• react-native-mmkv — fast key-value storage, Tencent.
• expo-* — managed workflow modulok, Expo team.
• @shopify/flash-list — fast list renderer.
• react-native-gesture-handler — gesture system.

De a long-tail (kisebb library-k, niche use case-ek) gyakran abandoned. Tipikus: egy 2022-ben publikált library, ami megoldotta a NFC-olvasást — 2026-ra a maintainer eltűnt, az új iOS-verzióra már nem fut.

Native oldalon: Apple és Google mindent maintainol. A 3rd party library-k (Firebase, OneSignal, Stripe) elsőként native-ra adnak ki, RN-re 1-2 hónappal később.

Library-discovery best practices RN-en

Mielőtt függőséget használsz:

1. GitHub stars > 1000 — sokan használják.
2. Last commit < 6 hónap — aktív karbantartás.
3. New Architecture compatible — Fabric / TurboModules-ready.
4. TypeScript types included — out-of-box DX.
5. Issues / PRs aktívak — a maintainer reagál.

Ha egy library ezek közül 2-nél kevesebbet teljesít, inkább írj magad vagy találj alternatívát.

Figyelem: A „régi RN architektúra" library-k (sok 2022 előtti) gyakran törnek a New Architecture-rel. A 2024-es upgrade tipikus: 5-10 könyvtár cseréje vagy frissítése. Tervezd be a projekt-fenntartásba.

Jobs market és csapat-bér — 2026 magyar piac

Pozíció	Havi bér (Ft)	Megjegyzés
Native iOS Swift senior	1.4-2.2M + bonus	Szűkebb kínálat
Native Android Kotlin senior	1.3-2.0M + bonus	Stabil kínálat
React Native senior	1.3-2.0M + bonus	Növekvő kínálat
Flutter senior	1.2-1.8M + bonus	Niche kínálat
Mobile lead (cross-stack)	2.2-3.5M + bonus	Ritka

A React Native fejlesztő jellemzően „full-stack mobile" (mindkét platform), de a deep platform-specifikus tudást (background fetch, share extension, NFC, Bluetooth LE) gyakran native-fejlesztővel kell kiegészíteni.

Recruiting nehézség

• Native iOS Swift: 2-4 hónap egy senior pozíció betöltésére.
• Native Android Kotlin: 1-3 hónap.
• React Native senior: 1-2 hónap (web-fejlesztők átlépnek).

Team-arány best practices

• 2 platform, 6 hónapos projekt: 2 RN-fejlesztő VAGY 1 iOS + 1 Android. Cost-arány ~50% RN javára.
• 1 platform, intenzív feature-szett: native-stack jobb.
• Multi-platform skálázás (3-5 fő team): native-stack könnyebben felépíthető (mindenki egy platformot tud mélyen).

5 use case ajánlás részletesen

Use case 1: B2C app, gyors market-entry, MVP-fókusz

Setup: Egyszerű feature-szett (auth, lista, detail view, push). UX nem requires platform-specifikus interakciókat. Cél: 8-12 hét alatt App Store-on lenni, mind iOS, mind Android.

Ajánlás: React Native Expo managed workflow-val.

Indoklás: Time-to-market 6-10 hét, kétszer olcsóbb mint native két platformra. Az Expo managed workflow (EAS Build, EAS Update, EAS Submit) gyakorlatilag eliminálja a deployment-friction-t.

Stack-recommendation: Expo + React Navigation + Reanimated + TanStack Query + Zustand state-management. ESLint + Prettier + TypeScript strict.

Use case 2: B2C app intenzív media-konzumációval (video, kamera)

Setup: Real-time video streaming, AR-overlay, kamera-effekt. A teljesítmény-érzékenység kritikus. UX-feature-ek tipikusan platform-specifikusak (iOS-en Live Photos, Android-on Camera2 API mélysége).

Ajánlás: Native iOS Swift + Native Android Kotlin.

Indoklás: A React Native + Reanimated jó animáció-szintre, de real-time media processing-re nem éri el a native szintet. Az AVFoundation (iOS) és CameraX (Android) képességeket native-ról teljesen, RN-ről csak részlegesen lehet elérni.

Stack-recommendation: Swift 6 + SwiftUI / UIKit, Kotlin + Jetpack Compose. Plus AVFoundation / CameraX a media-pipeline-ra.

Use case 3: B2B app, ahol a UX szabványos és a backend-integráció a fő munka

Setup: CRM-mobil, raktárkezelő, field service app. A felhasználói flow lineáris, a heavy lifting backend-oldalon. Sok form, lista, REST/GraphQL fetch.

Ajánlás: React Native.

Indoklás: A 70-80% code sharing két platformra optimal cost-arány. Native module szükségtelen. A B2B-felhasználók kevésbé szenzitívek a tökéletes natív UX-re, az „elérhető és gyors" elég.

Stack-recommendation: Expo + React Native Paper / Tamagui + React Query + Tab/Drawer navigation. Auth: Auth0 vagy Cognito.

Use case 4: App, ami in-app purchase + komplex platform-feature-eket használ

Setup: iOS Share Extension, Widget, Live Activity, App Clip. Android App Bundle dynamic delivery, foreground service.

Ajánlás: Native.

Indoklás: Ezek a feature-ek elérhetők RN-en is, de minden új OS-feature 3-6 hónapos delay-jel jön platform-specifikus moduloknak. Ha core-feature, native gyorsabb és rugalmasabb.

Stack-recommendation: Swift + SwiftUI (Widgets, Live Activities), Kotlin + Jetpack Compose. Plus a megfelelő platform-feature-modulok.

Use case 5: Belső / enterprise app korlátozott audience-re

Setup: Készletkezelő 50-100 belső felhasználónak. UX-szabványos, OS-frissítés-ütemezés rugalmas (a userek IT-controlled eszközön).

Ajánlás: React Native vagy akár PWA (ha offline-mode nem kell).

Indoklás: Belső use case-en a tökéletes natív UX nem kritikus. Az updates pace (RN OTA update) viszont nagy érték — bug-fix 1 órán belül minden felhasználón.

Stack-recommendation: Expo + minimal UI library. Plus enterprise authentication (SSO, MS Entra ID).

Összehasonlító döntési mátrix

Kritérium	RN súly	Native súly	Megjegyzés
Time-to-market	+++	+	RN ~2x gyorsabb
Performance (60fps animation)	++	+++	High-end deviceen különbség minimal
Platform-specifikus feature	++	+++	Native-ról bármi elérhető
Csapat-méret optimalizáció	+++	+	RN-csapat fele akkora
Long-term maintenance	++	++	RN-upgrade-ek kihívás, de doable
Total cost (5 év)	++	++	RN olcsóbb build, native olcsóbb maintenance
Recruiting könnyűség	++	+	RN-fejlesztő gyakoribb
OTA bug-fix	+++	+	Expo OTA major advantage
App size	++	+++	Native ~50%-kal kisebb
Battery-impact	++	+++	Native efficiency jobb
Cross-platform UX consistency	+++	+	RN ugyanaz mindenhol

A „++ vagy +++" jelzés szubjektív, de a piac általános állapotát tükrözi 2026-ban.

TCO (Total Cost of Ownership) számítás

Egy 5 éves projekten (4 év aktív fejlesztés + 1 év maintenance):

React Native scenario

Tétel	Cost (Ft)	Megjegyzés
Initial build (3 hó, 2 RN dev)	9-12M	Mid-senior bér
Ongoing fejlesztés (4 év, 1 dev átlag)	60-80M	1.5-2M / hó
RN-upgrade-projekt (5 év alatt 2 major)	4-6M	4-6 hét / upgrade
Total 5 év	73-98M Ft

Native scenario

Tétel	Cost (Ft)	Megjegyzés
Initial build (3 hó, 1 iOS + 1 Android)	12-16M	Mid-senior bér
Ongoing fejlesztés (4 év, 2 dev átlag)	100-140M	Két platform
iOS major upgrade-ek (5 év alatt 5)	2-3M	Általában kisebbek
Total 5 év	114-159M Ft

A native ~1.5-1.6x drágább 5 éves horizonton standard B2B-app esetén. De a kvalitás-különbség gyakran nem kritikus B2B kontextusban.

Premium B2C app (intenzív UX-fókusz) esetén a számítás megfordul: a native-app revenue-impact-je 20-30%-kal lehet magasabb a jobb UX miatt, ami fedi az extra cost-ot.

Migration scenario-k

RN → Native (rare, but happens)

Az „app sikerül, most platform-feature-eket kellene mélyebbre venni" forgatókönyv. Tipikus migration-time: 6-12 hónap, 50-70% kódbázis-rewrite.

Megfontolandó: maradni RN-en + selektíven native module-ok írása. Sokszor jobb mint a teljes migration.

Native → RN (more common)

Az „1 platformot tartunk, és a másikra is akarunk gyorsabban" forgatókönyv. Tipikus: a csapat megtart 1 native developer-t a platform-mélységekre, plus 2 RN-fejlesztő a cross-platform feature-ekre.

Tipp: Ne tervezzen most migration-t. A projekt-induláskor hozott platform-döntés 5-10 éves elköteleződés. Discovery-fázisban gondold át, ne menet közben.

Hivatalos doc-ok és további olvasmányok

• React Native dokumentáció — official guide
• Expo dokumentáció — managed workflow
• Apple Developer Documentation — Swift / iOS
• Android Developers — Kotlin / Android
• React Native Architecture Overview — New Architecture deep dive
• Software Mansion blog — RN-Library maintainer's perspective

Témához kapcsolódó saját cikkeink: App Store & Play Store deployment 2026 — release pipeline. Push értesítések helyes implementálása — RN + native push pattern-ek. Mobil app GDPR compliance — privacy alapok.

Lezárás

A jó hír 2026-ban: mindkét opció érett és skálázható. A rossz: a választás nem mindegy, és a wrong-choice 2-3 hónapnyi rework-be kerülhet.

Cross-platform (React Native) alapértelmezett, ha a use case standard B2B vagy B2C MVP. Native, ha intenzív platform-feature van vagy a performance-igény ≥ 60fps real-time interakcióval.

A platform-választás 1 hét scope a discovery-fázisban: use case-analysis, performance-igény-mérés, csapat-skill-audit, 5 éves TCO-modellezés. Utána a tényleges build 8-16 hét, és onnantól iteratív menet.

Ha mobil app projektet tervezel, kezdjük egy discovery-call-lal — az első hét célja pontosan ez a döntés. A wrong-choice utólag drága, ezért inkább 1 héttel többet tervezzünk a döntésre, mint 3 hónappal többet migration-re.