Бизнесу не нужно разбираться в языках программирования — нужно описать продукт так, чтобы выбор стал обоснованным: какие функции устройства критичны, нужен ли одинаковый интерфейс на iOS и Android, кто будет поддерживать приложение через несколько лет и есть ли у вас команда, которая уже пишет на React. Если продукт держится на глубокой работе с устройством и платформой, чаще выигрывает нативная разработка; если важнее общий код и единый дизайн — Flutter или React Native. Спорные места проверяют коротким прототипом до решения, а не после.
Содержание
Сначала проверьте, нужно ли приложение из стора
Вопрос «на чём писать» имеет смысл, только если вашим клиентам действительно нужно установленное приложение. Если сценарий укладывается в браузер — каталог, запись, личный кабинет без работы с устройством, — стоит сначала сравнить мобильное приложение с PWA и адаптивным веб-приложением. Этому посвящён отдельный материал.
Дальше в материале предполагается, что приложение из стора нужно: например, ради push-уведомлений, работы без сети, камеры, геолокации в фоне или присутствия в магазине приложений как канала продаж.
Три варианта простыми словами
Нативная разработка
- Как устроен
- Два отдельных приложения: Kotlin для Android и Swift для iOS
- Сильная сторона для бизнеса
- Полный и ранний доступ к возможностям платформы, поведение «как у системы»
- Цена решения
- Два кода, две компетенции, каждую функцию делают дважды
Flutter
- Как устроен
- Один код на Dart; интерфейс рисует собственный движок Flutter, а не системные элементы
- Сильная сторона для бизнеса
- Единый дизайн на всех платформах и версиях ОС, один код интерфейса
- Цена решения
- Нужны специалисты по Dart; системные элементы интерфейса воспроизводятся, а не используются напрямую
React Native
- Как устроен
- Один код на TypeScript в модели React; на экране — настоящие нативные компоненты
- Сильная сторона для бизнеса
- Можно использовать опыт веб-команды на React и общий код с веб-продуктом
- Цена решения
- Зависимость от экосистемы библиотек; часть функций всё равно требует нативного кода
Все три варианта зрелые. В React Native начиная с версии 0.76 по умолчанию включена новая архитектура: вместо асинхронного «моста» между JavaScript и нативным кодом используется интерфейс JSI. Flutter, по собственной документации, реализует каждый элемент интерфейса сам и не зависит от системных библиотек виджетов — поэтому приложение выглядит одинаково на разных версиях ОС.
Есть и промежуточный путь — Kotlin Multiplatform: общую бизнес-логику пишут один раз, а интерфейс можно оставить нативным на каждой платформе или тоже сделать общим через Compose Multiplatform. Это вариант для команды, которая уже сильна в Kotlin и хочет сохранить нативный интерфейс.
Шесть вопросов о продукте, которые решают выбор
Какие функции устройства критичны
Камера, Bluetooth-устройства, NFC, геолокация в фоне, виджеты, часы, встроенные платежи. Кроссплатформенные фреймворки обращаются к таким функциям через нативный код — во Flutter это platform channels, в React Native — нативные модули. Чем больше таких мест, тем больше нативного кода появится в «кроссплатформенном» проекте и тем меньше выигрыш от общего кода.
Каким должен быть интерфейс
Если важен узнаваемый фирменный дизайн, одинаковый на всех телефонах, — это аргумент в пользу Flutter. Если пользователи ждут привычного поведения своей платформы, сильнее натив и React Native с системными компонентами.
Кто будет поддерживать приложение
Приложение живёт годами, и его будет развивать не обязательно тот, кто написал первую версию. Проверьте сами, специалистов какого профиля проще найти в вашем городе и формате работы: откройте вакансии и резюме, а не рейтинги популярности. Если у вас уже есть веб-команда на React и TypeScript, React Native позволяет опереться на её опыт.
Как часто нужно выпускать обновления
В React Native с Expo часть изменений (JavaScript, стили, изображения) можно доставлять обновлением «по воздуху» через EAS Update. Изменения нативного кода, разрешений и версии SDK всё равно требуют новой сборки, а обновления обязаны соблюдать правила магазинов приложений.
Готовы ли вы к обязательным обновлениям платформ
Сторы регулярно повышают требования. Например, с 31 августа 2026 года новые приложения и обновления в Google Play должны быть нацелены на Android 16 (API 36) или выше. Это значит, что бюджет на поддержку нужен при любом стеке — «сделать и забыть» не получится.
Какие данные хранит приложение
Если приложение работает с платежами, медицинскими или персональными данными, требования к хранению на устройстве, сетевому обмену и аутентификации стоит сформулировать заранее. Ориентиром служит OWASP MASVS — стандарт требований к безопасности мобильных приложений с группами STORAGE, NETWORK, AUTH, PRIVACY и другими.
Компромиссы, о которых редко говорят на продаже
Как это звучит в предложении
- «Один код — значит, вдвое дешевле»
- «Натив — всегда быстрее и лучше»
- «Фреймворк умеет всё»
- «Обновления — без стора»
Что проверить на деле
- Тестирование, публикация и ревью всё равно идут на двух платформах, а платформенные особенности приходится учитывать отдельно
- Натив даёт полный доступ к платформе, но требует двух кодовых баз и двух компетенций; для типичных экранов разница для пользователя может быть незаметна
- Сторонние плагины для редких функций могут быть незрелыми — проверьте именно ваши функции
- Обновлением по воздуху меняется только часть приложения, и правила сторов продолжают действовать
Есть и долгосрочный компромисс: кроссплатформенный фреймворк — ещё один слой между вашим продуктом и платформой. Его обновления — регулярная работа, которую нужно планировать так же, как обновления самих iOS и Android. Нативное приложение избавлено от этого слоя, но каждая новая функция обходится дважды.
Правильный выбор — не самый модный, а тот, который вы сможете поддерживать после ухода первой команды.
Порядок принятия решения
Список функций
Перечислите функции приложения и отметьте каждую: «критично для запуска» или «желательно позже». Отдельно выделите функции, завязанные на устройство.
Карта рисков
Для критичных функций выясните, есть ли зрелая поддержка в каждом из вариантов. Функции без готового решения — главные кандидаты на нативный код.
Прототип спорной части
Если сомнения остались, сделайте короткий технический прототип самой рискованной функции на выбранном стеке. Это дешевле, чем обнаружить ограничение после половины проекта.
Письменное решение
Зафиксируйте выбор, причины, отвергнутые варианты и условие, при котором решение стоит пересмотреть: например, появление функции, которую стек не поддерживает.
Критерии приёмки
Пропишите проверку на реальных устройствах обеих платформ и публикацию в оба стора как часть приёмки, а не как «потом».
Объём работ зависит от переменных, которые вы собрали на этих шагах: число экранов и сценариев, количество функций с нативным кодом, интеграции с вашими системами, наличие готового backend и API, число платформ на старте и план поддержки. Стоимость определяется после брифа и согласования объёма — ни один из стеков сам по себе не делает проект дешёвым или дорогим.
Вопросы подрядчику и следующий шаг
- Почему этот стек подходит именно нашему продукту — какие из наших функций повлияли на выбор?
- Какие функции потребуют нативного кода и кто в команде будет его писать?
- Что произойдёт, когда выйдет новая версия iOS или Android, и входит ли это в поддержку?
- Какие изменения можно выпускать без стора, а какие потребуют новой сборки и ревью?
- На кого будут оформлены аккаунты разработчика и ключи подписи приложения?
- Как будет проходить тестирование на реальных устройствах обеих платформ?
- Как передаётся код и что нужно, чтобы приложение могла продолжить другая команда?
Ограничения: материал описывает выбор на уровне продукта и не заменяет проверку конкретных библиотек под ваши функции. Требования сторов и версии фреймворков меняются — сверяйте их с официальной документацией на дату решения.
