В 2026 году выбор платформы для разработки мобильного приложения стал сложнее: появился Flutter 4.0, React Native перешёл на New Architecture, Apple добавила Swift 6 с актором конкурренси. Разбираем когда что выбирать.
Сразу оговорка: выбор технологии почти никогда не определяет успех продукта. Он определяет стоимость изменений — насколько дорого будет добавлять функции через год. Поэтому решение принимают не по моде, а по трём вопросам: какие нативные возможности нужны, кто будет поддерживать код, и сколько платформ вы реально готовы содержать.
Нативная разработка: Swift и Kotlin
Плюсы: максимальная производительность, доступ ко всем системным API, лучший UX. Минусы: 2 кодовые базы, выше стоимость на 40%.
Когда выбирать: финтех, игры, приложения с тяжёлой графикой, продукты для App Store Editor's Choice.
Ещё один аргумент за нативную разработку — скорость доступа к новым возможностям системы. Виджеты, живые активности, интеграции с системными сервисами, свежие API камеры и работы с фоновыми задачами появляются сначала в нативных SDK, а обёртки для кроссплатформы выходят с задержкой в несколько месяцев. Если продукт живёт за счёт таких функций, ждать обёртку дороже, чем писать нативно.
Обратная сторона — поддержка. Две кодовые базы означают двойной объём правок при каждом изменении бизнес-логики и двойной регресс при тестировании. Это заметно не на старте, а на втором году жизни продукта.
Flutter
Плюсы: один код для iOS и Android, отличный UI, экономия 40% бюджета. Минусы: размер приложения больше, нативные интеграции через каналы.
Когда выбирать: e-commerce, маркетплейсы, корпоративные приложения, MVP.
Важно понимать, на чём именно экономия. Flutter сокращает мобильную часть работ, но не трогает backend, дизайн и тестирование. Если в проекте половина бюджета — это серверная логика и интеграции с 1С и платёжным шлюзом, общая экономия окажется не 40%, а порядка 15–20%.
Второй нюанс — нативные плагины. Всё, что касается платёжных SDK, биометрии, карт, фоновой геолокации и push, живёт в плагинах. Хороший плагин экономит недели, заброшенный — превращается в форк, который вы поддерживаете сами. Перед стартом стоит проверить, когда последний раз обновлялись ключевые плагины проекта.
React Native
Плюсы: команды JavaScript-разработчиков легче найти, экосистема React. Минусы: производительность хуже Flutter, чаще требует нативных модулей.
Когда выбирать: если у вас уже есть веб-приложение на React и нужно быстро запустить мобильную версию.
Реальная выгода здесь не в самом коде UI — переиспользовать вёрстку между вебом и мобильным приложением почти не получается. Выгода в общем слое: типы, модели данных, валидация, клиент API, бизнес-правила. Если этот слой у вас уже написан на TypeScript, React Native даёт ощутимую экономию и, главное, единую команду вместо трёх.
Чего вообще может хватить: веб и Telegram
Отдельный сценарий — когда мобильное приложение вообще не нужно. Если продукт не требует push-уведомлений, работы офлайн и доступа к камере или геолокации, адаптивный сайт решает задачу быстрее и дешевле: создание сайта начинается от 350 000 ₸ против 850 000 ₸ за приложение, и не требует прохождения модерации в сторах.
Второй вариант для Казахстана — Telegram. Аудитория уже в мессенджере, устанавливать ничего не нужно, платёжные сценарии решаются встроенными средствами. Telegram-бот стоит от 220 000 ₸, а Telegram Mini App — от 700 000 ₸ и по возможностям интерфейса близок к обычному приложению. Для сервисов записи, доставки и внутренних инструментов это часто достаточный формат, а полноценное приложение делают уже после проверки спроса.
Как выбрать: практический чек-лист
- Есть ли в продукте функции, требующие свежих системных API (виджеты, фоновая работа, тяжёлая графика)? Если да — нативно.
- Какова доля мобильной части в бюджете? Если меньше половины, экономия на кроссплатформе будет скромной.
- Кто поддерживает код через год — ваша команда или подрядчик? Технологию выбирают под тех, кто будет её вести.
- Нужны ли обе платформы сразу? Иногда честнее выпустить одну и посмотреть на реальное распределение пользователей.
- Проверены ли плагины и SDK для платежей, карт и push под выбранный стек?
Что не зависит от выбранного стека
Есть блок работ, одинаковый для нативной разработки, Flutter и React Native. Это backend и API, схема данных, права доступа, интеграции с учётными системами и платёжным шлюзом, аналитика, обработка ошибок и мониторинг. Обычно это от трети до половины бюджета проекта, и никакой выбор мобильной технологии эту часть не сокращает.
Сюда же относится релизная рутина: сертификаты и профили Apple, ключ подписи Android, описания для сторов, скриншоты под все размеры экранов, политика конфиденциальности, ответы на замечания ревью. Эти работы одинаковы везде, и их стоит закладывать в срок отдельной строкой, а не «в конце разработки».
Ошибки, которые дорого стоят
- Выбирать технологию до того, как описан продукт. Сначала сценарии и интеграции, потом стек.
- Считать, что кроссплатформа делит смету пополам. Она сокращает только часть работ.
- Строить на плагине, который поддерживает один человек и не обновлялся год.
- Игнорировать различия платформ в UI. Приложение, где на Android всё выглядит как на iOS, воспринимается чужим.
- Не заложить время на релизные особенности: отдельные требования App Store и Google Play не зависят от выбранного стека.
Что используем в ZoomApps
Flutter — для 60% проектов. Нативные iOS и Android — для финтеха, игр, премиум-проектов. React Native — по запросу клиента.
Игры — отдельная история: там выбор идёт не между Flutter и React Native, а между игровыми движками и нативной графикой, и считается это иначе — разработка игр начинается от 1 200 000 ₸.
Практический вывод: составьте список функций, которым нужен прямой доступ к системе, и оцените долю мобильной части в общем бюджете. Если функций из первого списка почти нет, а мобильная часть велика — берите Flutter. Если продукт держится на системных возможностях или это игра — нативная разработка. React Native оправдан там, где уже есть команда и кодовая база на TypeScript.