Як працює React Native
Застосунок на React Native складається з двох частин. Логіка та опис екранів пишуться на JavaScript або TypeScript — так само, як у веб-проєктах на React. А от кнопки, списки, поля введення й переходи між екранами — це справжні системні елементи iOS та Android, які фреймворк створює за вказівкою коду.
У нових версіях React Native взаємодію між JavaScript-частиною і системою суттєво перебудували, і вона стала швидшою та передбачуванішою. Для більшості бізнесових застосунків різниця зі швидкістю нативного коду користувачам непомітна.
Поверх React Native часто використовують Expo — набір інструментів, який бере на себе збірку, підписання, доступ до камери, сповіщень, файлів та інших можливостей телефона. Він помітно спрощує старт і подальші оновлення.
Переваги React Native
- Знайомі технології. JavaScript і TypeScript — одні з найпоширеніших мов розробки, тож знайти спеціалістів або передати проєкт іншій команді простіше.
- Спільний код з вебом. Типи даних, звернення до API, правила перевірки форм, тексти й переклади можна використовувати і на сайті, і в застосунку.
- Системні елементи інтерфейсу. Поля введення, прокручування, перемикачі поводяться так, як звик користувач конкретної платформи.
- Швидкі виправлення. Зміни в JavaScript-частині можна доставити користувачам без нової публікації в магазинах — у межах, які дозволяють правила Apple і Google.
- Велика спільнота. Для більшості типових задач — оплати, карти, аналітика, вхід через соцмережі — існують готові бібліотеки.
Недоліки та ризики
- Залежність від сторонніх бібліотек. Багато функцій реалізовано бібліотеками від спільноти. Якщо автор перестає їх підтримувати, заміна стає вашою задачею.
- Непрості оновлення. Перехід на нову версію React Native у проєкті, який давно не оновлювали, може вимагати помітних зусиль: разом із фреймворком змінюються залежності й налаштування збірки.
- Складна графіка й анімації. Ігри, редактори фото чи відео, дуже насичені анімаціями інтерфейси краще роблять нативно або на інших інструментах.
- Без нативних знань не обійтися. Для нестандартних функцій потрібні розробники, які розуміються на Swift і Kotlin, інакше проєкт впреться в межі готових бібліотек.
React Native чи Flutter
Обидва фреймворки дозволяють зробити якісний застосунок з одного коду. Вибір зазвичай визначають не технічні дрібниці, а контекст вашого бізнесу:
- якщо є веб-продукт на React і команда, яка його розвиває, — React Native дає більше вигоди за рахунок спільного коду та знань;
- якщо застосунок має складний фірмовий дизайн, однаковий до пікселя на всіх пристроях, — частіше зручніший Flutter;
- якщо нічого з цього немає, порівнюємо готові бібліотеки під ваші функції і досвід команди, яка підтримуватиме продукт.
Детальніше про те, коли один код на дві платформи взагалі має сенс, ми пишемо на сторінці про кросплатформні застосунки.
Expo чи «чистий» React Native
Для більшості нових проєктів ми радимо Expo: менше ручної роботи з налаштуваннями iOS та Android, простіша збірка і швидші оновлення. Сьогодні Expo дозволяє підключати й власні нативні модулі, тож колишнє обмеження «з Expo не можна нічого нестандартного» вже неактуальне.
Без Expo працюємо, коли проєкт уже давно існує в такому вигляді, коли потрібен повний контроль над нативною частиною або коли застосунок вбудовується в наявний нативний проєкт.
Швидкість застосунку
Скарги на «повільний React Native» здебільшого пов’язані не з фреймворком, а з тим, як написаний код. Типові причини: довгі списки, які малюють усі елементи одразу, зайві повторні оновлення екранів, важкі зображення без кешування, анімації, що виконуються в JavaScript замість системного рівня.
Ми вимірюємо, що саме гальмує, на реальних недорогих смартфонах, а не лише на потужних телефонах розробників. Після виправлень порівнюємо результат із початковим, щоб покращення було видно не на словах.
Новий проєкт чи оновлення старого
Для нового застосунку одразу закладаємо TypeScript, продуману навігацію і лише ті бібліотеки, які активно підтримуються. Якщо є веб-версія на React, домовляємося, які частини коду стануть спільними і як їх оновлювати синхронно.
Наявний застосунок нерідко потрапляє на доопрацювання із застарілою версією фреймворку, бібліотеками без підтримки і збіркою, яка ледве працює. Спершу відновлюємо стабільну збірку, далі оновлюємо React Native поетапно, щоб між кроками застосунок можна було випускати.
Публікація і життя після релізу
Застосунок на React Native проходить ту саму перевірку в App Store і Google Play, що й нативний. Ми готуємо збірки, сторінки в магазинах і відповіді про збір даних для обох платформ.
Після запуску важливо регулярно оновлювати сам фреймворк і бібліотеки: чим довше відкладати, тим дорожчий буде перехід. Можемо взяти це на себе в межах підтримки застосунку.
Що впливає на вартість
- Спільний код з вебом: чи є що перевикористати і наскільки він готовий до цього.
- Кількість і складність екранів: стандартні форми й списки чи нестандартні анімації.
- Нативні модулі: скільки функцій не покривають готові бібліотеки.
- Сервер: чи вистачить того самого API, що й для сайту, чи потрібні нові методи.
- Стан наявного проєкту: версія React Native, кількість застарілих залежностей, наявність тестів.
Оцінку даємо після розбору функцій і, для наявних застосунків, технічного аудиту.
Часті запитання
Чи можна використати код нашого сайту на React? Логіку, типи даних і роботу з API — так. Компоненти інтерфейсу доведеться переробити, бо в застосунку замість HTML використовуються системні елементи.
Чи можна оновлювати застосунок без перевірки в магазинах? Невеликі зміни в JavaScript-частині — так, якщо вони не змінюють суть застосунку. Нові нативні функції все одно публікуються звичайним шляхом.
Наш застосунок на старій версії React Native. Його треба переписувати? Здебільшого ні. Оновлення поетапно зазвичай дешевше й безпечніше, ніж переписування з нуля.
Чи підійде React Native для великого продукту? Так, на ньому працює чимало великих застосунків. Головне — продумана структура коду та уважний вибір бібліотек.
Чому Promodex
За плечима Promodex — 750+ проєктів з 2015 року, серед мобільних — Idram, а також Fuelio та Omio, у розробці яких ми брали участь. У нас власна команда в Києві: дизайнери, мобільні та веб-розробники, тому мобільний застосунок і сайт на React можуть розвиватися узгоджено. Роботу на аутсорс не передаємо, а після релізу продовжуємо підтримувати застосунок.
