Нативная или кроссплатформенная разработка: что выбрать бизнесу в 2026

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

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

Короткий ответ такой. Для большинства бизнес-приложений кроссплатформа на Flutter — разумный выбор по умолчанию: одна кодовая база вместо двух даёт экономию 30–45% бюджета и сокращает срок в полтора-два раза. Нативная разработка на Swift и Kotlin остаётся обязательной там, где продукт упирается в железо: игры, тяжёлая графика, дополненная реальность, глубокая работа с камерой, датчиками и Bluetooth. Студии, для которых разработка мобильных приложений для бизнеса — основное направление, обычно формулируют правило так: сначала требования продукта, потом инструмент, а не наоборот.

Что такое натив и кроссплатформа на пальцах

У мобильного приложения две целевые платформы: iOS и Android. Они устроены по-разному, говорят на разных языках и публикуются в разных магазинах. Вопрос выбора — это вопрос о том, как вы закроете обе.

Нативная разработка — два отдельных приложения. Для iPhone на Swift, для Android на Kotlin. Одинаковые функции, но разный код и, как правило, две команды. Каждая версия обращается к возможностям системы напрямую, без посредников. Любую функцию нужно делать дважды, любую ошибку — искать в двух местах.

Кроссплатформенная разработка — один код, который собирается в два приложения. Зрелых инструментов сегодня два: Flutter от Google и React Native. Команда пишет экраны, логику и интеграции один раз, а платформенные различия закрывает точечно.

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

Сколько это стоит

Возьмём один продукт — торговое приложение под iOS и Android со средним набором функций.

Параметр

Натив: Swift + Kotlin

Flutter

Стоимость первого релиза

6–8 млн ₽

3,5–5 млн ₽

Срок

6–8 месяцев

4–5 месяцев

Команда

Две группы разработчиков

Одна команда

Стоимость поддержки

Два процесса релизов

На 30–40% ниже

Производительность

Максимальная

Близка к нативной

Доступ к системным API

Полный из коробки

Через плагины, часть с задержкой

Тяжёлая графика и AR

Полная поддержка

Ограниченно

Веб и десктоп из той же базы

Нет

Да

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

Пять мифов, которые мешают выбирать

«Кроссплатформа тормозит». Миф родился во времена гибридных приложений первого поколения — по сути сайтов в оболочке. Современный Flutter компилируется в машинный код и для типового бизнес-приложения работает неотличимо от натива. Тормозит не технология, а плохая архитектура: медленное приложение прекрасно пишется и нативно.

«На кроссплатформе нельзя сделать нативные функции». Можно: виджеты, биометрия, пуши, фоновая геолокация, работа с камерой. Нюанс в другом: когда Apple или Google выпускают новую системную возможность, поддержка в плагинах появляется с задержкой в недели или месяцы.

«Натив — это качество, кроссплатформа — дёшево и сердито». Качество определяется командой и процессами, а не языком. Плохой натив хуже хорошего Flutter, и обратное тоже верно.

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

«Потом всё равно придётся переписывать на натив». На практике переписывают в обратную сторону — с двух разошедшихся нативных баз на единую. За пару лет раздельной разработки версии для iOS и Android расходятся по функциональности, и синхронизировать их дороже, чем собрать заново.

Когда кроссплатформа — выбор по умолчанию

• Проект сразу под две платформы — самый частый случай

• Типовой массовый продукт: магазин, доставка, запись на услуги, программа лояльности, личный кабинет

• Минимальный продукт, где важно быстро проверить гипотезу

• Несколько продуктов на одной команде — например, сеть с несколькими брендами

• Ограниченный бюджет при необходимости покрыть обе платформы

• Нужны ещё веб-версия или десктоп из той же кодовой базы

Отдельный аргумент для первого приложения: пока гипотеза не проверена, платить дважды за продукт, о котором вы ещё не знаете, нужен ли он рынку, — плохая ставка.

Когда нужен только натив

• Игры и приложения с тяжёлой графикой

• Дополненная реальность: ARKit и ARCore пока удобнее использовать напрямую

• Обработка видео и звука в реальном времени

• Глубокая работа с железом: специфичные датчики, Bluetooth-протоколы, нестандартные сценарии с NFC

• Приложения, которым нужны системные возможности в день их выхода

• Экстремальные требования к производительности и энергопотреблению — например, приложение курьера, которое сутки держит геотрекинг

Показательный случай — VPN-сервис, где нужны системные API для туннелирования, kill switch и корректная работа в фоне на обеих платформах. Здесь натив не предпочтение, а необходимость: прослойка добавляет и риск отклонения на модерации, и лишние точки отказа.

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

Kotlin Multiplatform: третий путь

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

Кому не подходит: тем, кто рассчитывает на максимальную экономию. KMP не убирает потребность в двух интерфейсных разработчиках, поэтому экономит заметно меньше, чем Flutter.

Гибрид: Flutter с нативными модулями

Реальные проекты редко бывают чистыми. Рабочая схема — Flutter как основа плюс нативные модули там, где без них никак: сканер документов, специфичная работа с камерой, интеграция с корпоративной библиотекой, существующей только под Android.

Это нормальная архитектура, а не костыль. Важно определить границу на этапе проектирования, а не в середине разработки: каждая нативная вставка возвращает часть двойной работы. Один-два модуля — норма. Когда их становится больше четырёх, экономия кроссплатформы съедается, и честнее сразу выбрать натив.

А может, хватит PWA

Вариант, который стоит рассмотреть до выбора между нативом и кроссплатформой, — вообще не делать приложение. Progressive Web App ставится на главный экран, работает офлайн и умеет присылать уведомления, а стоит в два-три раза дешевле нативной разработки.

Когда достаточно: информационные сервисы, простой каталог, B2B-кабинет, продукт, к которому пользователь обращается редко. Когда не хватит: нужны присутствие в магазинах, полноценные платежи, глубокий доступ к возможностям устройства или регулярный возврат пользователя через push на iOS, где поддержка ограничена.

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

Что будет через два года

Выбор стека влияет не только на первый релиз.

Поддержка. Одна кодовая база — один цикл релизов, одна регрессия, один набор автотестов. На дистанции это заметнее, чем экономия на старте. В нативе каждое изменение проходит два цикла, и со временем команда начинает экономить: «выпустим пока на Android, iOS потом». Так появляются рассинхронизированные версии, где пользователи одной платформы видят функции, которых нет у других.

Найм и устойчивость команды. Из нативного проекта уходит iOS-разработчик — половина продукта замирает до замены. В кроссплатформенном знания не делятся по платформам, команда взаимозаменяема. И если вы планируете со временем забрать разработку в штат, разница между «нанять одного» и «нанять двоих» часто решает, состоится ли внутренняя команда вообще.

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

Алгоритм выбора: шесть вопросов

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

2. Есть ли тяжёлая графика, AR или обработка медиа в реальном времени? Да — натив.

3. Требуются ли системные возможности в день их выхода? Да — натив.

4. Есть ли уже нативная команда и живые приложения? Да — рассмотрите Kotlin Multiplatform.

5. Планируете веб-версию или несколько брендовых приложений на одной базе? Да — Flutter.

6. Во всех остальных случаях — Flutter, и заранее определите, какие два-три модуля придётся сделать нативно.

Типовые развилки на примерах

Продукт

Подход

Почему

Доставка еды с корзиной, оплатой и push

Flutter

Типовые сценарии, обе платформы, экономия без потерь

Компаньон для медицинского прибора по Bluetooth

Натив или гибрид с нативным ядром

Постоянная работа с железом и фоновыми процессами

Маркетплейс услуг с чатом и отзывами, первая версия

Flutter

Гипотеза не проверена, важна скорость выхода

Банк, строящий бренд на новых системных функциях

Натив

Доступ к возможностям ОС в день релиза

Внутреннее приложение на корпоративных устройствах

Flutter, иногда под одну платформу

Парк устройств известен, аудитория закрытая

VPN с системным туннелем и kill switch

Натив

Системные API и риск отклонения на модерации

Чего не должно быть в основе решения

• «Так сделал конкурент» — у него другой бюджет, команда и история продукта

• «Подрядчику так удобнее» — без объяснения, почему это удобно и вам

• «Наш разработчик любит эту технологию» — личные предпочтения не масштабируются на бизнес-план

• «Прочитали, что технология умирает» — обе экосистемы развиваются годами

Чек-лист вопросов подрядчику

• Почему вы предлагаете именно этот стек для нашей задачи?

• В каких случаях вы предложили бы другой подход?

• Какие функции из нашего списка потребуют нативного кода и сколько его будет?

• Кто в команде будет их писать?

• Покажите два-три живых приложения на этом стеке, которые можно скачать

• Что будет с проектом, если ключевой разработчик уйдёт?

• Кому принадлежат код, репозиторий, аккаунты магазинов и ключи подписи?

• Что получит другая команда, если мы решим сменить подрядчика?

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

Частые вопросы

Что дешевле — натив или Flutter?

Flutter, если платформы две: экономия 30–45% на разработке и 30–40% на поддержке. Если платформа одна, разница почти исчезает.

Заметит ли пользователь разницу?

В типовом бизнес-приложении — нет. В игре, приложении с дополненной реальностью или сложной анимацией — да.

Можно ли перевести существующее нативное приложение на Flutter?

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

React Native или Flutter?

В российских коммерческих проектах чаще выбирают Flutter: больше зрелых плагинов, предсказуемее рендеринг, проще найти команду. React Native логичен, если у вас уже есть сильные JavaScript-разработчики.

Пройдёт ли кроссплатформенное приложение модерацию Apple?

Да, если оно не нарушает правила магазина. Отклоняют за содержание, права, приватность и ошибки, а не за фреймворк.

Подходит ли кроссплатформа для приложений с персональными данными?

Да. Требования закона касаются того, где и как хранятся данные, а не того, на чём написан клиент.

Можно ли выпустить сначала одну платформу, а вторую потом?

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