React Native

Що рухається, коли JavaScript зайнятий, — шістнадцять речей, які робить екран

Екран на React Native — це дві програми, що розмовляють між собою. Ваш React-код виконується в одному потоці JavaScript. В’ю, яких торкається користувач, належать UIUIUser Interface — те, що бачить користувачУсе, що користувач бачить і чим керує: екрани, кнопки, поля, стани. UI відповідає за те, ЯК виглядає взаємодія; чи має вона сенс узагалі — це вже питання UX, і ці два поняття плутають постійно.Усі терміни-потоку платформи, його ще називають головним. Здебільшого цієї різниці не видно. Вона стає видимою тієї миті, коли потік JavaScript зайнятий — розбирає велику відповідь, перерендерює довгий список, рахує щось важке, — бо все, що потребує JavaScript, чекає, а все, що не потребує, рухається далі. Тож корисне питання до будь-якої частини екрана — не «чи швидкий React Native?». Воно таке: «який потік це виконує і що побачить користувач, якщо цей потік буде зайнятий пів секунди?». Ось шістнадцять речей, які робить екран. Наступні розділи посилаються на рядки за номерами.

Два потоки й перехід: нова архітектура

<View> у React Native — це не div і не малюнок. Він стає справжнім UIView на iOS і справжнім android.view.View на Android, які створює й малює платформа. Тому скрол має правильну фізику, клавіатура поводиться коректно, а читачі екрана працюють без додаткових зусиль: нічого з цього не переписано, операційна система робить свою роботу. З тієї ж причини редизайн операційної системи доходить до застосунку на React Native компонент за компонентом, щойно застосунок перезібрано, — сторінка про Flutter показує цю різницю на прикладі iOS 26.

Зміна потрапляє на екран у три кроки. Перший — рендер: React виконує ваші компоненти в потоці JavaScript і будує дерево елементів, а рендерер перетворює його на shadow tree — копію структури екрана, що живе в C++. Другий — розкладка: Yoga, рушій flexbox на C++, рахує розмір і позицію кожного вузла. У типовому випадку обидва кроки відбуваються в потоці JavaScript; термінове оновлення, як-от відповідь на дотик, натомість можуть відрендерити синхронно в UI-потоці. Третій — монтування: UI-потік порівнює нове дерево з тим, що на екрані, і застосовує лише різницю: створити цю в’ю, оновити ту, прибрати третю. UI-потік ніколи не виконує ваш React-код. Він лише застосовує результат.

Початковий задум з’єднував дві сторони «мостом»: кожне повідомлення серіалізували в JSONJSONJavaScript Object Notation — текстовий формат данихТекстовий формат для передавання даних: пари «ключ — значення», списки, числа й рядки. Він народився в JavaScript, але сьогодні його читає будь-яка мова — і саме тому ним відповідає більшість API, а не чимось потужнішим.Усі терміни, ставили в чергу й доставляли пакетами, асинхронно. Це працювало й породило фірмовий збій фреймворку: зайнятий потік JavaScript надсилав вказівки пізно, і кадри втрачалися. Нова архітектура замінює міст трьома частинами. JSI, JavaScript Interface, дозволяє JavaScript тримати пряме посилання на об’єкт C++ і викликати його синхронно, без жодного JSON посередині. Fabric — це описаний вище рендерер, збудований на JSI. TurboModules — нативні модулі, які завантажуються під час першого використання, а не всі на старті, і чиї типи Codegen генерує з типізованої специфікації, тож розбіжність між сигнатурою в JavaScript і нативною падає ще на збірці.

Рушій JavaScript — Hermes, який Meta зробила саме для React Native. Він компілює JavaScript у байткод під час збірки застосунку, тож телефон не розбирає вихідний код на старті, — це перший захід із рядка 16. Hermes V1, перебудований компілятор і віртуальна машина, став типовим у 0.84; на застосунку Expensify команда React Native виміряла загальний час до інтерактивності на 7,6% коротший на Android і на 2,5% — на iOS. JavaScriptCore, рушій Safari, пішов з ядра в 0.79 і живе далі як пакет спільноти.

Списки, перерендери й зображення: звідки береться «React Native повільний»

Майже кожна скарга «React Native повільний» зводиться до рядків 10, 13 чи 15 — список, зайвий перерендер або забагато роботи в потоці JavaScript — або до рядка 4, зображення, якому ніхто не змінив розмір. Списки — першими, бо вони є майже на кожному екрані. Довгий список через .map() у ScrollView монтує кожен рядок, видимий чи ні. FlatList натомість віртуалізований: він монтує вікно рядків навколо екрана й демонтує решту. Типово він спершу рендерить 10 рядків, потім додає по 10 за пакет кожні 50 мс і тримає вікно заввишки 21 екран — десять угорі, десять унизу й видимий. Коли користувач гортає ривком швидше, ніж JavaScript встигає рендерити нові рядки, список показує порожнечу там, де мали бути рядки. Документація називає це порожніми ділянками (blank areas).

FlashList, список від Shopify, діє інакше: він перевикористовує. Замість монтувати й демонтувати рядки, він тримає приблизно екран клітинок і невеликий запас, а клітинку, що зникла вгорі, віддає елементу, який з’являється внизу. Версія 2, що вийшла 2025 року, працює лише на новій архітектурі й більше не потребує оцінок розміру. Її завантажують близько двох мільйонів разів на тиждень. З 10 вересня 2026 року вона несе ще й власний урок: Shopify йде з React Native і пише, що «веде переговори з кількома компаніями про довгострокове опікунство», — тож бібліотека, від якої ви залежите, тепер має спонсора, за яким треба стежити. Хоч який список, одиниця вартості — рядок. Список не зробить повільний рядок швидким: мемоїзуйте компонент рядка, тримайте його дешевим і давайте стабільний ключ.

Рядок 13 живе за тими самими правилами, що й React у вебі, — про них сторінка React: тримайте стан якомога нижче в дереві, мемоїзуйте те, що отримує незмінні пропси, дайте React Compiler мемоїзувати там, де його ввімкнено. Одне правило — суто мобільне. Навігаційний стек тримає змонтованими екрани під поточним, щоб вони зберігали позицію скролу й стан, — і вони так само перерендерюються щоразу, коли змінюється спільне сховище. freezeOnBlur у React Navigation зупиняє перерендери екранів, яких користувач не бачить; Coinbase 2020 року зробив те саме вручну, а розділ кейсів розповідає, чого їм коштувала відсутність цього.

Рядок 4 — це пам’ять, а не швидкість. Зображення декодують перед показом, і декодоване зображення займає ширина × висота × 4 байти, хоч яким був розмір файлу. Фото на 12 мегапікселів — 4000 на 3000 пікселів — займає в пам’яті 48 МБ, навіть якщо JPEG важив 2 МБ; стрічка з десяти таких — майже пів гігабайта, а на телефоні середнього класу з Android система вбиває застосунок задовго до цього. Просіть у сервера чи CDN той розмір, який справді показуєте, і беріть компонент зображень із дисковим і пам’яттєвим кешем, як-от expo-image.

Expo, нативний код і оновлення «по повітрю»

Expo колись був пісочницею, яку зрештою доводилося покидати. Тепер ні, і власна документація React Native радить починати новий застосунок із фреймворком і називає саме Expo. Він дає сервіс збірки, оновлення «по повітрю», великий набір підтримуваних нативних модулів, роутер на основі файлів і — те, що вирішує, як проєкт старітиме, — config plugins. Config plugin описує зміну нативних проєктів кодом: додати цей дозвіл, зареєструвати той SDKSDKSoftware Development Kit — готовий набір для платформиЗібраний набір бібліотек, інструментів і прикладів для роботи з чужою платформою. Відмінність від API в тому, що API лише описує правила, а SDK дає код, який уже вміє за цими правилами говорити.Усі терміни. Теки ios та android тоді генеруються, а не правляться руками, тож оновлення їх перегенерує й накладе ваші зміни знову. Проєкт, чиї нативні теки правили руками, перетворює кожне оновлення на злиття з власними правками; саме такі проєкти через два роки досі сидять на три версії позаду.

Expo випускає SDK під кожну версію React Native, яку бере, — після того як перевірив бібліотеки разом. SDK 57, що вийшов 30 червня 2026 року, працює на React Native 0.86. SDK 58 у бета-версії з 15 вересня 2026 року на реліз-кандидаті 0.88 і стане стабільним невдовзі після 0.88. Для команди це і є практичний зміст «оновлюватися по одній версії»: по одному SDK, а npx expo install --fix вирівнює під нього кожну бібліотеку Expo.

Оновлення «по повітрю» та їхня точна межа

Оскільки логіка застосунку — це JavaScript, ви можете надіслати новий бандл уже встановленим застосункам без рев’ю магазину — це оновлення «по повітрю» (OTA). Виправлення доходить до користувачів за хвилини, а не за дні. Обидва магазини це дозволяють, у записаних межах. Угода Apple Developer Program License Agreement, розділ 3.3.1(B), каже: інтерпретований код можна завантажувати лише тоді, коли він не змінює основного призначення застосунку, не обходить підпис, пісочницю та інші механізми безпеки й не створює магазину для інших застосунків. Google Play забороняє завантажувати виконуваний код — файли .dex, JAR чи .so — звідки-небудь, крім Play, і робить виняток для коду, що працює у віртуальній машині чи інтерпретаторі, як-от JavaScript, — який однаково мусить відповідати всім іншим правилам Play.

Технічна межа суворіша за юридичну. Оновлення замінює JavaScript і ресурси — зображення, шрифти, тексти — і більше нічого. Усе, що змінює нативний код, потребує нового бінарника й нового рев’ю: додати бібліотеку з нативним модулем, змінити дозвіл, оновити React Native, змінити іконку. Небезпечний випадок — проміжний: оновлення, написане під новішу збірку, приходить на телефони зі старішою. JavaScript кличе нативний модуль, якого немає, і застосунок падає на старті. Expo запобігає цьому через runtime version — мітку нативного шару, яку несе кожна збірка й кожне оновлення, тож оновлення пропонують лише збіркам із тією самою міткою. Політика fingerprint рахує мітку з усього, що може вплинути на нативний код, — це надійніше, ніж піднімати її вручну й пам’ятати про це.

Релізи, оновлення й дедлайни магазинів на 2026 рік

React Native випускає мінорну версію — 0.86, 0.87 — приблизно що два місяці, і команда релізів підтримує три останні. Найновіша — «Active», із частими патчами; найстаріша з трьох — «End of Cycle», лише з виправленнями важливих регресій; усе старіше — «Unsupported». На практиці версію підтримують близько пів року. Від 0.83, з грудня 2025 року, приблизно кожен другий реліз планують без змін, що щось ламають для користувача, — такими були 0.83 і 0.86, — щоб темп було легше витримувати.

Оновлюватися на одну мінорну версію — нудно й займає пів дня. Оновитися на чотири одразу — займає два тижні, бо фреймворк, бібліотека навігації, кожен нативний модуль і SDK обох платформ рухаються разом, і падіння після оновлення може прийти від будь-якого з них. React Native Upgrade Helper показує точний diff шаблону між будь-якими двома версіями — це більшість нативної роботи в «голому» проєкті. Таблиця релізів вище — ще й бюджет: пів року підтримки означає, що команда, яка оновлюється двічі на рік, ніколи не сидить на непідтримуваній версії, а та, що оновлюється раз на рік, — сидить завжди.

Який React Native перед вами

Дедлайни магазинів — успадковані від обох платформ

Кросплатформний застосунок не звільнений від календаря жодної з платформ — він має обидва. Кожен магазин піднімає мінімальні вимоги до збірок у визначену дату, і зміна доходить до React Native через нативні проєкти та через кожну нативну залежність. Ось ті, що діють або настають близько до дати цієї сторінки.

Скільки насправді спільного — і яка нативна робота лишається

Обіцянка, яку чують, — одна кодова база на дві платформи. Чесна версія така: бізнес-логіка, мережа, стан і більшість екранів спільні, а решта — ні. Патерни навігації різні, жест «назад» є на одній платформі й немає на іншій, діалоги дозволів поводяться інакше, і кожен магазин має власні правила щодо того, що ви зобов’язані показати. React Native дає Platform.select і файли .ios.tsx / .android.tsx саме тому, що остання частина має розходитися.

Коли для можливості немає JavaScript-APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни, ви пишете нативний модуль — невеликий шматок Swift чи Kotlin, відкритий для JavaScript. Це нормально, а не провал підходу, але це мить, коли команді потрібен хтось, хто читає документацію платформи. Shopify після п’яти років перенесення кожного застосунку на React Native написав 2025 року, що «100% React Native має бути антиціллю»: віджети домашнього екрана, застосунки для годинника, моделі на пристрої й ярлики Siri краще будувати нативно. Команда React Native, де ніхто не розуміє нативного боку, зрештою впирається в задачу, до якої не дотягнеться жоден обсяг JavaScript.

П’ять кейсів і те, чого в кожному бракувало

Кожен кейс задокументували ті, з ким він стався: інженерні блоги, бюлетень безпеки, повідомлення постачальника про закриття. Разом вони покривають рішення взяти фреймворк, ціну перерендерів, зникнення хостингової залежності, інструменти розробки як поверхню атаки й рішення піти.

Перший кейс досі цитують у кожній розмові про React Native — і зазвичай хибно. У червні 2018 року Габріел Піл опублікував звіт Airbnb про два роки з React Native. Заголовком була продуктивність; суттю — структура. Airbnb додав React Native у два великі нативні застосунки, що й далі швидко змінювалися: 80 000 рядків продуктового коду на 220 екранах плюс 40 000 рядків інфраструктури на JavaScript — усередині застосунків, де на кожній платформі було приблизно вдесятеро більше коду й учетверо більше екранів. Щоб продуктова робота була можлива, інфраструктурна команда обгорнула для React Native мережу, експерименти, інтернаціоналізацію й анімовані переходи спільних елементів — і підтримувала ці обгортки в ногу з нативним кодом, що не переставав змінюватися. Їхніми словами, вони «зрештою підтримували код на трьох платформах замість двох». Вони також несли близько п’ятдесяти комітів, накладених поверх React Native, що робило кожне оновлення болісним, а час запуску середовища JavaScript шкодив стартовим екранам і диплінкам. Нову роботу на React Native зупинили, а найвідвідуваніші екрани запланували повернути в натив до кінця 2018 року. Більшість інженерів, що з ним працювали, досі оцінювали його добре. Урок — про межі, а не про швидкість.

Третій кейс — сервіс, який просто закінчився. CodePush, сервіс оновлень «по повітрю» від Microsoft, роками був типовим способом доставляти виправлення JavaScript у застосунки на React Native. Він жив усередині App Center, і 31 березня 2025 року Microsoft закрив App Center — а з ним і CodePush. Самостійний сервер, який Microsoft запропонував для власного хостингу, заархівували за два місяці. Команди, для яких OTA був частиною реагування на інциденти, втратили його в конкретну дату, а застосунок, чиї встановлені бінарники дивилися на старий сервіс, більше взагалі не міг отримувати виправлень — зрушити їх міг лише реліз у стор. Виправлення існувало завжди — оновлення від Expo чи сумісний сервіс, — але вимагало нативної зміни, а отже, рев’ю. План виходу з хостингової залежності дешево написати, поки сервіс іще працює.

Четвертий кейс атакував розробників, а не користувачів. 3 листопада 2025 року JFrog розкрив CVECVECommon Vulnerabilities and Exposures — публічний номер відомої вразливостіПублічний ідентифікатор відомої вади безпеки, як-от CVE-2021-44228 для Log4Shell, щоб постачальники, сканери й бюлетені мали на увазі той самий баг. Номер каже, що вада існує; наскільки вона небезпечна саме для вас, залежить від того, чи працює у вас уражена версія і чи відкрита назовні вражена частина.Усі терміни-2025-11953 з оцінкою 9,8 з 10 у @react-native-community/cli-server-api — пакеті, на якому працює дев-сервер Metro, що його запускає npx react-native start. Сервер слухав усі мережеві інтерфейси, а не лише машину розробника, і один із його ендпоїнтів передавав частину запиту у функцію, що відкриває файли й URL засобами операційної системи. Будь-хто, хто міг дістатися порту, виконував команди на комп’ютері розробника; на Windows — ще й із довільними аргументами. Версія 20.0.0 це виправила. VulnCheck бачив експлуатацію з 21 грудня 2025 року — так доставляли шкідливе ПЗ, — а 5 лютого 2026 року CISA додала вразливість до свого каталогу експлуатованих. Дев-сервер — це сервер: прив’язуйте його до localhost, тримайте подалі від недовірених мереж і оновлюйте інструменти так само вчасно, як залежності самого застосунку.

Де він вироджується

React Native щедрий там, де вебкоманда сильна, і мовчазний там, де вона слабка. Компоненти, стан і отримання даних переходять просто з React, тож екран будувати легко. Не переходять другий потік, нативні проєкти й календар магазинів — і майже кожен збій — одне з цього:

• Анімації й ефекти скролу, керовані з JavaScript, що смикаються тієї миті, коли в потоку з’являється справжня робота (рядки 8–9).
• Довгі списки через .map() або віртуалізовані списки з дорогими немемоїзованими рядками (рядок 10).
• Глобальне сховище, що на кожну зміну перерендерює кожен змонтований екран (рядок 13).
• Фото в повній роздільності, декодовані в пам’ять заради мініатюр (рядок 4).
• Правлені руками теки ios та android, що перетворюють кожне оновлення на конфлікт злиття.
• Версія, що відстала більш ніж на три мінорні, і нативні бібліотеки, які так і не мігрували на нову архітектуру.
• Оновлення «по повітрю» без runtime version, поетапного розгортання й відкату.
• Команда без нативних навичок, що стає першого ж разу, коли фічі потрібен модуль, віджет чи дедлайн магазину.
• Тестування лише на свіжому iPhone, де потік JavaScript достатньо швидкий, щоб приховати всі помилки вище.
• Дев-сервер, доступний з мережі.

Чесна межа — другий потік і друга платформа. Продукт, чия суть — безперервна власна графіка (гра, інструмент для малювання, конвеєр камери), бореться з архітектурою, бо його гарячий шлях хоче жити повністю по один бік переходу. Продукт, збудований навколо можливості, яка не має JavaScript-поверхні й змінюється з кожним релізом ОС, однаково живе в нативному коді. І економіка не стала: React Native окупається, коли одна спільна реалізація економить більше, ніж коштує шар фреймворку, а рішення Shopify 2026 року показує, що цей баланс може зрушити. Для форм, списків, стрічок, комерції й робочих застосунків, які будує команда, що вже пише на React, — тобто для більшості того, що будують, — це досі дуже вигідний обмін.

Практична перевірка займає десять хвилин. Прочитайте версію React Native у package.json і знайдіть її рядок у таблиці релізів. Складіть список нативних залежностей і перевірте в кожної підтримку нової архітектури й дату останнього релізу. Відкрийте найповільніший екран у release-збірці на телефоні середнього класу з Android з увімкненим монітором продуктивності. Знайдіть у коді useNativeDriver: false, обробники onScroll, що викликають setState, і .map( усередині ScrollView. Переконайтеся, що оновлення «по повітрю» несуть runtime version. І звірте target API для Android і версію Xcode з таблицею дедлайнів.

Коли це застосовувати

Пов’язані сторінки

• РозробкаFlutterFlutter — це UI-фреймворк від Google, який малює кожен піксель застосунку власним рушієм з однієї кодової бази на Dart для iOS, Android, вебу й десктопа. Через цей вибір застосунок на Flutter виглядає однаково всюди й не змінюється, коли змінюється операційна система, — навіть коли вона змінюється навмисно, як це зробила iOS 26. Сторінка починається з шістнадцяти речей, які потрібні застосунку, і того, малює їх Flutter чи мусить просити платформу; далі — три дерева й бюджет кадру, ціна перебудови, Dart та ізоляти, межа з платформою й редизайни ОС, релізи до Flutter 3.47, п’ять задокументованих кейсів і те, де все це вироджується.
• РозробкаReactReact — бібліотека JavaScript для побудови інтерфейсів із компонентів, кожен з яких описує, що має бути на екрані за поточного стану. Далі React сам з’ясовує, як змінити сторінку, щоб вона цьому відповідала, і майже всі складнощі з ним походять із порушення цієї моделі: нечиста робота під час рендеру, стан там, де він не може бути джерелом правди, або ефект, що робить чужу роботу. Сторінка починається з усіх вбудованих хуків на одному екрані й чотирьох причин, з яких компонент рендериться; далі — рендер і коміт, перерендери, стан як знімок, ефекти, серверні компоненти й п’ять задокументованих кейсів.
• РозробкаPWAПрогресивний вебзастосунок, або PWA, — це сайт із service worker і вебманіфестом, який можна встановити, який працює офлайн і поводиться як застосунок. SDK для PWA не існує: що може встановлений вебзастосунок, залежить від браузера й платформи, і саме розрив між Chrome на Android і Safari на iPhone визначає більшість продуктових рішень. Сторінка починається з шістнадцяти можливостей і того, де кожна працює в жовтні 2026 року; далі — service worker і оновлення, яке не приходить, стратегії кешування й сховище, яке можуть очистити, встановлення на чотирьох платформах, що дозволяє Apple і як це змінювалося, питання магазинів застосунків, п’ять задокументованих кейсів і те, де все це вироджується.