React Native чи нативна розробка — зазвичай перше технічне рішення в мобільному проєкті, і воно на роки вперед впливає на бюджет, терміни та найм. Універсально правильної відповіді немає. Нижче порівнюємо обидва підходи за тим, що важливо для бізнесу, — вартість, швидкість виходу на ринок, продуктивність, доступ до функцій пристрою, якість інтерфейсу і підтримка, — а наприкінці даємо таблицю, за якою можна оцінити власну ідею.
Як працює кожен підхід
Нативна розробка
Нативний застосунок пишуть окремо для кожної платформи інструментами Apple і Google: Swift зі SwiftUI або UIKit для iOS, Kotlin із Jetpack Compose для Android. Ви отримуєте прямий доступ до кожного API платформи в день його виходу і повний контроль над продуктивністю. Ціна — дві кодові бази, зазвичай два профільні розробники чи дві команди і постійна робота, щоб обидва застосунки розвивалися синхронно.
React Native
React Native — фреймворк із відкритим кодом від Meta. Застосунок пишуть на JavaScript або TypeScript із React, а на iOS і Android він відображає справжні нативні компоненти інтерфейсу — це не вебсторінка всередині застосунку. Відколи Нова архітектура стала типовою, JavaScript звертається до нативного коду напряму і, де треба, синхронно, тож багато старих вузьких місць зникло. Більша частина коду, часто переважна, спільна для обох платформ.
Де місце Flutter
Flutter від Google — ще один поширений кросплатформний варіант. Застосунки пишуть мовою Dart, а інтерфейс Flutter малює власним рушієм рендерингу, а не нативними компонентами платформи. Завдяки цьому легко зробити однаковий до пікселя кастомний UI на всіх платформах. Це теж надійний вибір; між Flutter і React Native зазвичай обирають за мовою, яку знає команда, наявною кодовою базою та екосистемою потрібних бібліотек.
React Native чи нативна розробка: порівняння
| Критерій | React Native | Нативна розробка (Swift / Kotlin) |
|---|---|---|
| Кодова база | Одна спільна, з платформними частинами там, де потрібно | Дві окремі |
| Вартість для iOS + Android | Помітно нижча: одна команда, більшість функцій реалізують один раз | Вища: більшу частину клієнтської роботи роблять двічі |
| Вихід на ринок | Швидше, обидві платформи виходять разом | Повільніше або спершу одна платформа |
| Продуктивність | Не відрізнити від нативної для типових бізнес-застосунків | Максимальна, особливо для графіки та важких обчислень |
| Доступ до функцій пристрою | Через бібліотеки та нативні модулі | Прямий, включно з новими API в день релізу |
| Інтерфейс | Справжні нативні компоненти; потрібна увага до конвенцій платформ | Повністю платформний вигляд і найновіші компоненти дизайну першими |
| Оновлення без магазину | Зміни в JavaScript можна доставити без релізу в магазині (з Expo) | Кожна зміна проходить модерацію |
| Команда | Розробники JavaScript/TypeScript, близькі до вебу та Node.js | Окремі спеціалісти з iOS та Android |
Вартість, терміни та підтримка
Головна причина, чому компанії обирають React Native, — економіка. Одна команда робить кожну функцію один раз для обох платформ, тож ви запускаєтеся на iOS і Android одночасно з одним бюджетом. Економія реальна, але менша за половину: дизайн, бекенд, QA та управління проєктом потрібні в будь-якому разі, а частина платформної роботи лишається завжди — дозволи, вимоги магазинів, налаштування push-сповіщень, інколи нативні модулі.
Найм і структура команди важать не менше за першу розробку. Команда React Native працює тією самою мовою, що й сайт на React чи Next.js і бекенд на Node.js, тому розробники можуть переходити між частинами продукту, а знання не замикаються в голові однієї людини. У нативній розробці потрібні люди під кожну платформу, а синхронізація функцій і релізів між ними вимагає постійної координації.
У підтримці свої компроміси. Застосункам на React Native періодично потрібні оновлення фреймворку і бібліотек, а застаріла залежність може заблокувати оновлення. Нативні застосунки цього шару не мають, але кожен щорічний реліз iOS та Android доводиться проходити з двома кодовими базами. В обох випадках плануйте регулярну підтримку, а не чекайте, поки щось зламається.
Продуктивність, функції пристрою та якість інтерфейсу
Продуктивність
Для списків, форм, стрічок, карт, оплати, чату і відтворення медіа добре зроблений застосунок на React Native відчувається так само, як нативний. Плавні анімації виконуються в UI-потоці за допомогою бібліотек на кшталт Reanimated. Нативна розробка однозначно виграє там, де потрібне тривале важке навантаження: 3D-ігри, AR, обробка відео чи аудіо в реальному часі, машинне навчання на пристрої з жорсткими вимогами до затримки. Проблеми зі швидкодією в React Native зазвичай спричиняє реалізація — зайві перерендери, завеликі зображення, важкі обчислення в JavaScript-потоці, — а не сам фреймворк.
Доступ до функцій пристрою
Камера, геолокація, Bluetooth, біометрія, push-сповіщення, фонове аудіо, вбудовані покупки, робота з файлами — усе це доступне в React Native через підтримувані бібліотеки. Якщо чогось немає, розробники пишуть нативний модуль на Swift чи Kotlin і викликають його з JavaScript. Два чесні застереження: зовсім нові API операційних систем потрапляють у бібліотеки React Native із затримкою, а розширення платформ — віджети на головному екрані, застосунки для Apple Watch чи Live Activities — і досі пишуть нативно, навіть у проєкті на React Native.
Якість інтерфейсу
Оскільки React Native відображає справжні компоненти платформи, введення тексту, прокручування та доступність поводяться так, як очікують користувачі. Добра команда все одно зважає на конвенції платформ — патерни навігації, жест «назад», системні діалоги, — а не нав'язує обом однаковий дизайн. Коли Apple чи Google оновлюють дизайн-мову, нативні застосунки отримують нові компоненти першими; бібліотеки React Native підтягуються пізніше.
Що змінює Expo
Expo — фреймворк із відкритим кодом і набір сервісів довкола React Native; документація React Native радить починати нові застосунки саме з такого фреймворку. На практиці Expo дає:
- Готовий набір нативних модулів — камера, сповіщення, геолокація, захищене сховище, медіа тощо; вони підтримуються разом і оновлюються раз на рік як один SDK.
- Хмарні збірки та публікацію в магазини (EAS Build і Submit) — не треба самостійно підтримувати машини для збірки і налаштування підписів.
- Оновлення «по повітрю» (EAS Update), щоб доставляти виправлення та зміни в JavaScript без очікування модерації, у межах правил магазинів.
- Власний нативний код, коли він потрібен, через development builds і config plugins. Уявлення, що Expo не дозволяє використовувати нативні модулі, давно застаріло.
Коли обирати React Native, а коли нативну розробку
| Ваша ситуація | Що краще підходить | Чому |
|---|---|---|
| Бізнес-застосунок: акаунти, каталог, бронювання, оплата, чат, карти | React Native | Одна кодова база, нативний UI, швидший запуск |
| Потрібні iOS і Android одразу при обмеженому бюджеті | React Native | Дві платформи приблизно за ціною однієї з невеликою доплатою |
| MVP для перевірки ідеї | React Native (або вебзастосунок) | Найважливіші швидкість і вартість змін |
| Ваша команда чи сайт уже працює на React і TypeScript | React Native | Спільна мова, навички, інколи й код |
| 3D-гра, AR або застосунок із важкою графікою | Нативна розробка (або ігровий рушій) | Потрібен повний контроль над GPU і максимальна продуктивність |
| Обробка аудіо/відео в реальному часі або ML на пристрої з жорсткими вимогами до затримки | Нативна розробка | Важить кожна мілісекунда і прямий доступ до заліза |
| Продукт, побудований навколо найновіших можливостей платформи (віджети, Watch, CarPlay) | Нативна розробка | Нові API доступні в день релізу |
| Великий наявний нативний застосунок із нативною командою | Залишатися на нативі; додавати екрани на React Native, лише якщо це допомагає | Переписування рідко окупається |
Чи можна змінити підхід пізніше?
Так, в обидва боки, і це не обов'язково переписування всього за раз. Застосунок на React Native може містити нативні екрани й модулі, тож критичні для продуктивності частини можна переносити на Swift чи Kotlin поступово. Нативний застосунок може вбудувати React Native для нових розділів, щоб зробити їх спільними для обох платформ. Доступним майбутній перехід робить архітектура: бізнес-логіка на бекенді за задокументованим API, дизайн-система замість одноразових екранів і чіткі межі між інтерфейсом і даними. Тоді змінюється лише мобільний клієнт.
Як ми обираємо підхід в OXIOS
Більшість мобільних застосунків ми створюємо на React Native та Expo, бо для продуктів, з якими приходять наші клієнти, — бронювання, доставка, медицина, освіта, маркетплейси — це дає застосунки нативної якості на обох платформах швидше і дешевше. Golden Nest — застосунок-помічник для людей старшого віку з push-нагадуваннями і підписками через Stripe та вбудовані покупки — опублікований в App Store і Google Play з однієї кодової бази. Tropa, застосунок для самостійних екскурсій, працює з офлайн-маршрутами, а аудіогід у ньому грає навіть на заблокованому екрані.
Коли проєкту справді потрібна нативна розробка — важка графіка, AR, глибока робота з залізом, — ми кажемо про це ще на етапі дискавері, а не підганяємо задачу під фреймворк. Детальніше — на сторінках React Native розробка і розробка мобільних застосунків.
Не впевнені, який стек підходить вашому застосунку? Опишіть свою ідею й отримайте протягом одного робочого дня безкоштовну оцінку з рекомендованим підходом, термінами та діапазоном бюджету.