← Все статьи

Натив, Flutter или React Native: на чём делать мобильное приложение, чтобы не переплатить

Короткий ответ: если приложение нужно и на iOS, и на Android, а в его основе — аккаунты, каталог, заявки, оплаты и уведомления, разумнее всего общий код на Flutter или React Native: одна команда, одна смета и одна линия поддержки. Натив на Swift и Kotlin оправдан, когда продукт упирается в графику, анимацию или возможности устройства. В нашем прайсе базовый вариант — iOS и Android из одного кода на React Native или Flutter, от 200 000 ₽ и от 2 недель.

Про цену и три пути — PWA, кроссплатформа, натив — мы уже писали в статье «Мобильное приложение быстро и недорого». Здесь разберём глубже именно технологии: как они устроены, где у каждой предел и как выбрать, чтобы через год не переписывать приложение. Описания технологий сверены с их официальной документацией на сентябрь 2026 года.

Чем натив, Flutter и React Native отличаются по сути?

Разница в том, кто рисует интерфейс и на каком языке написан код. Натив пишут на родном языке каждой платформы, Flutter рисует экраны собственным движком, а React Native управляет системными элементами из JavaScript.

• Натив. Для iOS — Swift, для Android — Kotlin. Google с конференции Google I/O 2019 года развивает Android по принципу Kotlin-first: новые библиотеки, примеры и документацию проектируют в первую очередь под Kotlin, а современный инструмент интерфейсов Jetpack Compose доступен только на нём. Две платформы — два отдельных приложения.
• Flutter. Код пишут на языке Dart. По документации Flutter, у фреймворка свои реализации всех элементов управления, а не системные; в релизе код компилируется в машинный код, а движок отрисовки Impeller поставляется вместе с приложением.
• React Native. Код пишут на JavaScript или TypeScript с библиотекой React. По документации React Native, во время работы фреймворк создаёт для компонентов соответствующие системные элементы Android и iOS — поэтому кнопки и списки ведут себя как в обычных приложениях платформы.

Для бизнеса из этого следуют три практических вывода: сколько кода придётся поддерживать, как быстро приложение получает новые возможности iOS и Android и каких специалистов искать, если проект когда-нибудь перейдёт к другой команде.

Когда нативное приложение на Swift и Kotlin оправдано?

Натив оправдан, когда главная ценность продукта — в производительности, графике или глубокой работе с устройством, и ради этого вы готовы содержать две кодовые базы.

• Игры и сложная графика. Свои игры для iPhone мы делаем на Swift: так устроены головоломка «Час пик» и аркада «Орбита», в которой вся графика и звук считаются кодом. Подробнее — в статье о разработке мобильной игры.
• Возможности, которые появляются в ОС первыми. Новые функции iOS и Android сначала выходят в родных инструментах платформы. Кроссплатформенному приложению для них нужен готовый модуль или своя нативная вставка.
• Приложение под одну платформу. Если продукт нужен только на iPhone — например, внутренний инструмент для команды на корпоративных устройствах, — выгода общего кода исчезает.

Цена такого выбора — две разработки и две поддержки: каждое изменение экрана делается дважды и тестируется дважды. В нашем прайсе отдельного тарифа на натив нет: его считаем после брифа.

Когда выбрать Flutter?

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

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

Ограничение — обратная сторона того же подхода: если нужен «родной» вид каждой платформы, системные элементы приходится воспроизводить. К функциям устройства Flutter обращается через платформенные каналы — механизм связи кода на Dart с кодом на Swift или Kotlin. Когда готового модуля нет, эту часть пишут нативно.

Когда выбрать React Native?

React Native — естественный выбор, когда у вас уже есть веб-продукт на React или команда, которая знает JavaScript и TypeScript: часть знаний, подходов и кода переносится между сайтом и приложением.

• Уже есть личный кабинет на React. Логику работы с API, проверки форм и типы данных можно переиспользовать, а разработчиков проще найти.
• Нужен системный вид. Компоненты превращаются в настоящие элементы iOS и Android, поэтому приложение ведёт себя привычно для пользователя каждой платформы.
• Готовая инфраструктура. Для новых приложений документация React Native рекомендует использовать фреймворк, например Expo, а не собирать всю инфраструктуру самостоятельно.

Одна оговорка про обновления. Для React Native есть способы доставлять исправления JavaScript-кода без публикации новой версии, но правила Apple от этого не меняются: правило 2.5.2 запрещает скачивать код, который добавляет или меняет функции приложения. Новые функции всё равно выпускаются через проверку App Store.

А если у вас уже есть сайт — может, хватит обёртки?

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

Так сделано наше приложение знакомств Twin: единый код на React, нативные сборки для App Store и Google Play через Capacitor, push-уведомления и чат в реальном времени. Но просто показать сайт внутри приложения нельзя: правило 4.2 App Store требует, чтобы приложение давало функции, контент и интерфейс сверх переупакованного сайта. Если сайт ещё не готов, выбирать стоит между полноценными вариантами выше.

Сколько стоит и что входит в тариф?

Мобильное приложение у нас стоит от 200 000 ₽ и делается от 2 недель — это iOS и Android из одного кода на React Native или Flutter либо PWA. Смету считаем под задачу и фиксируем в договоре до старта; оплата — 50% предоплатой и 50% по акту.

По прайсу в тариф входят:

• до 6–8 экранов: онбординг, аккаунты, основной экран, профиль, настройки;
• регистрация и вход по телефону или email, восстановление пароля;
• push-уведомления (Firebase/APNs) и базовая аналитика;
• оплаты: подписки или разовые платежи через магазины или эквайринг;
• подключение к вашему API или простой бэкенд на нашей стороне;
• иконка, сплэш-экран, светлая и тёмная тема, оформление карточек и публикация в App Store и Google Play.

Отдельно оцениваются сложная бизнес-логика, чаты, карты и видеозвонки, а аккаунты разработчика Apple и Google Play оформляются на вас. Исходный код приложения и бэкенда передаём в ваш репозиторий. Подробности — на странице разработки мобильных приложений.

Как выбрать технологию, чтобы не переделывать приложение через год?

Переделки чаще всего вызывает не сама технология, а решения, которые не приняли на старте. Проверьте пять пунктов до первой строчки кода.

1. Список функций устройства. Камера, геолокация, Bluetooth, работа без сети, виджеты, часы. Для каждой проверяем, есть ли готовый модуль в выбранном фреймворке. Если критичной функции нет, её делают нативной вставкой — это надо заложить в смету сразу.
2. Логика — на сервере. Расчёты, права доступа и данные держим за API, а приложение показывает результат. Тогда смена технологии или появление веб-версии не потребует переписывать бизнес-правила.
3. Платформы на три года вперёд. Если через год понадобится веб-кабинет с той же логикой, это аргумент за React Native и общий язык с веб-версией. Если важен одинаковый фирменный интерфейс везде — за Flutter.
4. Кто будет поддерживать. Код лежит в вашем репозитории, и выбор распространённой технологии упрощает поиск разработчиков, если проект перейдёт к другой команде.
5. Рискованное — первым. Самую сложную функцию стоит проверить прототипом в первые дни, а не в конце проекта.

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

Короткие ответы на частые вопросы

Что дешевле: нативное приложение или Flutter и React Native?

Для приложения, которое нужно и на iOS, и на Android, обычно дешевле общий код на Flutter или React Native: экраны и логику пишут один раз, а не дважды. Натив на Swift и Kotlin означает два отдельных приложения и две линии поддержки.

Чем Flutter отличается от React Native?

Flutter написан на языке Dart и рисует интерфейс своим движком, не используя системные элементы управления. React Native работает на JavaScript и React и во время работы создаёт настоящие системные элементы iOS и Android для каждого компонента.

Когда без нативной разработки не обойтись?

Когда продукт упирается в графику, звук, анимацию или возможности устройства, которых нет в готовых модулях кроссплатформенных фреймворков, — например, в играх. В остальных случаях нативный код можно подключить точечно, не переписывая всё приложение.

Сколько стоит мобильное приложение на React Native или Flutter в Roboweb?

По прайсу Roboweb — от 200 000 ₽ и от 2 недель: iOS и Android из одного кода, до 6–8 экранов, вход, push-уведомления, оплаты и публикация в App Store и Google Play. Точную смету фиксируем в договоре до старта.

Можно ли потом перенести приложение с одной технологии на другую?

Можно, но это фактически новая разработка клиентской части. Чтобы переход был дешевле, бизнес-логику и данные с самого начала держат на сервере за API — тогда переписывать придётся только экраны.

Услуги и кейсы по теме: мобильные приложения · кейс Twin