Мобильная разработка: нативно, React Native или Flutter

Прежде чем сравнивать фреймворки, стоит проверить, нужно ли вообще устанавливаемое приложение. MDN определяет PWA (progressive web app) как приложение на веб-технологиях, которое работает на разных платформах из одной кодовой базы, устанавливается на устройство, умеет работать офлайн и интегрироваться с системой. Если сценарий укладывается в возможности браузера, PWA проще в выпуске и обновлении. Бизнес-сторону этого выбора — модерацию, каналы привлечения, этапность — мы разобрали в статье «PWA или мобильное приложение»; здесь — инженерный угол: что именно меняется в коде, инструментах и команде.

Инженерные признаки того, что веба будет мало: приложение должно жить в App Store и Google Play; нужны API, к которым браузер не даёт доступа или даёт с ограничениями на конкретной платформе; важна работа в фоне, тесная интеграция с системой (виджеты, общий доступ, биометрия, платежи платформы); нужен плавный сложный интерфейс с жестами и анимацией на слабых устройствах.

Нативное приложение пишется на основном языке платформы её же инструментами. Для Android это Kotlin: Google с 2019 года развивает платформу по принципу Kotlin-first и рекомендует начинать новые приложения с него, сохраняя поддержку Java. Интерфейс строят на Jetpack Compose — документация Android называет его рекомендуемым современным набором инструментов для нативного UI: вы описываете интерфейс, а при изменении состояния Compose обновляет его сам. Среда — Android Studio.

Для iOS это Swift и SwiftUI — декларативный фреймворк Apple для всех её платформ, с живым предпросмотром в Xcode. SwiftUI можно внедрять постепенно рядом с более старым UIKit. Xcode — набор инструментов Apple для разработки, тестирования и распространения приложений, и работает он на Mac.

Промежуточный вариант — Kotlin Multiplatform. Google официально поддерживает его для общего кода бизнес-логики между Android и iOS, а Compose Multiplatform от JetBrains позволяет при желании разделять и интерфейс. Это подход для команды, которая уже пишет на Kotlin и хочет перестать дублировать логику, не отказываясь от нативного UI.

React Native позволяет писать мобильное приложение на JavaScript или TypeScript в той же модели, что и React: компоненты, props, состояние, хуки. Принципиальное отличие от веба — нет DOM и HTML. Вместо <div> и <p> используются компоненты View и Text, и во время работы React Native создаёт для них настоящие представления Android и iOS. Это не сайт в обёртке: на экране — системные элементы интерфейса.

С версии 0.76 в React Native по умолчанию включена новая архитектура: асинхронный «мост» между JavaScript и нативным кодом заменён на JSI (JavaScript Interface) — прямые вызовы без сериализации данных. Она же поддерживает конкурентные возможности React 18 и новее. Документация честно оговаривает, что сама по себе новая архитектура не гарантирует ускорения: выигрыш зависит от кода приложения.

Сама команда React Native рекомендует начинать новые приложения с фреймворка, и в первую очередь называет Expo: он даёт файловую маршрутизацию, стандартную библиотеку нативных модулей и плагины, которые меняют нативный код без ручного редактирования проектов Android и iOS. На момент проверки актуален Expo SDK 57 — он построен на React Native 0.86 и React 19.2.

Flutter решает ту же задачу «один код — две платформы» иначе. Вместо системных элементов интерфейса он рисует всё сам: у Flutter собственные реализации каждого элемента управления на Dart, включая аналоги переключателей iOS и Android. Отрисовкой занимается движок на C++ с рендерером Impeller, который поставляется вместе с приложением; на iOS Impeller — единственный поддерживаемый рендерер, на Android он включён по умолчанию с API 29.

Код пишется на Dart. Во время разработки приложение работает в виртуальной машине с горячей перезагрузкой (hot reload) — изменения видны без полной пересборки и без потери состояния. Для релиза Flutter компилирует код напрямую в машинные инструкции. К API платформы Flutter обращается через platform channels — канал сообщений между Dart и нативным кодом — или через FFI для C-библиотек.

Производительность в таблицу намеренно не вынесена одной цифрой: все три подхода в итоге исполняют на устройстве скомпилированный нативный код движка, а узкие места обычно в конкретном приложении — длинные списки, тяжёлые изображения, лишние перерисовки. Сравнивать стоит прототип вашего самого тяжёлого экрана на реальном среднем телефоне, а не общие бенчмарки.

Как бы ни было написано приложение, на выходе это пакет для Android и пакет для iOS, которые подписываются ключами разработчика и проходят проверку магазинов. Здесь различия между стеками меньше, чем кажется.

Ниже — порядок вопросов, который мы используем как отправную точку. Это не правило, а способ не пропустить важное: ответ «да» на ранний вопрос обычно весит больше, чем все следующие.

Дальше по траектории: первое приложение на React Native и Expo — от create-expo-app до экрана со стилями, затем навигация в Expo Router. Для Flutter — отдельный урок о Dart и виджетах.