PWA, Swift та Kotlin або Expo: вибір архітектури мобільного додатку

Архітектуру, яку ви обираєте для мобільного продукту, важко змінити пізніше. Якщо рішення буде неправильним, наступний рік піде на боротьбу з платформою замість розробки функцій: конфлікти залежностей після оновлення фреймворку, відсутність API обладнання чи розбіжності між двома командами, які працюють над нативним кодом. У цьому посібнику порівнюються три найпоширеніші варіанти початку розробки – прогресивні веб-додатки, повністю нативні додатки, написані на Swift та Kotlin, та Expo на основі React Native, – а також наведені конкретні критерії для вибору між ними, чи то під час створення MVP, чи під час планування наступного етапу розвитку існуючого додатку.

Як порівнюються три варіанти

Перш ніж детально розглянути кожен варіант, ось у чому полягають їхні відмінності за критеріями, які зазвичай визначають кінцевий результат.

База коду

• PWA: одна веб-база коду, створена за допомогою HTML, CSS та JavaScript.

Нативний код: окрема база коду для кожної платформи — зазвичай Swift для iOS та Kotlin для Android.

Expo: єдина база коду на JavaScript або TypeScript, яка використовується як для iOS, так і для Android.

Присутність у магазинах додатків

• PWA: існує у вебі. Вказівка в магазині є необов’язковою та ґрунтується на обгортках чи специфічних рішеннях для кожної платформи.
• Нативний код та Expo: розповсюджуються безпосередньо через Apple App Store та Google Play.

Продуктивність

• Нативний код: максимальна продуктивність. Плавні анімації з повною частотою оновлення екрана, до 120 кадрів на секунду на сучасних екранах, без перешкод від шару абстракції.
• Expo: для більшості інтерфейсів майже такий самий, як нативний. React Native відображає справжні нативні елементи, а його нова архітектура замінює старий асинхронний місток прямими викликами з JavaScript у нативний код через JSI, що усуває давню проблему з обмеженою продуктивністю.
• PWA: обмежений тим, що дозволяє движок браузера, особливо щодо складних анімацій та роботи на фоні.

Доступ до обладнання

• Нативний: усе, що надає платформа.
• Expo: широкий спектр можливостей завдяки Expo SDK, який доповнюється плагінами налаштувань та користувацькими нативними модулями за потреби.
• PWA: основний набір функцій, доступних у веб-версії, таких як камера та геолокація, проте на iOS існують значні обмеження.

Швидкість випуску

• PWA: зміни стають активними відразу після розгортання, без перевірки в магазині.
• Expo: оновлення через мережу (OTA) дозволяють миттєво впроваджувати зміни до JavaScript та ресурсів, тоді як зміни до нативного коду все ще проходять через звичайну перевірку в магазині.
• Native: кожна версія проходить процес перевірки в магазині.

Витрати

• PWA: зазвичай найдешевший варіант для створення та підтримки.
• Expo: помірні витрати для однієї команди.
• Native: найбільш дорогий варіант, оскільки дві бази коду для різних платформ зазвичай вимагають двох спеціалізованих команд.

Прогресивні веб-додатки: підхід, орієнтований на веб

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

Переваги. Між вами та вашими користувачами немає магазину додатків. Будь-хто, у кого є URL, може використовувати додаток та додати його на свій головний екран. Оновлення потрапляють до всіх під час наступного завантаження, а контент може бути індексований пошуковими системами, що забезпечує органічне виявлення, якого рідко досягається через описи в магазинах.

Обмеження. Apple все ще обмежує роботу PWA на iOS. Функція Web Push доступна лише для доданих до головного екрана додатків, а виконання у фоновому режимі суворо обмежене. Web Bluetooth та подібні API апаратного забезпечення взагалі не підтримуються у Safari. Якщо продукт залежить від Bluetooth, постійного фонового відстеження чи глибокої інтеграції з пристроєм, PWA швидко зіткнеться з проблемами. Політика платформи тут змінювалася більше одного разу, тому перевірте поточний стан для ваших цільових версій iOS.

Нативний Swift та Kotlin: максимальний контроль

Розробка нативного додатку означає створення та підтримку двох додатків: одного на Swift для iOS та одного на Kotlin для Android.

Переваги. Нічого не приховується, тому продуктивність та якість відтворення є настільки ж високими, наскільки це дозволяє платформа. Нові API від Apple та Google стають доступними в день їх випуску, без необхідності чекати, поки їх обгорне якась фреймворк-структура. Це ідеальний вибір для складної графіки, реалістичного AR чи VR та інтенсивної обробки даних на фоні.

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

Expo: одна кодова база, результати на рівні нативних програм

Expo — це фреймворк та набір інструментів з відкритим кодом, створений на основі React Native. Він приховує більшу частину складностей створення нативних додатків для iOS та Android, тож один кодовий базис на JavaScript чи TypeScript може генерувати справжні нативні додатки для обох платформ.

Переваги. Розробка відбувається швидко. Expo Application Services (EAS) створює нативні бінарні файли в хмарі, тому у повсякденній роботі рідко потрібно відкривати Xcode чи Android Studio. EAS Update доставляє виправлення через OTA прямо до встановлених додатків. Слід пам’ятати, що оновлення через OTA можуть змінювати JavaScript та ресурси, але не нативний код, і політики магазину все ще визначають, що може бути змінено під час оновлення; нова нативна залежність означає необхідність нової збірки додатку в магазині.

Обмеження. Плагіни конфігурації та API Expo Modules API зробили створення власного нативного коду значно доступнішим, ніж раніше, а версії для розробки дозволяють використовувати будь-яку нативну бібліотеку, а не лише ті, що постачаються з Expo Go. Проте додатки, які потребують драйверів апаратного забезпечення найнижчого рівня чи складного власного коду на C++, все одно вимагають справжньої роботи з нативним кодом, і команді потрібна людина, яка вміє це робити.

Щоб дізнатися більше про міжплатформені опції поза Expo, включаючи Flutter та Kotlin Multiplatform, перегляньте огляд блогу про міжплатформені мобільні фреймворки.

Вибір правильної архітектури

Підбирайте архітектуру відповідно до продукту, а не до улюбленого інструменту команди:

1. Оберіть PWA, коли бюджет обмежений, важлива доступність через пошук, а продукт переважно складається з контенту чи форм: інтернет-магазин, новинний сайт чи панель керування SaaS. Це також розумний спосіб перевірити попит перед тим, як інвестувати у створення додатків для магазинів.
2. Оберіть Expo для стартапу, MVP чи продакшн-додатку, який потребує швидкого доступу до App Store та Google Play за допомогою одної команди. Цей варіант підходить для більшості додатків для бізнесу та споживачів.
3. Оберіть нативний додаток для високоякісних ігор, продуктів з великою кількістю обладнання, таких як пристрої для фітнесу, що постійно синхронізуються через Bluetooth, або будь-якого додатку, де справжніми вимогами є інтерфейси з частотою оновлення 120 кадрів на секунду та відсутність ризиків абстракції.

Ці варіанти не є незмінними рішеннями. PWA може існувати разом із додатком з магазину, а додаток Expo може містити нативні модулі, написані на Swift та Kotlin, тому часто існує гібридний підхід, коли одна частина продукту виходить за межі стандартних можливостей.

Підсумок

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