Flutter, React Native или натив: на чём заказать мобильное приложение
Вопрос «на чём писать мобильное приложение» заказчик обычно слышит в пересказе: одна студия говорит «только нативное приложение», другая советует кроссплатформенное приложение на Flutter, третья хвалит React Native. Каждая продаёт то, что умеет. Между тем от технологии зависят бюджет на старте, стоимость каждой новой функции, скорость найма разработчиков и то, придётся ли через три года переписывать продукт с нуля.
Ниже — сравнение пяти подходов глазами владельца бизнеса: нативная разработка на Swift и Kotlin, Flutter, React Native, Kotlin Multiplatform и PWA. Что изменилось в 2026 году, когда что выбирать, как считать реальную экономию кроссплатформы и что спросить у подрядчика, чтобы понять, выбрал ли он технологию под вашу задачу или под свою команду. Этапы создания приложения и публикацию в сторах мы разобрали отдельно в статье о том, как создать мобильное приложение, здесь только о выборе стека.
Что такое нативное и кроссплатформенное приложение
Нативное приложение — это программа, написанная на «родном» языке и официальными инструментами конкретной операционной системы: для iPhone — на Swift в Xcode, для Android — на Kotlin в Android Studio. Оно напрямую работает с камерой, геолокацией, платежами и другими функциями устройства, а новые возможности iOS и Android получает сразу после их выхода. Обратная сторона — под две платформы нужны два отдельных приложения со своим кодом.
Кроссплатформенное приложение пишут один раз и собирают сразу под iOS и Android: большая часть кода общая, платформенные детали дописывают отдельно. В 2026 году для этого используют три зрелые технологии: Flutter от Google (язык Dart), React Native (JavaScript или TypeScript) и Kotlin Multiplatform от JetBrains (Kotlin). Пользователь разницы не видит: оба варианта скачиваются из App Store, Google Play или RuStore и работают как обычное приложение. Не стоит путать кроссплатформу с веб-обёрткой, где внутри приложения просто открывается сайт, — такие решения работают хуже и чаще получают отказ на модерации.
Пять подходов к мобильной разработке
На чём делают мобильные приложения в 2026 году? Рабочих вариантов пять, и отличаются они не языком, а тем, сколько кода пишется один раз на обе платформы.
- Нативная разработка. Два отдельных приложения: под iOS на Swift (интерфейс на SwiftUI), под Android на Kotlin (Jetpack Compose). Официальные инструменты Apple и Google, полный доступ ко всем возможностям системы, но две кодовые базы и, как правило, две команды.
- Flutter. Фреймворк Google на языке Dart. Один код на iOS и Android, интерфейс рисует собственный движок, поэтому приложение выглядит одинаково на всех устройствах. Код компилируется в машинный, а не интерпретируется.
- React Native. Фреймворк на JavaScript/TypeScript. Один код на обе платформы, но интерфейс собирается из системных элементов iOS и Android. Главный плюс — общий язык и часть кода с веб-проектом на React.
- Kotlin Multiplatform (KMP). Общая бизнес-логика на Kotlin (сеть, данные, расчёты), а интерфейс — на выбор: нативный под каждую платформу или общий на Compose Multiplatform. Подход «делим код, где это выгодно».
- PWA. Веб-приложение, которое устанавливается на экран телефона, работает офлайн и умеет отправлять push-уведомления. Не требует магазинов приложений, но ограничено возможностями браузера.
Что изменилось в 2026 году: актуальное состояние технологий
Многие статьи о выборе стека пересказывают аргументы пятилетней давности: «React Native тормозит из-за моста», «Flutter дёргается при первом запуске анимаций», «KMP — эксперимент». Сейчас это уже не так.
Flutter: Impeller вместо Skia
Flutter перешёл на собственный графический движок Impeller: на iOS он единственный, на Android включён по умолчанию для современных устройств. Шейдеры компилируются заранее, поэтому исчезли характерные подтормаживания при первом показе анимаций, на которые жаловались раньше. Из одной кодовой базы собираются iOS, Android, веб и десктоп, а для российского рынка важно, что компания «Открытая мобильная платформа» развивает собственный порт Flutter для ОС Аврора (в официальную сборку Flutter он не входит).
React Native: только New Architecture
Новая архитектура (рендерер Fabric, TurboModules, прямой вызов нативного кода через JSI вместо асинхронного «моста») стала архитектурой по умолчанию в версии 0.76, а с версии 0.82 (октябрь 2025) — единственной: отключить её уже нельзя. Для заказчика вывод двойной. Производительность новых проектов заметно выросла. Но старые приложения на React Native, которые годами не обновлялись, теперь требуют отдельной миграции, а часть устаревших сторонних библиотек её не переживёт.
Kotlin Multiplatform и Compose Multiplatform: стабильны
Общая логика на KMP имеет статус Stable с конца 2023 года, Google официально поддерживает этот подход для Android. Общий интерфейс Compose Multiplatform для iOS вышел в стабильный статус в мае 2025 года (версия 1.8.0). Иначе говоря, KMP перестал быть экспериментом и стал полноценным вариантом для продакшна, хотя готовых библиотек и специалистов у него пока меньше, чем у Flutter и React Native.
Натив: SwiftUI и Jetpack Compose
Нативная разработка тоже ускорилась: декларативные SwiftUI и Jetpack Compose сократили объём кода интерфейса. Но главный недостаток остался — каждую функцию приходится писать и тестировать дважды.
Flutter vs React Native vs натив vs KMP: сравнительная таблица
Сравнение по критериям, которые важны заказчику, а не разработчику. Оценки относительные, для типового бизнес-приложения: каталог, личный кабинет, оплата, push-уведомления, интеграция с CRM или 1С.
| Критерий | Натив (Swift + Kotlin) | Flutter | React Native | KMP |
|---|---|---|---|---|
| Скорость разработки | Самая низкая: всё дважды | Высокая | Высокая | Средняя: интерфейс часто пишется дважды |
| Стоимость на две платформы | Базовая (100%) | Экономия до 40% | Экономия до 40% | Меньше, чем у Flutter и RN: общая в основном логика; больше с общим UI |
| Производительность | Максимальная | Близка к нативной | Близка к нативной после New Architecture | Нативная при нативном UI |
| Доступ к функциям устройства | Полный и сразу после выхода новой ОС | Через плагины; редкое — нативным кодом | Через модули; редкое — нативным кодом | Полный: платформенный код пишется напрямую |
| Внешний вид | Родной для каждой ОС | Одинаковый на iOS и Android | Близок к системному | Родной или общий — на выбор |
| Найм разработчиков | Нужны два профиля | Специалистов меньше, но один закрывает обе ОС | Проще всего: большой рынок JS/React | Мало специалистов, ищут среди Android-разработчиков |
| Долгосрочная поддержка | Предсказуемая, но двойная | Предсказуемая, одна кодовая база | Зависит от качества сторонних библиотек | Предсказуемая, но экосистема моложе |
| Главный риск | Бюджет и расхождение версий | Нужна платформенная фича без готового плагина | Обновления ломают зависимости | Дефицит кадров и библиотек |
PWA в таблицу не включён намеренно: это другой класс решения. Приложение без публикации в App Store, Google Play и RuStore, дешевле всех вариантов, но с жёсткими ограничениями. Например, Safari на iPhone не поддерживает Web Bluetooth, а push-уведомления на iOS работают только после ручной установки PWA на домашний экран (с iOS 16.4). Подробно о том, когда хватает веб-версии, — в статье «Мобильное приложение или мобильная версия сайта».
React Native или Flutter: что выбрать бизнесу
Это самый частый спор, и ответ зависит не от «какой фреймворк лучше», а от того, что у вас уже есть.
Flutter выгоднее, когда вы делаете новый продукт с нуля, нужен фирменный дизайн с анимациями, важно одинаковое поведение на iOS и Android, а в перспективе нужны веб-версия или ОС Аврора из той же кодовой базы. Интерфейс не зависит от версии системы, поэтому на старых Android-смартфонах и новых iPhone приложение выглядит и ведёт себя одинаково, а тестирование проще. Типовой состав работ и сроки такого проекта описаны на странице Flutter-разработки.
React Native выгоднее, когда у компании уже есть веб-продукт на React и своя фронтенд-команда: часть логики, типов и даже компонентов можно переиспользовать, а разработчиков проще нанять. Второй сценарий — встраивание новых экранов в существующее нативное приложение по частям.
Когда нужна нативная разработка на Swift и Kotlin
Натив оправдан не «для солидности», а при конкретных требованиях. Типичные признаки:
- Тяжёлая графика и медиа: видеоредакторы, обработка фото в реальном времени, стриминг с низкой задержкой, 3D.
- AR и работа с сенсорами: ARKit и ARCore, LiDAR, сложные сценарии с камерой.
- Глубокая работа с Bluetooth LE и внешними устройствами: медицинские датчики, фитнес-трекеры, умный дом, оборудование на производстве, где важна стабильная фоновая работа.
- Экосистема платформы: Apple Watch, виджеты, CarPlay и Android Auto, интеграция с системными сервисами.
- Банки и финтех с жёсткими требованиями безопасности, где служба ИБ требует минимума сторонних зависимостей и полного контроля над кодом.
Если приложение нужно только под одну платформу, например внутренний инструмент на Android-терминалах сотрудников, натив тоже часто разумнее: экономить кроссплатформой нечего. Для таких задач есть отдельные направления — разработка приложения под iOS на Swift и под Android на Kotlin.
Промежуточный вариант — Flutter или KMP с нативными модулями: большая часть приложения общая, а критичная часть (работа с BLE-устройством или камерой) пишется нативно. Так делают многие продукты, и это нормальная инженерная практика, а не костыль.
Какую технологию выбрать под задачу: сценарии
| Сценарий | Что обычно выбирают | Почему |
|---|---|---|
| MVP для проверки гипотезы | Flutter или React Native | Быстрый выход сразу на обе платформы, минимальный бюджет |
| Приложение-витрина, каталог, программа лояльности | Flutter; PWA, если не нужны сторы | Типовые экраны, упор на дизайн и скорость запуска |
| Интернет-магазин с оплатой и интеграцией с 1С | Flutter или React Native | Вся сложность на бэкенде, интерфейс типовой |
| Есть веб-продукт на React и своя команда | React Native | Общий язык, переиспользование кода, проще найм |
| Финтех, банк, медиа с тяжёлой графикой | Натив или KMP с нативным UI | Производительность, безопасность, родной UX |
| AR, BLE-устройства, носимая электроника | Натив; кроссплатформа с нативными модулями | Глубокий доступ к железу и фоновой работе |
| Есть нативное Android-приложение, нужно iOS | KMP | Логику переносят, а не пишут заново |
| Внутреннее приложение для сотрудников | Flutter или PWA | Дёшево, быстро, модерация сторов часто не нужна |
Сколько на самом деле экономит кроссплатформа
Цифра «экономия до 40%» верна, но её важно правильно читать. Экономится только клиентская часть: код интерфейса и логики, которые не нужно писать дважды. Остальные статьи бюджета от технологии почти не зависят:
- аналитика, проектирование и дизайн — макеты под iOS и Android всё равно адаптируют;
- бэкенд, админка и интеграции с 1С, CRM, платёжными системами;
- тестирование на реальных устройствах обеих платформ;
- публикация в App Store, Google Play и RuStore и прохождение модерации.
Поэтому на проекте, где половина бюджета уходит на бэкенд и интеграции, итоговая экономия заметно ниже (ориентировочно 15–25%), а на приложении с богатым интерфейсом и простым сервером — приблизиться к 40%. Ещё важнее экономия на дистанции: каждая новая функция и каждое исправление делаются один раз, а релизы на обе платформы выходят одновременно. По нашим ориентирам кроссплатформенный MVP начинается от 400 000 ₽, нативный MVP на одну платформу — от 800 000 ₽, точная цена зависит от числа экранов, ролей и интеграций. Подробный разбор бюджета — в статье о стоимости мобильного приложения.
Миграция с одной технологии на другую
Переход на другой стек — дорогое решение, и полная переписка оправдана не всегда. Основные сценарии:
- Два нативных приложения → Flutter. Частый случай: версии разъехались по функциям, каждая доработка стоит вдвое. Можно переписать приложение целиком или встраивать Flutter-модули в нативное приложение постепенно (режим add-to-app), экран за экраном.
- Нативное Android → KMP. Логику выносят в общий модуль, а iOS-версию собирают поверх неё. Подходит, когда Android-команда сильная и её не хочется терять.
- Старый React Native → актуальная версия или Flutter. Если приложение застряло на старой архитектуре, сначала оценивают стоимость обновления до актуальной версии с New Architecture. Иногда она сопоставима с переходом на Flutter, и тогда сравнивают оба варианта.
- PWA или обёртка сайта → полноценное приложение. Обычно это новая разработка клиентской части, но бэкенд и API сохраняются.
Чтобы оценить миграцию, нужен аудит: объём кода, устаревшие зависимости, покрытие тестами, качество API. От этого зависит, что выгоднее: поддерживать текущий код, рефакторить его или переписывать — подробнее в статье о legacy-коде. Главное правило миграции — не останавливать развитие продукта на полгода: пользователи и бизнес не ждут.
Вопросы подрядчику и типовые ошибки при выборе стека
Какие вопросы задать подрядчику о выборе технологии
Эти вопросы показывают, выбирает ли студия стек под вашу задачу или под свою команду:
- Почему для моего проекта вы предлагаете именно эту технологию и в каком случае посоветовали бы другую?
- Какие функции приложения потребуют нативного кода и заложены ли они в смету?
- Какие сторонние библиотеки и плагины критичны и что будет, если их перестанут поддерживать?
- Как будут работать push-уведомления, платежи и публикация в RuStore?
- Сколько стоит поддержка в год и как часто нужно обновлять приложение под новые версии iOS и Android?
- Если через два года мы захотим сменить подрядчика или нанять свою команду, насколько легко будет найти разработчиков на этот стек?
- Покажите проекты на этой технологии, которые вы поддерживаете дольше года.
Хорошая команда, которая делает разработку мобильных приложений на нескольких стеках, спокойно ответит на все вопросы и назовёт ограничения своей рекомендации. Настораживает, если на любой проект предлагается одна и та же технология без объяснений.
Типовые ошибки при выборе стека
- Выбор по моде или по отзыву знакомого. «У конкурента натив, значит, и нам надо» — без анализа требований.
- Натив «на вырост» для MVP. Двойной бюджет на гипотезу, которая может не подтвердиться. Для проверки спроса кроссплатформы почти всегда достаточно.
- Кроссплатформа для задач, где она упирается в потолок. AR, сложная работа с BLE в фоне, обработка видео — здесь экономия превращается в бесконечные доработки.
- Игнорирование найма. Стек выбирают, не думая, кто будет поддерживать приложение через три года, если студия уйдёт с проекта.
- Экономия на обновлениях. Приложение не обновляли два-три года, фреймворк ушёл вперёд, и простая доработка превращается в миграцию.
- Код и аккаунты у подрядчика. Любая технология бесполезна, если исходники, ключи подписи и аккаунты разработчика в сторах оформлены не на вас.
Чек-лист: как выбрать технологию мобильного приложения
- Определите платформы: iOS и Android, одна из них, нужна ли веб-версия или ОС Аврора.
- Выпишите функции, завязанные на железо: камера, BLE, NFC, AR, фоновая геолокация, носимые устройства.
- Решите, нужно ли присутствие в App Store, Google Play и RuStore или достаточно PWA.
- Оцените, что уже есть: веб на React, нативное приложение, своя команда разработки.
- Для MVP и типового бизнес-приложения по умолчанию рассматривайте Flutter или React Native.
- Для финтеха, тяжёлой графики, AR и глубокой работы с устройствами — натив или KMP с нативными модулями.
- Попросите подрядчика обосновать выбор и указать, какие функции потребуют нативного кода.
- Сравните сметы целиком: бэкенд, дизайн, тестирование, публикация и поддержка на год.
- Проверьте, что исходный код, ключи подписи и аккаунты разработчика будут оформлены на вашу компанию.
Итог: на чём писать мобильное приложение в 2026 году
Для большинства бизнес-приложений — магазинов, сервисов, программ лояльности, личных кабинетов и MVP — разумный выбор по умолчанию: кроссплатформа на Flutter или React Native. Flutter чаще выигрывает в новых продуктах с фирменным дизайном, React Native — там, где уже есть веб на React и своя команда. Нативная разработка оправдана для тяжёлой графики, AR, работы с внешними устройствами и продуктов с жёсткими требованиями безопасности. Kotlin Multiplatform стал стабильным вариантом для команд с сильной Android-экспертизой и для постепенного перехода с натива. PWA подходит, когда сторы не нужны, а функциональность ограничивается возможностями браузера. Решение стоит принимать на этапе аналитики, по списку функций и планам на три-пять лет, а не по тому, какую технологию знает подрядчик.