React Native Нова Архитектура: Миграция към Fabric и TurboModules през 2026

Обновено: 5 юни 2026 г.

Новата архитектура на React Native е модерният рендеринг и нативен слой, който заменя стария мост (Bridge) с три синхронни компонента: Fabric (нов UI renderer), TurboModules (мързеливо заредени нативни модули) и JSI (JavaScript Interface). От React Native 0.76 насам тя е активирана по подразбиране за всички нови проекти. В това ръководство ще покажа как да мигрирате съществуващо приложение през 2026 г., как да отстраните най-честите проблеми със съвместимостта и как да измерите реалните печалби в производителността. Самият аз изкарах подобна миграция върху продуктово приложение с около 60 екрана и ще споделя какво ме спъна по пътя.

• От React Native 0.76 (октомври 2025) новата архитектура е активирана по подразбиране за всички нови проекти, а 0.78 затвърди стабилността на Fabric и TurboModules в production.
• Мостът все още е наличен в режим Bridgeless = false, но ще бъде премахнат след версия 0.80. Така че миграцията не е по избор за дългосрочно поддържани приложения.
• Включването става с един флаг (newArchEnabled=true в gradle.properties и RCT_NEW_ARCH_ENABLED=1 при pod install), но изисква проверка на всяка библиотека трета страна.
• Очакваните печалби: 15–40% по-бързо стартиране, премахване на JSON серилизацията през моста и истински синхронни нативни извиквания през JSI.
• Expo SDK 53+ автоматично активира новата архитектура за нови проекти и предоставя npx expo-doctor за проверка на съвместимостта на библиотеките.

Какво представлява новата архитектура на React Native?

Накратко, новата архитектура е цялостно преработване на вътрешностите на React Native. Започна още през 2018 г. и финализира с включването си по подразбиране във версия 0.76. Тя заменя асинхронния JSON мост между JavaScript и нативния код с три самостоятелни, но синхронизирани слоя. JSI позволява на JavaScript директно да задържа референции към C++ обекти. TurboModules предоставя статично типизирани, мързеливо заредени нативни модули. А Fabric е новият рендериращ слой, който създава shadow nodes на C++ и комуникира с UI thread без сериализация.

Целта е да отпаднат трите най-големи тесни места на стария мост: задължителна JSON серилизация, асинхронна природа на всички извиквания и пълно зареждане на всички нативни модули при стартиране. На практика потребителите виждат по-бързо стартиране, по-плавни анимации, истинско синхронно четене на layout и възможност за интегриране на тежки C++ библиотеки (например SQLite, FFmpeg, TensorFlow Lite) без overhead. Официалната документация за архитектурата на React Native предлага диаграми, които визуализират потока на данни между трите слоя.

Fabric срещу стария Paper renderer

Старият renderer, известен като Paper, използва Java/Kotlin на Android и Objective-C на iOS, за да изгражда view йерархията. После асинхронно я синхронизира с shadow tree-то в JavaScript. Това води до забележимо изоставане при бързи скрол анимации и невъзможност за синхронно измерване на layout. Fabric пренаписва тази логика изцяло на C++, споделя един и същ код между двете платформи и поддържа concurrent rendering от React 18 нататък.

Характеристика	Paper (стар)	Fabric (нов)
Език на shadow tree	Java / Obj-C	C++ (споделен)
Комуникация с UI thread	Асинхронен мост	JSI, синхронна
Concurrent React (Suspense, transitions)	Частично	Пълна поддръжка
Синхронно measure()	Не	Да
Memory overhead на view	По-висок	~30% по-нисък
Поддръжка от 0.78	Deprecated	По подразбиране

Освен техническите разлики, Fabric улеснява споделянето на компоненти между React Native и React Native for Windows/macOS, защото shadow tree-то живее в C++. Това е причината екипите на Microsoft и Meta да мигрират собствените си приложения. Microsoft Office Mobile и Facebook вече работят изцяло на Fabric от края на 2025 г.

TurboModules и JSI обяснени

TurboModules са еволюцията на нативните модули. В Paper всички нативни модули се регистрират при стартиране, дори ако приложението никога не ги използва. Това директно влияе на времето за първи рендер (TTI). При TurboModules регистрацията е мързелива: модулът се зарежда едва при първото му извикване от JavaScript. Спецификацията се описва на TypeScript или Flow, а Codegen генерира C++ интерфейси, които гарантират типова безопасност между двата свята.

// specs/NativeBatteryModule.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getBatteryLevel(): Promise<number>;
  isCharging(): boolean; // синхронен извик, невъзможен в Paper
}

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

JSI е по-ниско ниво. Той позволява на C++ код директно да създава JavaScript функции и обекти, без преминаване през мост. Това отваря възможности като react-native-mmkv (синхронно четене/писане), react-native-skia (графика на 120 fps) и vision-camera (frame processors в реално време), които просто не са възможни в стария мост. Работната група за новата архитектура в GitHub поддържа актуален списък с подготвени за TurboModules библиотеки.

Предварителни стъпки преди миграцията

Преди да включите флага, направете три неща. Първо, обновете React Native поне до 0.76, а още по-добре до 0.78, защото по-старите версии все още имат частична поддръжка на Bridgeless режим. Второ, прегледайте всяка библиотека от трета страна: пакети без TurboModules спецификация ще работят в режим interop layer, но с измеримо забавяне. Трето, изпълнете npx react-native doctor или (за Expo) npx expo-doctor, за да получите автоматизиран отчет.

# Проверка кои библиотеки поддържат новата архитектура
npx expo-doctor

# Преглед на конкретен пакет
npx react-native config | jq '.dependencies'

Освен библиотеките, прегледайте и собствените си нативни модули. Ако имате custom Java/Kotlin или Objective-C/Swift код, ще трябва да напишете TurboModule спецификация и да изпълните Codegen. За съществуващи приложения, които използват пълното ръководство за Expo SDK 53, повечето от вътрешните модули вече са пренесени.

Активиране на новата архитектура в Android

За голи (bare) React Native проекти отворете android/gradle.properties и сменете стойността:

# android/gradle.properties
newArchEnabled=true
hermesEnabled=true

Hermes е препоръчителният JavaScript engine. Той е оптимизиран за JSI и стартира до 30% по-бързо от JSC. След това почистете build кеша и регенерирайте автогенерираните файлове:

cd android
./gradlew clean
cd ..
npx react-native run-android

Codegen ще се изпълни автоматично по време на компилирането и ще генерира C++ обвивки за всеки TurboModule, описан в package.json чрез полето codegenConfig. Ако виждате грешка "Unknown TurboModule", проверете дали името на спецификацията съвпада с регистрираното име в Java/Kotlin (case-sensitive). Аз самият изгубих половин ден на точно това, защото в TypeScript бях написал 'BatteryModule', а в Kotlin беше "BatteryManager".

Активиране на новата архитектура в iOS

На iOS активирането става чрез environment variable при инсталиране на pods. Изпълнете:

cd ios
bundle install
RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
cd ..
npx react-native run-ios

Резултатът от pod install ще покаже съобщение "Configuring the target with the New Architecture", ако променливата е разпозната. От React Native 0.78 нататък променливата е заменена с конфигурационен ключ в Podfile:

# ios/Podfile
use_react_native!(
  :path => config[:reactNativePath],
  :hermes_enabled => true,
  :fabric_enabled => true,
  :new_arch_enabled => true,
  :app_path => "#{Pod::Config.instance.installation_root}/.."
)

След първия успешен build, проверете в Xcode конзолата за съобщението "Running with the New Architecture". То се извежда при стартиране на bridgeless runtime-а. Ако вместо него виждате "Running with the legacy bridge", обикновено липсва $RCTNewArchEnabled в main.m или AppDelegate.mm.

Експо проекти и новата архитектура

Експо опрости миграцията значително. От SDK 53 нататък новата архитектура е включена по подразбиране за всички нови проекти, създадени с npx create-expo-app. За съществуващи проекти, добавете полето в app.json:

{
  "expo": {
    "newArchEnabled": true,
    "plugins": [
      ["expo-build-properties", {
        "ios": { "newArchEnabled": true },
        "android": { "newArchEnabled": true }
      }]
    ]
  }
}

След това генерирайте нативните директории и стартирайте EAS Build:

npx expo prebuild --clean
eas build --platform all --profile development

За проекти с интензивна навигация, обмислете комбинацията с Expo Router за файлово базирана навигация, която е напълно оптимизирана за Fabric от версия 4.0. За анимации, които използват shared values, Reanimated 4 с CSS анимации и преходи също работи изключително добре с JSI и постига 60+ fps дори при сложни преходи. (Честно казано, миналия месец в мой проект сменихме точно тази комбинация и анимациите спряха да трепкат при бавни Android устройства.)

Чести грешки и как да ги поправите

Грешка: "TurboModuleRegistry.getEnforcing(...): 'XYZ' could not be found"

Тази грешка означава, че спецификацията не е намерена при Codegen. Проверете дали името в TurboModuleRegistry.getEnforcing<Spec>('XYZ') съответства на регистрираното име в нативния пакет (getName() метода на Android, RCT_EXPORT_MODULE на iOS) и дали package.json съдържа codegenConfig.name и codegenConfig.type: "modules".

Грешка: "Invariant Violation: Tried to register two views with the same name"

Възниква, когато един и същ компонент е регистриран и в стария Paper renderer, и в Fabric. Премахнете старата регистрация в ViewManager и оставете само Fabric версията с codegenConfig.type: "components".

Бели екрани на iOS след активиране

Най-честата причина е, че root view-то все още използва RCTRootView вместо RCTAppDelegate. От 0.78 шаблонният AppDelegate.mm вече инициализира bridgeless runtime автоматично, но за стари проекти трябва ръчно да обновите файла. Документацията на working group ръководството за разрешаване на новата архитектура съдържа стъпка по стъпка пример.

Анимации, които "скачат" след миграция

Често се дължи на библиотека, която все още използва стария NativeAnimatedHelper. Обновете react-native-reanimated до 4.x и react-native-gesture-handler до 2.18+. И двете имат пълна Fabric поддръжка.

Как да измерите реалните печалби в производителността

Не разчитайте на впечатления, а измерете преди и след миграцията с конкретни инструменти. За време за стартиране (TTI), използвайте react-native-performance с маркер при първия useEffect на root компонента. За frame rate на анимации, използвайте Perfetto на Android и Instruments > Core Animation на iOS. За JS to Native latency, измервайте кръговите времена с performance.now() около TurboModule извикване.

// Пример: измерване на TurboModule overhead
import { performance } from 'react-native-performance';

const start = performance.now();
const level = await BatteryModule.getBatteryLevel();
const elapsed = performance.now() - start;
console.log(`TurboModule round-trip: ${elapsed.toFixed(2)}ms`);
// Очаквано: <0.5ms на новата архитектура срещу 5-15ms на моста

В реални условия миграцията на средно сложно приложение (50+ екрана, 30+ нативни модула) показва: 18–35% по-бързо студено стартиране, 40–60% намаление на JS-Native latency за често извиквани модули и 25% по-нисък memory footprint при дълги списъци, защото Fabric освобождава view-та по-агресивно. За B2C приложения това директно се превръща в по-висок D1 retention. Meta съобщава за 1.5% подобрение след пълна Fabric миграция на Facebook Mobile.

Често задавани въпроси

Задължителна ли е миграцията към новата архитектура?

Да, за дългосрочно поддържани приложения. Старият мост официално е deprecated от React Native 0.74 и ще бъде премахнат след 0.80 (очаквано в края на 2026 г.). За нови проекти миграцията е по подразбиране от 0.76.

Каква е разликата между Bridgeless и New Architecture?

"New Architecture" е общият термин за Fabric, TurboModules и JSI заедно. "Bridgeless" е runtime режим, който напълно премахва моста и работи само през JSI. От 0.74 нататък Bridgeless е по подразбиране, когато новата архитектура е активирана.

Мога ли да включа само Fabric, без TurboModules?

Не. Двата компонента са свързани и се активират с един и същ флаг. Технически interop слоят позволява стари нативни модули да работят в Fabric среда, но самият Fabric изисква JSI и TurboModule инфраструктурата.

Колко време отнема миграцията на средно по сложност приложение?

За приложение без custom нативни модули и с актуални зависимости, някъде между няколко часа и един ден. За приложения с custom модули или остарели библиотеки обикновено отнема от 1 до 3 седмици, основно за пренаписване на спецификации и тестване на регресии.

Как да върна назад миграцията, ако нещо се обърка?

Просто върнете newArchEnabled=false в gradle.properties и преинсталирайте pods без RCT_NEW_ARCH_ENABLED. Никой код не е окончателно сменен, флагът просто избира коя runtime пътека да се компилира.