Swift проти React Native: RAM, CPU і ціна двох рантаймів

Якщо коротко

• React Native тримає в пам’яті дві системи одночасно: власний рушій JavaScript і нативні елементи інтерфейсу під ним. В одному рецензованому дослідженні він спожив більше пам’яті, ніж будь-який інший протестований фреймворк
• Одне прокручування списку додало 9,74 МБ у Swift проти 45,13 МБ у React Native, приблизно на 78% менше. Це був ще й найменш передбачуваний результат тесту: між запусками він гуляв на чверть власного середнього
• Пам’ять вирішує, чи переживе застосунок сесію. iPhone не вповільнює важкий застосунок — він його закриває, починаючи з найважчого. Ваш клієнт бачить порожній кошик, а не збій
• Власна міграція Shopify — найчесніший публічний показник. Запуск став приблизно на 3% швидшим на iPhone — а деякі складні екрани стали до 20% повільнішими, і кілька тижнів частка сесій без збоїв трималася нижче їхньої цілі
• Він повільніший не в усьому. В одному тесті з безперервною анімацією він споживав менше процесора й менше батареї, ніж нативна версія
• Віджети — це Swift у будь-якому разі. Вони працюють під лімітом, у який, за власною документацією React Native, його споживання пам’яті навряд чи впишеться
• Ваша нинішня команда може переважити все це. Якщо у вас уже працюють React-розробники, запуск цього кварталу може переважити вчетверо легший застосунок наступного року

Ми створюємо і на нативному Swift, і на React Native. Це те порівняння, яке ми справді проводимо всередині команди, перш ніж почати проєкт.

Наскільки React Native менш ефективний за нативний Swift?

За кожним числом нижче стоїть пристрій, версія фреймворку та інструмент вимірювання. Ті, у яких цього немає, ми називаємо в кінці. І не використовуємо.

Скільки насправді коштує вам ця цифра пам’яті?

Коли пам’яті бракує, iPhone не вповільнює застосунок — він його закриває, найважчий першим. Ваш клієнт не бачить збою. Він перемикається на інший застосунок на двадцять секунд, повертається — і знаходить порожній кошик та екран входу. Це найменш усвідомлена ціна важчого застосунку, і вона ніколи не з’являється у ваших звітах про збої.

Ми розібрали це окремо — разом зі стелею для віджетів, через яку частину функцій узагалі неможливо створити: Чому iPhone закриває важкі застосунки першими.

Усі числа, які ми змогли перевірити, в одній таблиці

Чотири речі, про які питають: пам’ять, навантаження на процесор, розмір завантаження і швидкість відкриття застосунку. Ось що справді виміряли — і чого не виміряли.

Читайте праву колонку, перш ніж користуватися будь-яким рядком. І читайте рядки, де написано цього ніхто не публікував, бо їх більше, ніж визнає будь-хто, хто продає вам фреймворк.

Один застосунок із флешкартками, зібраний обома способами й запущений на iPhone, — єдиний публічний тест, який ставить нативний Swift поряд із React Native. Він охоплює пам’ять. На інші три питання такого тесту не опубліковано.

Що вимірювали	Нативний Swift	React Native	Хто вимірював і на чому
Пам’ять — єдине питання зі справжньою відповіддю
Скільки додаткової пам’яті застосунок узяв під час прокручування довгого списку	9,74 МБ	45,13 МБ	SynergyBoat, серпень 2025. Той самий застосунок, зібраний обома способами, iPhone 16 Plus, по три запуски
Та сама цифра, поряд зі Swift	точка відліку	у 4,6× більше	Виведено з рядка вище — Swift спожив приблизно на 78% менше пам’яті
Наскільки результат гуляв між запусками	± 0,18	± 10,94	Той самий тест, і цей рядок важить не менше за попередній. React Native не просто споживав більше — він був разюче менш передбачуваним: розкид сягав приблизно чверті власного середнього. Читайте це як «приблизно вчетверо-вп’ятеро», а не точно 4.6
Пам’ять проти нативного застосунку, на Android	на Android Swift немає	найвища серед усіх протестованих фреймворків	Oliveira та колеги, 2023 — єдине рецензоване дослідження тут. Android, а нативний застосунок для порівняння був на Java. Це напрям, а не цифра для iPhone
Старі цифри для iPhone, які цитують і досі	48 МБ	135 МБ	inVerita, червень 2020, iPhone 6s — виміряно до того, як React Native змінив і рушій JavaScript, і всю свою архітектуру. Наводимо, щоб ви впізнали ці цифри, коли їх видають за актуальні
Навантаження на процесор — жоден тест на iPhone не містить Swift
iPhone, той самий застосунок, обома способами	цього ніхто не публікував	цього ніхто не публікував	Ми ретельно шукали й не знайшли жодного
Проти нативного застосунку, на Android	на Android Swift немає	найбільші накладні витрати серед протестованих фреймворків — але менші, ніж у нативного, в одному застосунку з безперервною анімацією	Те саме рецензоване дослідження. Цей виняток справжній, і його варто знати: React Native повільніший не в усьому
Розмір завантаження — те, на що чекає ваш клієнт
Найпростіший застосунок, як його завантажують на iPhone	цього ніхто не публікував	цього ніхто не публікував	Ні Apple, ні команда React Native не публікують порівнянної цифри для порожнього застосунку на iPhone
Механізми, які застосунок тягне із собою просто щоб працювати	немає — він користується тим, що вже є на телефоні	рушій JavaScript, близько 2,4 МБ	Вимірювання Callstack на iPhone. Це структурна різниця: ваш застосунок везе з собою другий рантайм і тримає його в пам’яті поряд із нативним
Як швидко відкривається застосунок — порівнянних даних немає
Холодний старт на iPhone, той самий застосунок	цього ніхто не публікував	цього ніхто не публікував	Єдиний відкритий проєкт, який публікує швидкість відкриття проти справжнього застосунку на Swift, не має версії на React Native

Кожен рядок має джерело в розділі Джерела — з точними пристроями, версіями та інструментами. Рядки з написом цього ніхто не публікував — це і є висновок, а не прогалина, яку ми не змогли заповнити.

Числа, схожі на порівняння, але не порівняння

Ці три спливають майже в кожному аргументі за React Native. Кожне міряє React Native проти старішої версії самого себе. Жодне не містить Swift. Якщо вам наводять одне з них як привід відмовитися від нативного, воно відповідає на інше питання.

Що кажуть	Що насправді порівнювали	Деталь, яку пропускають
«Тепер він стартує приблизно на 40% швидше»	Два рушії JavaScript — один проти одного	Callstack, на iPhone, на React Native 0.64. Пам’ять впала приблизно на 18% — а застосунок побільшав на 2,4 МБ
«Нова архітектура полагодила продуктивність»	React Native 0.76 проти 0.75	Власні нотатки до релізу, на Android: приблизно на 3,8 МБ менше, відкриття приблизно на 15 мілісекунд швидше. Жодної цифри щодо пам’яті не опубліковано
«Shopify довів, що це готове до продакшну»	Власні застосунки Shopify — до і після оновлення	Shopify, вересень 2025: приблизно на 10% швидше відкриття на Android, ~3% на iPhone — і поряд із цим деякі екрани до 20% повільніші, більше підвисань на обох платформах, а частка сесій без збоїв пару тижнів трималася нижче їхньої власної цілі

Обрати Swift чи React Native?

Ефективність — лише один із чинників, і рідко вирішальний. Чесний компроміс: нативний Swift виграє у вимірюваннях, а нативна розробка дорожчає тієї ж миті, коли вам потрібен ще й Android — бо друга платформа не входить у ціну.

Що створювати і чого це вам коштуватиме. Останню колонку зазвичай пропускають.

Якщо це ваша ситуація	Створюйте це	Чому	Чого це вам коштує
Тільки iPhone, Android не планується	Нативний Swift	Близько чверті приросту пам’яті, усі можливості Apple з першого дня і жодного другого рантайму в завантаженні	Нічого додаткового. З однією платформою нативна розробка ще й дешевша — одна кодова база і жодного прошарку фреймворку між вами та багами
Обидві платформи, а ефективність і є продуктом — фонове аудіо, камера, мапи, ШІ на пристрої або клієнти зі старішими телефонами	Нативна розробка на обох	Саме тут розрив у пам’яті перестає бути статистикою і починає закривати ваш застосунок посеред сесії	Чесно кажучи, дорога відповідь. Дві кодові бази: кожен екран створюється двічі. Дизайн, бекенд, продукт і тестування не дублюються, тож це помітно менше, ніж платити вдвічі, — але шар застосунку справді дублюється
У вас уже є команда React і TypeScript	React Native	Команда, яку ви вже маєте, — більший актив, ніж бенчмарк. Запуск цього кварталу цінніший за вчетверо легший застосунок наступного року	Найважчий і найменш передбачуваний результат у єдиному тесті на iPhone, що містить Swift. Варто переглянути рішення, якщо застосунок стане чутливим до продуктивності
Обидві платформи, звичайний контент, застосунок для бронювання чи магазину, бюджет обмежений	React Native	Одна команда на дві платформи — реальна економія, а для застосунку, який показує списки й форми, розрив може ніколи не дійти до ваших клієнтів	Значно важчий застосунок. Закладіть у бюджет тестування на найстарішому телефоні, який ви підтримуєте, а не на найновішому — саме там це видно
Віджети чи Live Activities важливі для продукту	Swift, що б ви ще не обрали	Власна документація React Native каже, що його споживання пам’яті, найімовірніше, надто високе, щоб вписатися в ці ліміти	Це не зовсім вибір. Плануйте Swift у команді від початку, а не дізнавайтеся про це пізно

Джерела

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

Вимірювання

1. SynergyBoat — «Flutter проти React Native проти нативної розробки: бенчмарк продуктивності 2025» (31 серпня 2025)Цифри ΔMemory. iPhone 16 Plus, N=3, приріст RSS за прокручування списку зі 100 елементів. Опубліковано самим виробником. Ми беремо лише його вимірювання пам’яті: порівняння часу кадру там міряє різні величини під один бюджет.
2. Oliveira, Moraes, Castor & Fernandes — «Аналіз накладних витрат на ресурси у фреймворках для розробки мобільних застосунків» (EASE 2023)Рецензоване. Samsung Galaxy S20 FE, Android 12, adb batterystats + meminfo, 45 запусків на бенчмарк, перші 15 відкинуто. Flutter 3.0.3 (Skia), React Native 0.68.2 (Hermes вимкнено), проти нативної Java. Без iOS, без Swift. Відкритий PDF через Утрехтський університет; DOI 10.1145/3593434.3593487.
3. Shopify Engineering — «Міграція на нову архітектуру React Native» (5 вересня 2025)Продакшн-дані застосунків Shopify Mobile і Point of Sale. Звітує і про свої регресії, і про виграші — саме тому ми його використовуємо.
4. React Native — «Курс на Hermes як рушій за умовчанням»Містить цифри Callstack/Mattermost для iOS: старт приблизно на 40% швидший, пам’ять приблизно на 18% нижча, застосунок на +2.4 MiB більший, на React Native 0.64.
5. Callstack — «Продуктивність Hermes на iOS»Оригінальні вимірювання Mattermost, що стоять за цими цифрами.

Першоджерельна документація

1. Apple — «Заглиблення в пам’ять iOS», сесія 416 на WWDC18Визначає обсяг пам’яті застосунку як брудні та стиснуті сторінки, які рахують сторінками по 16 КБ. Зазначає, що ліміт залежить від пристрою, і ніколи не публікує конкретного числа.
2. Apple — «Виявлення високого споживання пам’яті за звітами подій jetsam»Розібраний приклад, який ми цитуємо: 92 802 сторінки × 16 384 байтів = 1,52 ГБ у використанні на момент завершення через per-process-limit. Це споживання в момент смерті, а не опублікована стеля.
3. Apple Developer Forums — EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=30 MB)Логи збоїв WidgetKit, про які повідомляють розробники, а не специфікація Apple. Джерело стелі віджета в ~30 МБ.
4. Meta Engineering — «Hermes: рушій JavaScript з відкритим кодом, оптимізований для мобільних застосунків» (2019)Чому Hermes постачається без JIT: прогрів шкодить часу до інтерактивності, а JIT коштує розміру коду й пам’яті.
5. facebook/hermes issue #1829 — споживання пам’яті в Hermes V1Мейнтейнер Meta пояснює, що HV32 споживає приблизно на 40% менше пам’яті, але потребує відображення пам’яті, недоступного на iOS, тож Hermes V1 постачає там HV64. Діє з React Native 0.84 (лютий 2026).
6. Нотатки до релізу React Native 0.70 (5 вересня 2022)Hermes стає рушієм за умовчанням.
7. React Native — «Нова архітектура вже тут» (23 жовтня 2024)Fabric, TurboModules і bridgeless — за умовчанням. Також джерело факту, що застарілий міст лишається у 0.76 задля сумісності.
8. Нотатки до релізу React Native 0.76Єдині офіційні цифри: APK для Android приблизно на 3,8 МБ менший (20%), медіанний старт приблизно на 15 ms (~8%) швидший. Жодної цифри щодо пам’яті не опублікували.
9. React Native — документація щодо розширень застосункуВласне попередження React Native, що його споживання пам’яті «зазвичай завелике» для найтісніших бюджетів розширень. Зверніть увагу: сторінка досі обговорює віджет Today на 16 МБ, який Apple прибрала в iOS 18.

Відкритий код, який ви можете запустити самі

1. Вихідний код бенчмарка SynergyBoatУсі чотири реалізації — Swift, Flutter, React Native, Kotlin — разом з інструментуванням. Клонуйте й перезапустіть.
2. Пакет відтворення результатів EASE 2023Усі сирі дампи adb, що стоять за статтею. Їх можна перезапустити.
3. RNArchBench — React Native: стара архітектура проти новоїReact Native 0.81.5 з нативною базовою лінією на Kotlin, відтворюваний конвеєр аналізу. Лише Android, і самі автори називають свої дані щодо CPU та RAM описовими, а не підставою для статистичних висновків.
4. jacobras/flutter-vs-native-vs-kmpОдин застосунок у чотирьох стеках, включно з нативною базою на Swift/SwiftUI. Публікує лише розмір застосунку та час старту — без RAM і CPU. Архівовано в серпні 2026.

Джерела, які ми перевірили й не використали

1. inVerita — «Глибоке порівняння продуктивності» (червень 2020)Походження цифр «48 МБ / 117 МБ / 135 МБ». iPhone 6s і iPad Mini 3 з 2014 року, до Hermes, Impeller і нової архітектури. Посилаємося, щоб твердження можна було перевірити, а не як на рекомендацію.
2. inVerita — «Вивчення продуктивності» (березень 2020)Мікробенчмарки з обчисленням цифр числа пі, що стоять за твердженням «Flutter на 15% швидший за Swift». Міряють арифметику в циклі, на iPhone 6s.

Про те, як сюди вписується Flutter, читайте в порівнянні трьох або в Swift проти Flutter. Якщо хочете ухвалити це рішення для конкретного продукту, а не в абстракції — поговоріть з нами.