Expo SDK 55 útmutató: Új architektúra 2026

Bevezetés – Miért 2026 a fordulópont a React Native számára?

Nos, 2026-ban a React Native ökoszisztéma végre odaért, ahová már évek óta tartott. Az Expo SDK 55 megjelenésével ugyanis a platform hivatalosan is lezárta a régi architektúra korszakát. És nem, ez nem csak egy újabb verziófrissítés – ez tényleg egy paradigmaváltás. Olyan, ami gyökeresen átalakítja, hogyan fejlesztünk, milyen teljesítményt érünk el, és mennyire fájdalmas (vagy nem) a karbantartás.

Az Expo SDK 55 a React Native 0.83.1 verzióra épül, ami már a React 19.2-t integrálja. Ez az a kombináció, amire régóta vártunk: szinkron natív hívások, párhuzamos renderelés, modern JavaScript funkciók natív szinten. Olyan dolgok, amikről korábban csak álmodoztunk.

Ebben az útmutatóban végigmegyünk az összes lényeges újdonságon, a migrációs lépéseken és a gyakorlati mintákon. Akár egy meglévő projektet frissítesz, akár nulláról indítasz valamit, itt minden benne lesz, amire szükséged lehet.

Az Új Architektúra Alapjai

A régi Bridge problémái

Ha valaha küzdöttél a Bridge lassúságával, tudod miről beszélek. A React Native eredeti architektúrája egy aszinkron, JSON-alapú hídon keresztül kommunikált a JavaScript és a natív oldal között. Minden egyes interakció szerializálást és deszerializálást igényelt. És ez nem csak elméletben volt lassú – gyakorlatban is érezted, főleg ha nagy mennyiségű adattal dolgoztál vagy gyors frissítésekre volt szükség. A komplex animációk? Azok simán akadoztak a Bridge egyszálú jellege miatt.

JSI – JavaScript Interface

Az Új Architektúra alapköve a JSI (JavaScript Interface), ami közvetlenül összeköti a JavaScript motort a natív kóddal. Ez egy vékony C++ réteg, amely lehetővé teszi, hogy a JavaScript kód szinkron módon hívjon natív függvényeket – és itt a lényeg: anélkül, hogy az adatokat JSON formátumba kellene szerializálnia.

Ez drámaian csökkenti a kommunikációs költséget. Plusz lehetővé teszi az igazi referenciaátadást a két világ között (amit korábban csak álmodozhattál meg).

// A régi Bridge működése (koncepcionális):
// JS -> JSON.stringify(adat) -> Bridge -> JSON.parse(adat) -> Natív
// Natív -> JSON.stringify(eredmény) -> Bridge -> JSON.parse(eredmény) -> JS

// Az új JSI működése (koncepcionális):
// JS -> JSI (közvetlen C++ hívás) -> Natív
// Natív -> JSI (közvetlen referencia) -> JS

// Példa: Natív modul közvetlen elérése JSI-n keresztül
import { TurboModuleRegistry } from 'react-native';

// A modul közvetlenül, szinkron módon érhető el
const nativeModule = TurboModuleRegistry.getEnforcing('MyNativeModule');
const result = nativeModule.computeSync(42); // Szinkron hívás!

TurboModules

A TurboModules a JSI-re épülő modulrendszer, ami felváltja a korábbi NativeModules megoldást. Őszintén szólva, ez az egyik kedvenc újításom. A legfontosabb előnyei:

Lusta betöltés (lazy loading): A modulok csak akkor töltődnek be, amikor ténylegesen szükség van rájuk. Nem az alkalmazás indításakor, mint régen.
Szinkron hívások: A natív függvények szinkron módon is hívhatók, nem csak aszinkron callback-eken vagy Promise-okon keresztül.
Típusbiztonság: A Codegen automatikusan generálja a natív interfészeket a TypeScript/Flow típusdefiníciók alapján, csökkentve a futásidejű hibák lehetőségét.
Közvetlen memória-hozzáférés: A JavaScript és a natív kód megosztott memóriaterületen dolgozhat. Ez jelentősen csökkenti az adatmásolás szükségességét (ami korábban rémálom volt nagy adathalmazoknál).

Fabric Renderer

A Fabric a React Native új renderelő motorja, ami az UIManager helyébe lép. C++-ban íródott, és közvetlenül a JSI-n keresztül kommunikál a JavaScript oldallal.

Legfontosabb jellemzői:

Párhuzamos renderelés: A React 19.2 concurrent rendering képességeit teljes mértékben támogatja, lehetővé téve a megszakítható renderelési ciklusokat.
Szinkron elrendezés (layout): A Yoga layout motor közvetlenül elérhető a JavaScript-ből, ami szinkron mérési és elrendezési műveleteket tesz lehetővé.
Többszálú renderelés: A Fabric képes a renderelési munkát több szál között elosztani, javítva a válaszidőt és a folyékonyságot.

Az alábbi szöveges ábra szemlélteti az architektúra különbségét (ezt érdemes elmenteni valahová):

RÉGI ARCHITEKTÚRA:
┌──────────────┐    ┌──────────────────┐    ┌──────────────┐
│  JavaScript  │───>│  Bridge (JSON)   │───>│    Natív     │
│   szál       │<───│  (aszinkron)     │<───│    szál      │
└──────────────┘    └──────────────────┘    └──────────────┘

ÚJ ARCHITEKTÚRA:
┌──────────────┐    ┌──────────────────┐    ┌──────────────┐
│  JavaScript  │───>│   JSI (C++)      │───>│    Natív     │
│   szál       │<───│  (szinkron is)   │<───│    szál      │
└──────────────┘    └──────────────────┘    └──────────────┘
        │                                          │
        │           ┌──────────────┐               │
        └──────────>│   Fabric     │<──────────────┘
                    │  (Renderer)  │
                    └──────────────┘
                           │
                    ┌──────────────┐
                    │ TurboModules │
                    │ (lazy load)  │
                    └──────────────┘

Expo SDK 55 Újdonságai

React Native 0.83.1 és React 19.2 integráció

Az Expo SDK 55 a React Native 0.83.1 verziót tartalmazza, amely a React 19.2-re épül. Ez a kombináció számos forradalmi újítást hoz a mobilfejlesztésbe. A React 19.2 concurrent renderelési képességei teljes mértékben kihasználhatók a React Native kontextusában – beleértve a Suspense, a Transitions és az új hook-ok támogatását is.

A régi architektúra végérvényes eltávolítása

Az SDK 55 történelmi lépést tesz: teljesen eltávolítja a Legacy Architecture támogatását.

Ez azt jelenti, hogy a newArchEnabled konfiguráció már nem létezik – az Új Architektúra az egyetlen és alapértelmezett működési mód. Ennek komoly következményei vannak:

Minden natív modul és könyvtár kötelezően támogatja az Új Architektúrát, különben nem használható az SDK 55-tel.
Nem kell többé két architektúrát párhuzamosan tesztelni és karbantartani (ami eddig elég fájdalmas volt).
A framework mérete csökken, mivel a kompatibilitási réteg eltávolításra került.
A teljesítmény javul az egységes kódbázisnak köszönhetően.

Hermes v1 motor

Az Expo SDK 55 bevezeti a Hermes v1 motort opt-in lehetőségként. A Hermes v1 jelentős fejlődést jelent az elődjéhez képest. Az alábbi területeken kínál előnyöket:

Modern JavaScript támogatás: Teljes ES2024 kompatibilitás, beleértve a Symbol.dispose, Array.fromAsync és egyéb modern funkciókat.
Gyorsabb bytecode generálás: A fordítási idő akár 30%-kal csökkenhet a korábbi verzióhoz képest.
Kisebb memóriahasználat: A továbbfejlesztett garbage collector hatékonyabban kezeli a memóriát, különösen hosszan futó alkalmazásoknál.
Jobb hibakeresés: A Chrome DevTools integrációja kibővült, részletesebb profilozási adatokkal.

A Hermes v1 aktiválásához a következő konfigurációt kell hozzáadni:

// app.json
{
  "expo": {
    "jsEngine": "hermes",
    "experiments": {
      "hermesVersion": "v1"
    },
    "android": {
      "jsEngine": "hermes"
    },
    "ios": {
      "jsEngine": "hermes"
    }
  }
}

Új alapértelmezett sablon

Az Expo SDK 55 egy teljesen megújult projektsablont vezet be. Az új sablon natív lapfüles navigációval (native tabs) érkezik, és a projektstruktúra is átalakult: az alkalmazás forráskódja mostantól a /src/app könyvtárban helyezkedik el az eddigi /app helyett.

Ez tisztább szétválasztást biztosít a forráskód és a konfigurációs állományok között (ami szerintem rég esedékes volt).

# Új projekt létrehozása az SDK 55 alapértelmezett sablonjával
npx create-expo-app@latest myapp

# Az eredményül kapott projektstruktúra:
# myapp/
# ├── src/
# │   └── app/
# │       ├── _layout.tsx       # Gyökér elrendezés natív lapfülekkel
# │       ├── index.tsx         # Főoldal
# │       ├── (tabs)/
# │       │   ├── _layout.tsx   # Lapfüles elrendezés
# │       │   ├── home.tsx
# │       │   └── settings.tsx
# │       └── +not-found.tsx
# ├── assets/
# ├── app.json
# ├── package.json
# └── tsconfig.json

Kisebb OTA frissítések Hermes bytecode diffeléssel

Az SDK 55 az EAS Update szolgáltatásban egy rendkívül hasznos újítást vezet be: a Hermes bytecode differenciális frissítéseket. A korábbi rendszerben az OTA (Over-The-Air) frissítések a teljes JavaScript bundle-t letöltötték. Az új rendszer csak a ténylegesen megváltozott bytecode szegmenseket küldi el.

Ez akár 60-80%-kal kisebb frissítési csomagokat eredményez. Különösen fontos ez a korlátozott sávszélességgel rendelkező felhasználók számára, és jelentősen csökkenti a frissítés alkalmazásához szükséges időt.

expo-brownfield csomag

Az expo-brownfield csomag egy régóta várt újítás, amely lehetővé teszi az Expo és a React Native integrálását meglévő natív alkalmazásokba. A csomag az Expo modulokat natív könyvtárként (AAR Androidon, XCFramework iOS-en) csomagolja, ami leegyszerűsíti a beágyazást. Erről később részletesen is szólunk.

@expo/ui könyvtár fejlesztései

Az @expo/ui könyvtár jelentős előrelépéseket tett az 1.0-s verzió felé. Az SDK 55-ben a könyvtár kibővült platformspecifikus komponensekkel, amelyek natív felületi elemeket használnak – SwiftUI iOS-en, Jetpack Compose Androidon. Az egységes API lehetővé teszi, hogy a fejlesztők egy kódbázisból mindkét platformon natív kinézetű és működésű komponenseket használjanak.

Verzióigazítás

Az Expo csapata az SDK 55-ben bevezette az egységes verziószámozást: mostantól minden hivatalos Expo csomag verziószáma megegyezik az SDK főverzió számával. Ez azt jelenti, hogy az expo-camera, expo-location és az összes többi csomag egyaránt az 55.x.x verziónál tart.

Ez drámaian egyszerűsíti a függőségek kezelését és a kompatibilitás ellenőrzését (ami eddig elég kaotikus tudott lenni).

// package.json – SDK 55 egységes verziószámozás
{
  "dependencies": {
    "expo": "~55.0.0",
    "expo-camera": "~55.0.0",
    "expo-location": "~55.0.0",
    "expo-notifications": "~55.0.0",
    "expo-file-system": "~55.0.0",
    "expo-image": "~55.0.0",
    "expo-router": "~55.0.0",
    "@expo/ui": "~55.0.0"
  }
}

React 19.2 Újítások React Native-ban

Az Activity komponens

A React 19.2 egyik legizgalmasabb újítása az <Activity> komponens. Ez lehetővé teszi a felhasználói felület egyes részeinek elrejtését az unmount nélkül. És ez a funkció különösen hasznos a React Native alkalmazásokban, ahol a képernyők közötti navigáció során a komponensek állapotának megőrzése kritikus fontosságú a felhasználói élmény szempontjából.

Az <Activity> komponens a mode prop segítségével vezérelhető. Amikor a mode értéke "hidden", a komponens és annak teljes alkomponens-fája láthatatlanná válik, de megőrzi belső állapotát, a DOM csomópontjait és az aktív effektjeit. Amikor a mode visszaáll "visible" értékre, a komponens azonnal megjelenik – újrarenderelés nélkül.

import React, { useState, Activity } from 'react';
import { View, Text, Button, TextInput, ScrollView } from 'react-native';

function TabNavigator() {
  const [activeTab, setActiveTab] = useState('home');

  return (
    <View style={{ flex: 1 }}>
      {/* A Home képernyő megőrzi állapotát, amikor nem aktív */}
      <Activity mode={activeTab === 'home' ? 'visible' : 'hidden'}>
        <HomeScreen />
      </Activity>

      {/* A Search képernyő görgetési pozíciója és szövegbevitele megmarad */}
      <Activity mode={activeTab === 'search' ? 'visible' : 'hidden'}>
        <SearchScreen />
      </Activity>

      {/* A Profile képernyő adatai nem töltődnek újra */}
      <Activity mode={activeTab === 'profile' ? 'visible' : 'hidden'}>
        <ProfileScreen />
      </Activity>

      <View style={{ flexDirection: 'row', justifyContent: 'space-around' }}>
        <Button title="Főoldal" onPress={() => setActiveTab('home')} />
        <Button title="Keresés" onPress={() => setActiveTab('search')} />
        <Button title="Profil" onPress={() => setActiveTab('profile')} />
      </View>
    </View>
  );
}

function SearchScreen() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  return (
    <View style={{ flex: 1, padding: 16 }}>
      <TextInput
        value={query}
        onChangeText={setQuery}
        placeholder="Keresés..."
        style={{ borderWidth: 1, padding: 8, borderRadius: 8 }}
      />
      <ScrollView>
        {results.map(item => (
          <Text key={item.id}>{item.title}</Text>
        ))}
      </ScrollView>
    </View>
  );
}

Az <Activity> komponens különösen nagy értéket képvisel az alábbi helyzetekben:

Lapfüles navigáció: A nem aktív lapfülek tartalma elrejthető, miközben az állapot megmarad (görgetési pozíció, űrlap adatok, lekérdezési eredmények).
Előretöltés (prefetching): A háttérben már renderelhető egy képernyő, amelyet a felhasználó valószínűleg meg fog nyitni, így az átváltás azonnal megtörténik.
Modális ablakok mögötti tartalom: A modális ablak mögötti képernyő elrejthető az újrarenderelés nélkül.

A useEffectEvent hook

A useEffectEvent hook egy régóta várt kiegészítés, amely megoldja az effektekben használt eseménykezelők problémáját. A hagyományos megközelítésben, ha egy effekt egy eseménykezelőtől függ, az eseménykezelőt fel kell venni a függőségi listába, ami felesleges újrafutásokat okozhat.

A useEffectEvent lehetővé teszi, hogy az effekten belül egy stabil referencián keresztül olvassuk a legfrissebb értékeket anélkül, hogy azokat függőségként kellene megadnunk.

import { useState, useEffect, useEffectEvent } from 'react';
import { AppState } from 'react-native';

function useAnalytics(screenName: string) {
  const [visitCount, setVisitCount] = useState(0);

  const onAppStateChange = useEffectEvent((nextAppState: string) => {
    if (nextAppState === 'active') {
      console.log(`Képernyő aktív: ${screenName}, látogatás: ${visitCount}`);
      analytics.track('screen_view', {
        screen: screenName,
        visits: visitCount
      });
      setVisitCount(c => c + 1);
    }
  });

  useEffect(() => {
    const subscription = AppState.addEventListener('change', onAppStateChange);
    return () => subscription.remove();
  }, []);

  return visitCount;
}

function ProfileScreen({ userId }: { userId: string }) {
  const visits = useAnalytics('ProfileScreen');

  return (
    <View>
      <Text>Profil – Látogatások száma: {visits}</Text>
    </View>
  );
}

A useEffectEvent hook előnyei a korábbi megoldásokkal szemben:

Megszünteti a felesleges effekt-újrafutásokat, amelyeket a változó függőségek okoztak.
Nem szükséges manuálisan useCallback-et és useRef-et kombinálni a stabil referenciák eléréséhez.
Egyértelműen jelzi a kód szándékát: ez egy esemény, amely az effekthez tartozik, de nem annak függősége.
Típusbiztos és a React fejlesztői eszközök is megfelelően kezelik.

React Native DevTools Fejlesztések

Hálózati forgalom vizsgálata

A React Native 0.83 jelentősen továbbfejlesztett hálózati ellenőrzési (Network Inspection) képességekkel érkezik. A fejlesztői eszközök most már képesek minden HTTP és WebSocket kérést rögzíteni és megjeleníteni, beleértve a kérések és válaszok fejléceit, törzsét, időzítését és állapotkódjait.

Ez korábban csak külső eszközökkel (mint a Flipper vagy a Charles Proxy) volt lehetséges, de mostantól közvetlenül a beépített DevTools-ból elérhető. Végre.

Teljesítményprofilozás

Az új Performance Tracing funkció lehetővé teszi a renderelési ciklusok, a JavaScript végrehajtás és a natív modulhívások részletes időzítési elemzését. A profilozó adatai vizuálisan megjeleníthetők egy idővonal nézetben, amely megmutatja, hol tölti az alkalmazás a legtöbb időt, és hol lehetséges az optimalizálás.

Önálló asztali alkalmazás

Az egyik legjelentősebb változás a React Native DevTools új önálló asztali alkalmazása, amely nem igényel böngészőt a működéshez. Az alkalmazás közvetlenül csatlakozik a futó React Native alkalmazáshoz, és egy dedikált ablakban jeleníti meg az összes fejlesztői eszközt. Ez gyorsabb és megbízhatóbb, mint a korábbi böngészőalapú megoldás, és jobban integrálódik a fejlesztői munkafolyamatba.

# A React Native DevTools önálló alkalmazás indítása
# Az Expo CLI automatikusan elindítja, de manuálisan is meghívható:
npx react-native-devtools

# Vagy az Expo fejlesztői menüjéből (az eszközön rázással elérhető):
# "Open DevTools" -> automatikusan megnyílik az asztali alkalmazás

# Teljesítményprofilozás indítása parancssorból:
npx expo start --dev-client --performance-trace

Intersection Observer API (Canary)

A React Native 0.83 Canary funkcióként bevezeti az Intersection Observer API támogatását. Ez a webes világban régóta ismert API lehetővé teszi, hogy a fejlesztők értesüljenek arról, amikor egy elem belép vagy kilép a látható területről. Ez rendkívül hasznos a lusta betöltés (lazy loading), a végtelen görgetés és az elemek megjelenésén alapuló animációk megvalósításához – anélkül, hogy a onScroll eseményt kellene folyamatosan figyelni.

Migráció az Új Architektúrára

Előkészületek

Mielőtt az SDK 55-re frissítenél, fontos áttekinteni a projekt jelenlegi állapotát és a függőségek kompatibilitását. Az alábbi lépések segítenek a zökkenőmentes átállásban.

1. lépés: Az Expo SDK frissítése

Az Expo CLI beépített frissítési eszközt biztosít, amely automatikusan kezeli a verziófüggőségeket:

# Az Expo SDK frissítése a legújabb verzióra
npx expo install expo@~55.0.0

# Az összes Expo csomag frissítése a kompatibilis verzióra
npx expo install --fix

# A natív konfigurációk újragenerálása (ha szükséges)
npx expo prebuild --clean

# A frissítés ellenőrzése
npx expo-doctor

2. lépés: Könyvtárak kompatibilitásának ellenőrzése

Az Expo Doctor eszköz képes ellenőrizni, hogy az összes használt könyvtár kompatibilis-e az Új Architektúrával:

# Kompatibilitási ellenőrzés futtatása
npx expo-doctor

# Példa kimenet:
# ✓ [email protected] – kompatibilis
# ✓ [email protected] – kompatibilis
# ✓ [email protected] – kompatibilis
# ✗ [email protected] – NEM kompatibilis az Új Architektúrával
#   → Ajánlott alternatíva: [email protected]

Ha egy függőség nem kompatibilis az Új Architektúrával, a következő lehetőségek állnak rendelkezésre:

Frissítés: Ellenőrizd, hogy a könyvtár újabb verziója támogatja-e az Új Architektúrát.
Alternatíva keresése: Keress egy hasonló funkciójú, kompatibilis könyvtárat.
Saját implementáció: Kisebb könyvtárak esetén megfontolandó a funkcionalitás saját megvalósítása TurboModule-ként.
Közösségi hozzájárulás: Nyiss egy issue-t vagy készíts pull request-et a könyvtár repositoryjában az Új Architektúra támogatásának hozzáadásához.

3. lépés: Natív modulok frissítése

Ha az alkalmazás egyedi natív modulokat használ, azokat át kell alakítani TurboModule-okká. A Codegen eszköz segít ebben a folyamatban:

// Új TurboModule specifikáció – src/specs/NativeMyModule.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  // Szinkron metódus – azonnal visszatér
  getDeviceName(): string;

  // Aszinkron metódus – Promise-t ad vissza
  fetchUserData(userId: string): Promise<{
    name: string;
    email: string;
    avatar: string;
  }>;

  // Eseményfigyelő metódusok
  addListener(eventName: string): void;
  removeListeners(count: number): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('MyNativeModule');

4. lépés: Tesztelés és ellenőrzés

A migráció után alapos tesztelést kell végezni. Különös tekintettel a következő területekre:

Natív modulok és könyvtárak helyes működése
Animációk és gesztusok folyamatossága
Memóriahasználat és teljesítmény a Fabric rendererrel
Az OTA frissítések helyes működése
Mindkét platform (iOS és Android) tesztelése

Brownfield Integráció

Az expo-brownfield csomag működése

A „brownfield" kifejezés azokra a projektekre utal, amelyekben egy meglévő natív alkalmazásba (Swift/Kotlin) kell beépíteni React Native funkcionalitást. Az expo-brownfield csomag az SDK 55-ben debütált, és drámaian leegyszerűsíti ezt a folyamatot.

A csomag működési elve a következő:

Natív könyvtár építése: Az Expo projekt React Native részét egy önálló natív könyvtárrá (AAR Androidon, XCFramework iOS-en) csomagolja, amely beágyazható bármely meglévő natív alkalmazásba.
Izolált JavaScript runtime: A React Native saját, izolált JavaScript futtatókörnyezetben fut a natív alkalmazáson belül, nem zavarva a meglévő natív kódot.
Kétirányú kommunikáció: A natív és a React Native kód közötti kommunikáció egy jól definiált, típusbiztos üzenetküldő rendszeren keresztül történik.

A brownfield integráció beállítása

# Az expo-brownfield csomag telepítése a React Native projektbe
npx expo install expo-brownfield

# A natív könyvtár felépítése
# Android (AAR generálása):
npx expo-brownfield build:android --output ./build/android

# iOS (XCFramework generálása):
npx expo-brownfield build:ios --output ./build/ios

# Az eredmény:
# ./build/android/expo-module.aar
# ./build/ios/ExpoModule.xcframework

Kétirányú üzenetküldés

Az expo-brownfield csomag egy eseményalapú üzenetküldő rendszert biztosít a natív és a React Native kód közötti kommunikációhoz:

// React Native oldal – üzenetek küldése és fogadása
import { BrownfieldBridge } from 'expo-brownfield';

// Üzenet küldése a natív oldalnak
BrownfieldBridge.sendMessage('userLoggedIn', {
  userId: '12345',
  timestamp: Date.now(),
});

// Üzenet fogadása a natív oldalról
BrownfieldBridge.addEventListener('nativeEvent', (data) => {
  console.log('Natív esemény érkezett:', data);
});

// React Native nézet bezárása és eredmény visszaküldése
BrownfieldBridge.dismiss({ result: 'success', data: formData });

A brownfield integráció ideális azoknak a csapatoknak, amelyek fokozatosan szeretnék bevezetni a React Native-ot egy meglévő natív alkalmazásba, anélkül, hogy az egész alkalmazást egyszerre kellene újraírniuk.

Teljesítményoptimalizálás az Új Architektúrával

A Fabric hatékony használata

A Fabric renderer az Új Architektúra egyik legfontosabb komponense, és helyes használatával jelentős teljesítménynövekedés érhető el. Az alábbi tippek segítenek a Fabric előnyeinek maximális kihasználásában.

1. Párhuzamos renderelés kihasználása: A React 19.2 useTransition hook-jával jelezhetjük a React-nek, hogy mely állapotfrissítések nem sürgősek, így a Fabric képes a fontos frissítéseket priorizálni.

import { useState, useTransition } from 'react';
import { View, TextInput, FlatList, Text, ActivityIndicator } from 'react-native';

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('');
  const [filteredItems, setFilteredItems] = useState(items);
  const [isPending, startTransition] = useTransition();

  const handleSearch = (text: string) => {
    setQuery(text);

    startTransition(() => {
      const filtered = items.filter(item =>
        item.title.toLowerCase().includes(text.toLowerCase()) ||
        item.description.toLowerCase().includes(text.toLowerCase())
      );
      setFilteredItems(filtered);
    });
  };

  return (
    <View style={{ flex: 1 }}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Keresés az elemek között..."
        style={{ padding: 12, borderWidth: 1, margin: 8, borderRadius: 8 }}
      />
      {isPending && <ActivityIndicator style={{ margin: 8 }} />}
      <FlatList
        data={filteredItems}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={{ padding: 16, borderBottomWidth: 1 }}>
            <Text style={{ fontSize: 16, fontWeight: 'bold' }}>{item.title}</Text>
            <Text style={{ color: '#666' }}>{item.description}</Text>
          </View>
        )}
      />
    </View>
  );
}

2. Virtualizált listák optimalizálása: A Fabric rendererrel a FlatList és a SectionList komponensek teljesítménye jelentősen javul, mivel a Yoga layout motor szinkron módon érhető el. Ennek ellenére továbbra is fontos a következő optimalizálási technikák alkalmazása:

Használj getItemLayout prop-ot, ha az elemek mérete ismert, elkerülve a dinamikus méréseket.
Alkalmazd a windowSize és maxToRenderPerBatch prop-okat a renderelési ablak finomhangolásához.
A React.memo használatával kerüld el a listalemek felesleges újrarenderelését.

TurboModules lusta betöltése

A TurboModules rendszer egyik legnagyobb előnye a lusta betöltés támogatása. A régi NativeModules rendszerben minden natív modul az alkalmazás indításakor betöltődött, ami lassította a cold start időt. A TurboModules-szal a modulok csak akkor inicializálódnak, amikor először használatba vesszük őket (ami érthető okokból sokkal jobb).

Az optimális teljesítmény érdekében érdemes a következő stratégiát alkalmazni:

Kritikus modulok: Azok a modulok, amelyek az alkalmazás indításakor azonnal szükségesek (például navigáció, állapotkezelés), a gyökér komponensben importálandók.
Késleltetett modulok: Azok a modulok, amelyek csak bizonyos képernyőkön vagy funkciókban szükségesek (például kamera, helymeghatározás), csak az adott képernyő vagy funkció aktiválásakor importálandók.
Háttér modulok: Azok a modulok, amelyek nem felhasználói interakcióhoz kötöttek (például analitika, háttér-szinkronizáció), az alkalmazás idle állapotában tölthetők be.

Hermes v1 teljesítményelőnyei

A Hermes v1 motor számos belső optimalizálást tartalmaz, amelyek közvetlenül javítják az alkalmazás teljesítményét:

Bytecode precompiláció: A JavaScript kód bytecode-dá fordítása a build folyamat során történik, nem futásidőben, ami akár 50%-kal gyorsabb alkalmazásindulást eredményezhet.
Továbbfejlesztett Garbage Collector: A Hermes v1 új, generációs szemétgyűjtő algoritmust használ, amely csökkenti a GC-szüneteket és egyenletesebb teljesítményt biztosít.
Inline caching: A tulajdonság-hozzáférések gyorsítása révén a gyakran használt objektumok kezelése hatékonyabb.
Kisebb memóriafoglalás: Az optimalizált adatszerkezeteknek köszönhetően a Hermes v1 akár 20-30%-kal kevesebb memóriát használ azonos feladatok elvégzéséhez.

Teljesítménymérés az új DevTools-szal

Az SDK 55-ben elérhető új teljesítménymérő eszközökkel pontosan nyomon követhető, hol található szűk keresztmetszet az alkalmazásban. Az alábbi módszerek ajánlottak a rendszeres teljesítményauditáláshoz:

import { PerformanceObserver, performance } from 'react-native/performance';

// Egyéni teljesítményjelölők használata
function MeasuredComponent() {
  useEffect(() => {
    performance.mark('component-render-start');

    return () => {
      performance.mark('component-render-end');
      performance.measure(
        'MeasuredComponent render',
        'component-render-start',
        'component-render-end'
      );
    };
  }, []);

  return <View>{/* Komponens tartalma */}</View>;
}

// Teljesítményfigyelő beállítása az alkalmazás gyökerében
const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  entries.forEach(entry => {
    if (entry.duration > 16) { // 60 FPS = ~16ms per frame
      console.warn(
        `Lassú művelet: ${entry.name} – ${entry.duration.toFixed(2)}ms`
      );
    }
  });
});

observer.observe({ entryTypes: ['measure'] });

A React Native DevTools Performance Tracing funkciójával vizuálisan is megjeleníthető az alkalmazás teljesítményprofilja, amely megmutatja a JavaScript szál, a natív szál és a UI szál tevékenységét egy egységes idővonal nézetben. Ez lehetővé teszi, hogy azonosítsd a szűk keresztmetszeteket és célzottan optimalizáld az alkalmazás legkritikusabb részeit.

Összefoglalás és Jövőkép

A változások jelentősége

Az Expo SDK 55 és a React Native 0.83 megjelenése valódi mérföldkő a mobilfejlesztés történetében. A régi Bridge-alapú architektúra végleges eltávolítása lezárja a React Native egyik legvitatottabb korszakát, és megnyitja az utat a valóban natív szintű teljesítmény előtt.

Az új architektúra nem csupán technikai javulást hoz, hanem a fejlesztői élményt is alapjaiban változtatja meg.

Foglaljuk össze a legfontosabb tanulságokat:

Az Új Architektúra immár nem választható: Az SDK 55-tel a JSI, a TurboModules és a Fabric az egyetlen támogatott működési mód. Ez egyszerűsíti a fejlesztést, de megköveteli, hogy minden függőség kompatibilis legyen.
A React 19.2 funkciók valódi értéket teremtenek: Az <Activity> komponens és a useEffectEvent hook nem csupán elméleti újítások – gyakorlati problémákat oldanak meg, amelyekkel minden React Native fejlesztő szembesül.
A Hermes v1 érzékelhető teljesítményjavulást hoz: A gyorsabb indulási idő, a kisebb memóriahasználat és a modern JavaScript támogatás mind hozzájárulnak a jobb felhasználói élményhez.
A brownfield integráció megnyitja a kaput a nagyvállalati adoptáció előtt: Az expo-brownfield csomag lehetővé teszi, hogy a meglévő natív alkalmazások fokozatosan integrálják a React Native-ot, anélkül, hogy teljes újraírásra lenne szükség.
Az egységes verziószámozás egyszerűsíti a karbantartást: Az SDK-val azonos verziószámú csomagok áttekinthetőbbé teszik a függőségek kezelését.

Amit 2026 második felében várhatunk

Az Expo csapata már dolgozik a következő nagy mérföldköveken:

@expo/ui 1.0 megjelenése (2026 közepén): Az @expo/ui könyvtár eléri az 1.0-s verziót, amely stabil, platformnál natív felületi komponenseket kínál egységes API-n keresztül. A SwiftUI és a Jetpack Compose alapú komponensek teljes körű testreszabhatósággal fognak rendelkezni.
Server Components a React Native-ban: A React Server Components (RSC) teljes körű támogatása a React Native-ban lehetővé teszi majd a szerver oldali renderelést mobilalkalmazásokban, ami gyorsabb adatbetöltést és kisebb bundle-méretet eredményez.
Expo Modules API továbbfejlesztése: Az Expo Modules API további egyszerűsítéseket kap, amelyek még könnyebbé teszik a natív modulok létrehozását Swift és Kotlin nyelven.
Hermes v1 alapértelmezetté válása: A Hermes v1 motor várhatóan 2026 második felében válik az alapértelmezett JavaScript motorvá, felváltva a jelenlegi stabil Hermes verziót.
Továbbfejlesztett EAS szolgáltatások: Az EAS Build és az EAS Update szolgáltatások további optimalizálásokat kapnak, beleértve a gyorsabb build időket és az intelligensebb OTA frissítési stratégiákat.

Ajánlások a fejlesztők számára

A 2026-os React Native ökoszisztéma érettebb és stabilabb, mint valaha. Az alábbi ajánlásokat fogalmazom meg:

Új projektek esetén: Használd az Expo SDK 55 alapértelmezett sablonját, és azonnal építkezz az Új Architektúrára. Aktiváld a Hermes v1 motort, és használd ki a React 19.2 új funkcióit, különösen az <Activity> komponenst a navigációs állapot megőrzéséhez.
Meglévő projektek esetén: Tervezd meg a migrációt az SDK 55-re, kezdve a függőségek kompatibilitásának ellenőrzésével. Fokozatosan vezesd be az Új Architektúra specifikus funkciókat, és használd a teljesítménymérő eszközöket a javulás nyomon követéséhez.
Nagyvállalati környezetben: Értékeld ki az expo-brownfield csomag lehetőségeit a meglévő natív alkalmazások fokozatos React Native integrációjához. Ez a megközelítés minimalizálja a kockázatot és lehetővé teszi az inkrementális adoptációt.
Könyvtár-szerzők számára: Ha natív könyvtárat tartasz fenn, győződj meg arról, hogy az teljesen kompatibilis az Új Architektúrával. Az Expo Modules API használata ajánlott, mivel ez automatikusan biztosítja a kompatibilitást és egyszerűsíti a karbantartást.

A React Native 2026-ban erősebb pozícióban van, mint valaha. Az Új Architektúra teljes bevezetése, a React 19.2 integrációja és az Expo ökoszisztéma érettsége együttesen egy olyan platformot eredményeznek, amely teljesítményben megközelíti a natív fejlesztést, miközben megőrzi a cross-platform fejlesztés minden előnyét. Ez a kombináció teszi 2026-ot a React Native igazi fordulópontjává.