Нативний Swift проти Flutter і React Native: RAM, CPU і справжня ефективність

Коротко

• У єдиному тесті на iPhone, який міряє всі три однаково, Swift витратив найменше пам’яті — і з великим відривом. Одне прокручування списку додало 9,74 МБ у Swift, 25,33 МБ у Flutter і 45,13 МБ у React Native — приблизно на 62% і 78% менше
• Цей розрив закладено в архітектуру, це не баг. Flutter і React Native тримають у пам’яті власний рушій. Застосунок на Swift користується тим, що вже є в телефоні
• Пам’ять важлива тому, що iPhone не сповільнюється — він закриває застосунки, починаючи з найважчого. Ваш клієнт бачить порожній кошик, а не збій. У звітах про збої це не з’являється ніколи
• Віджети вирішують цю суперечку самі. Віджети на головному екрані та Live Activities працюють у ліміті, замалому для рушія, який застосунок везе з собою, тож ця частина пишеться на Swift — хоч що ви оберете для основного застосунку
• Більшість користувачів різниці не помітить. На новому телефоні всі три відчуваються однаково. Вирішальною різниця стає на старих апаратах, у довгих сесіях і там, де застосунок довго працює без перерви
• Нативний виграє у вимірах і коштує дорожче, щойно вам потрібен ще й Android, бо друга платформа в ціну не входить. Оце і є справжній вибір — не Swift проти Flutter, а один застосунок проти двох
• Ставтеся скептично до чисел, які вам показують. На три з чотирьох найчастіших питань замовників — навантаження на процесор, розмір завантаження, швидкість відкриття — ніхто взагалі не опублікував тесту на iPhone зі Swift. Більшість чисел в обігу — з 2020 року, і описують вони те, чого вже ніхто не випускає

Ми створюємо на всіх трьох: нативний Swift, Flutter і React Native. Тож це порівняння компромісів, з якими ми живемо щодня, а не реклама одного з них.

Наскільки більше RAM і CPU споживають Flutter чи React Native порівняно з нативним Swift?

Приріст пам’яті за автоматизоване прокручування списку зі 100 елементів. SynergyBoat, iPhone 16 Plus, N=3, серпень 2025. Це саме приріст, а не повний обсяг пам’яті. Повні умови й обмеження — у таблиці нижче.

Про дві речі це число вам не каже, і обидві важливі.

Це пам’ять, а не CPU. Жоден опублікований бенчмарк не міряє CPU для всіх трьох на iOS відносно базового рівня Swift. Ми шукали ретельно — такого просто немає. Усе нижче, де є цифра CPU, або запускалося на Android, або не мало нативної гілки взагалі, і ми щоразу про це кажемо.

Більшість користувачів цього не відчує. На звичайних екранах усі три тримають 60 fps на сучасному залізі, а різниця в 35 МБ непомітна на телефоні з 8 ГБ RAM. Розрив стає вирішальним у трьох конкретних місцях: розширення застосунку з жорстким лімітом пам’яті, тривалі обчислення та старі пристрої або пристрої з малим обсягом RAM. Саме про них і йдеться в цій статті.

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

Спершу одне визначення, бо його постійно розмивають. Під «нативним Swift» ми маємо на увазі Swift з UIKit або SwiftUI. Ці два теж різняться за обсягом пам’яті. Але обидва працюють під ARC і жоден не завантажує друге середовище виконання. Саме на цій відмінності тримається все порівняння.

У що насправді обходиться це число пам’яті?

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

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

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

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

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

Що вимірювали	Нативний Swift	Flutter	React Native
Пам’ять — єдине питання зі справжньою відповіддю
Скільки пам’яті додалося під час прокручування довгого списку 1	9,74 МБ	25,33 МБ	45,13 МБ
Те саме число поряд зі Swift 1	базовий рівень	у 2,6× більше	у 4,6× більше
Наскільки результат коливався між запусками 1	± 0,18	± 0,47	± 10,94
Пам’ять проти нативного застосунку, на Android 2	на Android Swift немає	посередині	найбільше з усіх протестованих фреймворків
Старі числа з iPhone, які цитують досі 3	48 МБ	117 МБ	135 МБ
Навантаження на процесор — жоден тест на iPhone не містить Swift
iPhone, той самий застосунок, усі три 4	цього ніхто не публікував	цього ніхто не публікував	цього ніхто не публікував
Прокручування списку, на Android 5	на Android Swift немає	43,4%	52,9%
Робота камери, на Android 5	на Android Swift немає	81,6%	49,1%
Розмір завантаження — те, на що чекає ваш клієнт
Порожній застосунок, як він завантажується на iPhone 6	цього ніхто не публікував	10,9 МБ	цього ніхто не публікував
Механізми, які застосунок везе з собою лише щоб працювати 7	нічого — використовує те, що вже є в телефоні	рушій ~4 МБ	рушій JavaScript, ~2,4 МБ
Швидкість відкриття застосунку — порівнянних даних немає
Холодний запуск на iPhone, той самий застосунок 8	цього ніхто не публікував	цього ніхто не публікував	цього ніхто не публікував

1. SynergyBoat, серпень 2025 — той самий застосунок із флеш-картками, зібраний чотирма способами, iPhone 16 Plus, по три запуски на кожен. Swift витратив приблизно на 62% менше пам’яті, ніж Flutter, і на 78% менше, ніж React Native. React Native не просто витратив більше — він був найменш передбачуваним: коливався приблизно на чверть власного середнього, тож читайте це як «десь у чотири-п’ять разів», а не точно 4.6.
2. Oliveira та колеги, 2023 — єдине тут дослідження, яке пройшло академічне рецензування. Телефон на Android, а нативний застосунок, з яким порівнювали, написано на Java, не на Swift. Це напрямок руху, а не число з iPhone.
3. inVerita, червень 2020, на iPhone 6s. Виміряно до трьох найбільших змін продуктивності, які ці фреймворки будь-коли випускали. Наводимо, щоб ви впізнали ці числа, коли їх подадуть вам як актуальні — вони не актуальні.
4. Жоден публічний бенчмарк на iPhone не міряє навантаження на процесор із нативним застосунком на Swift. Flutter публікує живі числа з iPhone, але лише для Flutter і рахує їх так, що вони не зійдуться з тим, що ви виміряєте самі.
5. Tollin & Lidekrans, Лінчепінзький університет, 2023. Лише Android, версію на Swift не збирали. Зверніть увагу: між двома навантаженнями порядок міняється на протилежний — саме тому один-єдиний відсоток процесора для фреймворку вартий дуже небагато.
6. Власний FAQ Flutter, виміряно в березні 2021 на порожньому застосунку. Apple не публікує відповідного числа для Swift, а для React Native ми такого не знайшли, тож цьому числу немає з чим чесно стати поруч.
7. Розмір рушія — з FAQ Flutter; для React Native — виміри Callstack. Ось у чому структурна різниця: кросплатформний застосунок везе з собою друге середовище виконання й тримає його в пам’яті. Застосунок на Swift позичає те, що вже є в телефоні.
8. Команда Flutter проганяє тест швидкості відкриття Swift проти Flutter у власній системі збірки, але жодних чисел із нього не публікує. Один проєкт з відкритим кодом таки публікує швидкість відкриття проти справжнього застосунку на Swift — але не має версії на React Native.

Рядки, де написано цього ніхто не публікував, — це і є висновок, а не прогалина, яку ми не заповнили. На три з чотирьох найчастіших питань замовників немає опублікованого тесту на iPhone із нативним застосунком на Swift.

Числа, які виглядають як порівняння, але ними не є

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

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

DeviceLab від Flutter публікує живі показники RAM і CPU зі справжніх iPhone, окремо для кожного коміту. Ось бенчмарк прокручування станом на 6 вересня 2026: iPhone 16 Pro — 84,70 МБ, iPhone 11 — 80,91 МБ. У таблиці вище його немає, і це навмисно: він міряє Flutter проти Flutter, без жодного застосунку на Swift.

Але є два застереження щодо одиниць. Поруч наведено показники CPU: 9,33% і 13,72%. Обидва виміряні по всіх ядрах. Це не та методика підрахунку, яку використовує Xcode Instruments. Тож їх не можна ставити поряд ані з відсотками CPU на Android вище, ані з будь-яким числом для Swift, яке ви виміряєте самі. Ряд даних про пам’ять — це власний замір рушія dirty_memory_usage. Це не «брудна плюс стиснена» пам’ять у розумінні Apple, а пам’ять GPU наводиться окремо. Тож із показником обсягу пам’яті в Instruments це теж не порівнюється напряму.

У тій лабораторії також немає ані гілки на Swift, ані на React Native. Вона порівнює Flutter із попереднім Flutter. Це найкраще інструментовані дані в усій статті — і вони все одно не вирішують суперечку.

Якщо чесно прочитати цю таблицю, впадають в око чотири речі.

• Ніхто не опублікував контрольованого бенчмарку на iOS, де той самий застосунок написано трьома способами на актуальних середовищах виконання. Такого дослідження не існує. Хто показує вам таке — екстраполює
• Строга академічна робота — це Android із базовим рівнем на Java, тож про Swift вона сказати нічого не може. Ще вона міряла Flutter 3.0.3 на Skia і React Native 0.68.2 на JavaScriptCore. Обидва фреймворки відтоді замінили саме ці компоненти. Її метод — найкращий у галузі. Її середовища виконання — на два покоління старіші
• Результат перевертається залежно від навантаження. У даних із Лінчепінга Flutter виграє прокручування списку. А потім програє тест камери на 32 пункти
• Числа пам’яті з iOS і з Android не порівнянні взагалі — про це нижче

Чому пам’ять iOS і Android не можна ставити в одну колонку

На цьому спотикається майже кожна порівняльна стаття, навіть уважна в усьому іншому. У сесії «Глибоке занурення в пам’ять iOS» на WWDC18 Apple визначає обсяг пам’яті застосунку як його брудні та стиснені сторінки («чиста пам’ять фактично не рахується»), у сторінках по 16 КБ. Android через meminfo повідомляє PSS/RSS за цілком іншою моделлю. 90 МБ на iOS і 90 МБ на Android — це не той самий вимір. Усереднювати їх чи вибудовувати спільний рейтинг — нісенітниця.

З тієї сесії варто винести ще дві речі. Apple ніколи не публікує числового ліміту пам’яті. Він залежить від пристрою, а його перевищення спричиняє EXC_RESOURCE.

Власна документація Apple про звіти подій jetsam розбирає приклад. Процес використовує 92 802 сторінки × 16 384 байти = 1,52 ГБ, коли його завершують за per-process-limit. Але це те, що застосунок використовував. Це не опублікована стеля. Хто наводить конкретне «iOS убиває застосунки на X ГБ» — вигадує специфікацію.

То що ж обрати насправді?

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

Ось справжнє порівняння. Не Swift проти Flutter, а один нативний застосунок проти двох нативних застосунків проти одного спільного, який важчий на обох. Знайдіть свою ситуацію нижче.

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

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

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

Ось чесний підсумок. Для переважної більшості застосунків користувачі ніколи не відчують різниці в пам’яті чи CPU. Зате вони відчують погано зроблений застосунок на будь-якому з трьох. Обирайте за командою, платформною стратегією та конкретними системними фреймворками, від яких ви залежите. А потім виміряйте власну збірку на справжньому пристрої, перш ніж остаточно вирішувати.

Порівняння один на один, із повними доказами для кожного фреймворку: Swift проти Flutter і Swift проти React Native.

Джерела

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

Виміри

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. Tollin & Lidekrans — «React Native проти Flutter: порівняння продуктивності» (Лінчепінзький університет, 2023)Лише Android. Flutter 3.10.0 проти React Native 0.71.6, adb shell top, п’ять запусків по 30 секунд. Гілки на Swift немає. Розділ обговорення пояснює розрив у тесті камери, який більшість цитувань оминає.
4. Shopify Engineering — «Міграція на нову архітектуру React Native» (5 вересня 2025)Дані з продакшену Shopify Mobile і Point of Sale. Звітують і про свої регресії, і про виграші — саме тому ми це використовуємо.
5. Панель продуктивності Flutter DeviceLabЖиві показники RAM і CPU для кожного коміту зі справжнього заліза iPhone 11 та iPhone 16 Pro. Лише Flutter. CPU — це відсоток по всіх ядрах, а не показник за методикою Xcode Instruments. Посилання з документації Flutter про метрики продуктивності.
6. React Native — «На шляху до Hermes за замовчуванням»Містить числа Callstack/Mattermost для iOS: запуск на ~40% швидший, пам’яті на ~18% менше, застосунок +2.4 МіБ, на React Native 0.64.
7. Callstack — «Продуктивність Hermes на iOS»Оригінальні виміри Mattermost, які стоять за цими числами.

Документація самих виробників

1. Apple — «Глибоке занурення в пам’ять iOS», сесія 416 на WWDC18Визначає обсяг пам’яті застосунку як брудні + стиснені сторінки, у сторінках по 16 КБ. Зазначає, що ліміт залежить від пристрою, і жодного числа не публікує.
2. Apple — «Профілювання та оптимізація пам’яті вашої гри», сесія 10106 на WWDC22Джерело твердження, що на Apple silicon використані ресурси Metal рахуються як брудна пам’ять, бо CPU і GPU мають спільний пул.
3. Apple — «Виявлення високого споживання пам’яті за звітами подій jetsam»Розібраний приклад, який ми цитуємо: 92 802 сторінки × 16 384 байти = 1,52 ГБ у використанні на момент завершення за per-process-limit. Це споживання на момент смерті, а не опублікована стеля.
4. Форуми Apple Developer — EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=30 MB)Логи збоїв WidgetKit, про які повідомляли розробники, а не специфікація Apple. Джерело стелі ~30 МБ для віджетів.
5. FAQ Flutter — «Наскільки великий рушій Flutter?»Розміри мінімального застосунку: ~4,8 МБ завантаження для ARM64 Android, 10,9 МБ завантаження для iOS, з них ~4 МБ — рушій. Виміряно в березні 2021, без Material Components, --split-per-abi.
6. Flutter — рушій рендерингу ImpellerПідтверджує, що Impeller — єдиний рендерер на iOS і що він компілює шейдери заздалегідь, під час збірки.
7. Flutter — «Не бійтеся збирача сміття» (Matt Sullivan, 2019)Опис поколіннєвого збирача сміття: очищувач молодого простору, паралельний mark-sweep, idle-хуки рушія.
8. Meta Engineering — «Hermes: рушій JavaScript з відкритим кодом, оптимізований для мобільних застосунків» (2019)Чому Hermes постачається без JIT: розігрів псує час до інтерактивності, а JIT збільшує розмір коду й споживання пам’яті.
9. facebook/hermes, тікет #1829 — споживання пам’яті в Hermes V1Мейнтейнер із Meta пояснює, що HV32 споживає на ~40% менше пам’яті, але потребує відображення пам’яті, недоступного на iOS, тож там Hermes V1 постачається з HV64. Стосується React Native 0.84 і новіших (лютий 2026).
10. Нотатки до релізу React Native 0.70 (5 вересня 2022)Hermes стає рушієм за замовчуванням.
11. React Native — «Нова архітектура вже тут» (23 жовтня 2024)Fabric, TurboModules і режим без мосту за замовчуванням. Також джерело того факту, що старий міст лишається у 0.76 задля сумісності.
12. Нотатки до релізу React Native 0.76Єдині офіційні числа: APK для Android менший на ~3,8 МБ (20%), медіанний запуск швидший на ~15 мс (~8%). Числа щодо пам’яті не публікували.
13. React Native — документація про розширення застосункуВласне попередження React Native, що його споживання пам’яті «зазвичай завелике» для найтісніших бюджетів розширень. Зверніть увагу: сторінка досі описує віджет Today на 16 МБ, який Apple прибрала в iOS 18.

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

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

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

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

Якщо вам потрібна друга думка щодо цього рішення для конкретного продукту — поговоріть з нами. Ми випускаємо на всіх трьох і не маємо жодної вигоди з того, що саме ви оберете.