Що насправді означає «нативний» для мобільних застосунків

Коротко

• «Нативний» не означає, що застосунок напряму говорить із ядром. Жоден застосунок цього не робить — навіть написаний на Swift. Будь-який сторонній застосунок на iOS, хоч би на чому він був побудований, працює у тій самій пісочниці, яку накладає операційна система, і звертається до апаратного забезпечення через ті самі системні фреймворки
• ART в Android спочатку виконує ваш код через інтерпретатор і JIT, а вже потім компілює гарячі шляхи заздалегідь у фоні — це зворотний порядок до того, що зазвичай уявляють, і саме так Android працює за замовчуванням із Android 5.0
• Реліз-збірки Flutter теж компілюються заздалегідь, у справжній машинний код. Це не «виконання у віртуальній машині», як часто описують. Реальна, вимірювана ціна — це двигун, який Flutter тримає в пам'яті постійно; про це окремо, з цифрами
• Справжня різниця — у тому, з чим лінкується мова, а не в тому, наскільки вона привілейована. Swift звертається напряму до Core Data, Core Animation і Metal. Flutter і React Native доходять до того самого апаратного забезпечення через міст, який хтось має написати й підтримувати
• Саме через цей міст нові функції Apple з'являються у Swift першими. Новий SDK доходить до кожного Swift-проєкту того дня, коли Apple його випускає. Кросплатформний плагін для тієї самої функції з'являється тоді, коли до нього доходять руки в його мейнтейнера
• Ніщо з цього не робить кросплатформність «гіршою» за замовчуванням. Це просто інший набір компромісів — і ті з них, які справді доходять до ваших клієнтів, можна виміряти. Ми їх виміряли

Ми розробляємо і нативний Swift, і Flutter, і React Native, тож це те пояснення, яке ми даємо клієнту перед вибором — а не аргумент на користь того, що нам вигідніше продати.

Що люди мають на увазі під «нативним» — і що з цього правда

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

Нативний iOS: ближче до фреймворків Apple, а не до ядра

Що насправді дають Swift і SwiftUI — це пряме лінкування. Застосунок iOS, написаний на Swift, звертається до Core Data, Core Animation і Metal так само, як і будь-який власний застосунок Apple — без прошарку перекладу, без мосту, без мейнтейнера плагіна між вашим кодом і API. Це також означає, що ваш інтерфейс може слідувати Human Interface Guidelines від Apple, використовуючи справжні компоненти платформи, а не їх перемальовану імітацію.

Це реальна перевага. Просто не та, яку має на увазі «доступ на рівні ядра». Пісочниця, вимоги до підпису коду й процес перевірки застосовуються однаково — незалежно від того, написано бінарник на Swift чи скомпільовано з Dart.

Нативний Android теж нативний — просто компілюється інакше

Застосунки Android, написані на Kotlin чи Java, настільки ж нативні для Android, наскільки Swift нативний для iOS. Де платформи справді розходяться — це рантайм під капотом, і звичний опис цього рантайму має переплутаний порядок. ART в Android спочатку виконує щойно встановлений застосунок через свій інтерпретатор і JIT-компілятор; потім JIT передає те, що дізнався про те, які методи справді виконуються часто, компілятору dex2oat прямо на пристрої, і той компілює цей гарячий код заздалегідь у фоні. Холодний код увесь час лишається інтерпретованим. ART є типовим рантаймом Android з версії Android 5.0, що замінив Dalvik — понад десять років тому.

Де накладні витрати Android справді реальні — це фрагментація: застосунок має коректно працювати на набагато більшій кількості чипсетів, розмірів екранів і версій ОС, ніж будь-коли вимагає iOS, і чимала частина вражень «Android повільніший» насправді пояснюється слабким пристроєм з невеликою кількістю RAM, а не самим рантаймом.

Де кросплатформні фреймворки справді додають прошарок

Це та частина, яку варто зрозуміти правильно, бо обидва основні фреймворки описують неточно — але в протилежних напрямках.

Flutter у продакшні не інтерпретується під час виконання. Власна документація Flutter з архітектури прямо каже: «для релізу застосунки Flutter компілюються напряму в машинний код — інструкції Intel x64 або ARM». Віртуальна машина використовується лише під час розробки, для hot reload. Реальна структурна ціна інша: Flutter постачає і тримає власний рушій рендерингу в пам'яті протягом усього життя застосунку, бо він малює кожен піксель сам, замість використання компонентів UIKit. Це реальна, вимірювана різниця в пам'яті — скільки саме і за яких умов, ми розбираємо окремо.

React Native йде іншим шляхом: він тримає рушій JavaScript (Hermes) запущеним поруч із нативними в'юхами UIKit протягом усього життя застосунку, тож ви платите за два менеджери пам'яті там, де Swift-застосунок платить за один. Цю ціну теж можна виміряти, і ми її виміряли.

Інший реальний розрив — це охоплення. Власна документація Flutter описує звернення до API платформи поза межами свого ядра як повідомлення, надіслане через «канал платформи» до нативного коду, який хтось має написати. React Native каже те саме про власні нативні модулі: функції платформи «не доступні напряму з react-native», тож щоб до них дістатися, треба написати й підтримувати справжній Swift чи Kotlin під капотом. Нове API від Apple доступне кожному Swift-проєкту того ж дня, коли Apple його випускає. До Flutter чи React Native воно доходить лише тоді, коли для нього з'являється плагін, а це можуть бути дні, а може не статися взагалі.

Що насправді змінюється, поруч

Це не рейтинг. Що насправді робить кожен підхід і що коштує дійти до того самого результату.

Що це означає на практиці

Усе вище перестає бути абстракцією, щойно застосунок опиняється під тиском на пам'ять. У єдиному опублікованому тесті на iPhone, де той самий застосунок збудовано на нативному Swift, Flutter і React Native і всі три виміряно однаково, одна прокрутка списку зі 100 елементів додала 9,74 МБ у Swift, 25,33 МБ у Flutter і 45,13 МБ у React Native — Swift використав на 62% менше пам'яті, ніж Flutter, і на 78% менше, ніж React Native (iPhone 16 Plus, по три прогони, серпень 2025). iPhone не сповільнює важкий застосунок — він його завершує, починаючи з найважчого, і жодного звіту про збій це не залишає. Окремо ми розібрали, у що це обходиться комерційно, а повне порівняння з джерелами того, що Flutter і React Native справді додають у RAM і CPU, з кожною цифрою, підписаною пристроєм і версією фреймворку, — тут.

То коли «нативність» справді має значення?

Ефективність — лише одна зі змінних, і рідко єдина, що вирішує долю проєкту.

• Лише iPhone, і ефективність важлива — фонове аудіо, камера, ШІ на пристрої, старіше залізо: нативний Swift — пряма відповідь, і з однією платформою це ще й дешевший варіант
• У планах віджети або Live Activities: ця частина буде на Swift незалежно від того, на чому побудований основний застосунок — ліміт пам'яті, під яким вони працюють, не вміщує вбудований рушій
• Обидві платформи, звичайний контент, обмежений бюджет: Flutter або React Native — законний вибір: одна команда, дві платформи, і для застосунку бронювання чи магазину різниця в пам'яті може ніколи не дійти до клієнта
• У вас уже є команда на React чи Dart: це реальний актив, якого не показує жоден бенчмарк. Запуск цього кварталу може переважити легшість наступного

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

Часті запитання

Чи мають нативні застосунки доступ до ядра на iPhone?

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

Чи Android досі використовує Dalvik?

Ні. ART замінив Dalvik як типовий рантайм Android ще в Android 5.0, понад десять років тому. ART спершу виконує щойно встановлений застосунок через інтерпретатор і JIT-компілятор, а потім у фоні заздалегідь компілює код, який справді працює найчастіше.

Чи Flutter працює у віртуальній машині?

Не в продакшені. Реліз-збірки Flutter заздалегідь компілюються в машинний код; віртуальна машина працює лише під час розробки, для hot reload. Справжня ціна Flutter — рушій рендерингу, який він тримає в пам'яті протягом усього життя застосунку.

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

У тесті SynergyBoat на iPhone 16 Plus одна прокрутка списку зі 100 елементів додала 9,74 МБ у Swift, 25,33 МБ у Flutter і 45,13 МБ у React Native. Це одне вимірювання одного сценарію, опубліковане постачальником, а не правило для кожного застосунку.

Чому нові функції Apple першими доходять до застосунків на Swift?

Нова API Apple з'являється в SDK того дня, коли Apple її випускає, тож кожен Swift-проєкт може одразу нею скористатися. Flutter і React Native отримують її лише тоді, коли хтось напише плагін-міст, — а це може тривати дні або не статися ніколи.

Чи кросплатформність — поганий вибір для стартапу?

Не за замовчуванням. Для двох платформ, звичайного контенту й обмеженого бюджету Flutter чи React Native — законний вибір: одна команда випускає обидва застосунки. Нативний Swift — пряма відповідь для продуктів лише під iPhone, чутливих до ефективності, і для віджетів чи Live Activities.

Джерела

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

Вимірювання

1. SynergyBoat — «Flutter vs React Native vs Native: 2025 Performance Benchmark» (31 серпня 2025)Цифри пам'яті на обкладинці й у тексті. iPhone 16 Plus, N=3, приріст RSS за прокрутку 100 елементів. Опубліковано виробником. Використовуємо лише частину про пам'ять; його порівняння часу кадру міряє різні величини проти одного бюджету.

Першоджерела

1. Apple — «Security of runtime process in iOS, iPadOS, and visionOS»Джерело твердження «усі сторонні застосунки працюють у пісочниці» та того, що застосунки отримують доступ до чужих даних лише через сервіси, явно надані iOS.
2. Apple — Human Interface GuidelinesВласний стандарт дизайну Apple, на який ми посилаємось щодо консистентності нативного інтерфейсу платформи.
3. Apple — документація Core Data
4. Apple — документація Core Animation (QuartzCore)
5. Apple — документація Metal
6. Android Open Source Project — «Implement JIT compiler»Джерело того, що ART спочатку виконує інтерпретатор і JIT, а потім використовує профіль JIT для запуску заздалегідь скомпільованого проходу компілятора dex2oat на пристрої.
7. Android Developers Blog — «Android 5.0 Lollipop SDK and Nexus Preview Images» (жовтень 2014)Джерело фрази «ART is enabled by default on API 21 & new Android devices with Android 5.0.»
8. Flutter — Architectural overviewДжерело фрази «для релізу застосунки Flutter компілюються напряму в машинний код» і того, що віртуальна машина — це функція, доступна лише в режимі розробки.
9. Flutter — Platform channelsДжерело того, як Flutter звертається до API платформи поза власним ядром: повідомлення, надіслане нативному коду через канал.
10. React Native — Native platform codeДжерело фрази «вашому застосунку може знадобитись доступ до функцій платформи, недоступних напряму з react-native», і того, що доступ до них означає написання нативного коду.

Про виміряну ціну рушія, який тримає в пам'яті кожен кросплатформний фреймворк, читайте Нативний Swift проти Flutter проти React Native: RAM, CPU та реальна ефективність, Swift проти Flutter або Swift проти React Native. Про те, що ця ціна робить із сесією в продакшні, читайте Чому iPhone закриває важкі застосунки першими.