Если коротко: для большинства бизнес-приложений — каталогов, записи, личных кабинетов, внутренних инструментов — в 2026 году разумно начинать с кроссплатформенной технологии (Flutter, React Native или Kotlin Multiplatform). Нативная разработка оправдана, когда продукт сильно зависит от возможностей устройства, производительности или новейших функций ОС. PWA подходит для проверки спроса и сервисов, которыми пользуются нерегулярно. Ниже — как принять это решение осознанно, а не по вкусам конкретного подрядчика.
Пять подходов коротко
Нативная разработка
Отдельное приложение для каждой платформы на её «родном» стеке: Swift и SwiftUI (или UIKit) для iOS, Kotlin и Jetpack Compose (или View-система) для Android. Приложение напрямую использует системные API, выглядит и ведёт себя так, как ожидают пользователи платформы, и первым получает доступ к новым возможностям ОС. Цена — две кодовые базы и, как правило, две группы разработчиков.
Flutter
Фреймворк от Google на языке Dart. Интерфейс рисуется собственным движком, а не системными компонентами, поэтому приложение выглядит одинаково на всех платформах и хорошо подходит для фирменного дизайна. Один код работает на iOS, Android, а также в вебе и на десктопе. Системные функции подключаются через плагины; если нужного нет — пишется платформенный код.
React Native
Фреймворк от Meta, приложения пишутся на JavaScript или TypeScript с React. Интерфейс строится из настоящих системных компонентов. Большой плюс — огромная экосистема JavaScript и возможность привлечь веб-разработчиков. С версии 0.76 по умолчанию включена «новая архитектура», которая уменьшила накладные расходы на взаимодействие JavaScript с нативным кодом. Популярная обвязка Expo упрощает сборку, обновления и публикацию.
Kotlin Multiplatform (KMP)
Подход от JetBrains: общая бизнес-логика (сеть, данные, правила) пишется на Kotlin и используется на обеих платформах, а интерфейс можно делать нативным для каждой или общим — через Compose Multiplatform, версия которого для iOS получила статус стабильной в мае 2025 года (Compose Multiplatform 1.8.0). Удобен для команд, у которых уже есть Android-разработчики на Kotlin, и для постепенного перехода существующих нативных приложений.
PWA (прогрессивное веб-приложение)
Сайт, который можно установить на главный экран, с работой без сети и уведомлениями. Не требует публикации в магазинах и обновляется мгновенно. Возможности ограничены тем, что разрешает браузер: на iOS push-уведомления для веб-приложений, добавленных на главный экран, доступны начиная с iOS 16.4, но многие системные функции (фоновые задачи, часть датчиков, глубокая интеграция с ОС) веб-приложениям недоступны или работают ограниченно.
Сравнительная таблица
| Критерий | Нативная | Flutter | React Native | KMP | PWA |
|---|---|---|---|---|---|
| Кодовых баз для iOS и Android | 2 | 1 | 1 | 1 общая логика + UI общий или раздельный | 1 (веб) |
| Стоимость первой версии | Выше всех | Ниже | Ниже | Средняя | Самая низкая |
| Производительность и плавность | Максимальная | Высокая | Высокая для типовых интерфейсов | Близка к нативной | Зависит от браузера |
| Доступ к функциям устройства | Полный, сразу | Через плагины или свой код | Через модули или свой код | Полный через платформенный код | Ограниченный |
| Новые функции ОС в день выхода | Да | С задержкой | С задержкой | Да, в нативной части | Как решит браузер |
| Внешний вид | Системный | Одинаковый на платформах | Системные компоненты | Любой | Веб-интерфейс |
| Публикация в магазинах | Да | Да | Да | Да | Не нужна (возможна через обёртку) |
| Поиск разработчиков | Два профиля | Dart-разработчики | Большой рынок JS/TS | Kotlin-разработчики + iOS | Веб-разработчики |
Когда выбирать нативную разработку
- Продукт строится вокруг возможностей устройства: работа с камерой и обработкой изображения в реальном времени, AR, Bluetooth-устройства, фоновая геолокация, интеграция с часами, виджеты, CarPlay и Android Auto.
- Критична производительность: сложная графика, большие списки с медиа, редакторы фото и видео, игры (хотя для игр чаще используют игровые движки).
- Нужны новейшие функции ОС сразу после релиза — например, новые элементы интерфейса или системные интеграции, которые кроссплатформенные библиотеки поддержат позже.
- Приложение — главный продукт компании на долгие годы, и есть ресурсы на две сильные команды.
- Высокие требования к безопасности, где важен полный контроль над каждым уровнем и минимум сторонних зависимостей (банковские и медицинские приложения часто выбирают нативный стек, хотя это не обязательное правило).
Когда выбирать кроссплатформенную разработку
- Приложение в основном показывает данные с сервера и собирает ввод пользователя: каталоги, запись, личные кабинеты, программы лояльности, доставка, внутренние инструменты для сотрудников.
- Нужно выпустить iOS и Android одновременно при ограниченном бюджете.
- Функциональность одинакова на обеих платформах, а дизайн фирменный, а не строго системный.
- Команда небольшая, и поддерживать две кодовые базы сложно.
Flutter, React Native или KMP?
| Ситуация | Чаще подходит |
|---|---|
| Нужен выразительный фирменный интерфейс, одинаковый везде | Flutter |
| В компании уже есть веб-команда на React/TypeScript | React Native |
| Есть нативное Android-приложение на Kotlin, нужно добавить iOS | Kotlin Multiplatform |
| Важен системный вид и поведение компонентов на каждой платформе | React Native или KMP с нативным UI |
| Нужны частые обновления логики без полного релиза | React Native (с учётом правил магазинов) |
| Планируется также веб- и десктоп-версия из того же кода | Flutter или Compose Multiplatform |
На практике выбор между тремя кроссплатформенными вариантами часто определяется командой: хорошо сделанное приложение на «не самом подходящем» фреймворке лучше, чем слабо сделанное на идеальном. Спросите исполнителя, сколько приложений на выбранной технологии он выпустил и поддерживает сейчас.
Когда достаточно PWA
Прогрессивное веб-приложение — хороший первый шаг, если:
- нужно быстро и недорого проверить, будут ли люди пользоваться сервисом;
- сервисом пользуются эпизодически, и уговаривать установить приложение из магазина неоправданно;
- важна мгновенная доставка изменений без модерации;
- не нужны глубокие системные функции и фоновая работа.
Ограничения PWA: нет присутствия в поиске магазинов приложений (если не делать обёртку), меньше доверия у части пользователей, ограничения браузеров на iOS, менее надёжные уведомления. Многие проекты начинают с PWA или адаптивного сайта, а мобильное приложение делают, когда подтверждён спрос на регулярное использование.
Мифы о кроссплатформенной разработке
«Кроссплатформенное приложение всегда тормозит»
Для типовых бизнес-интерфейсов разница с нативным приложением, как правило, незаметна пользователю, если приложение сделано аккуратно. Проблемы с производительностью чаще связаны с архитектурой (лишние перерисовки, тяжёлые изображения, неоптимальные запросы), чем с фреймворком.
«Один код — значит в два раза дешевле»
Экономия реальна, но не двукратна. Дизайн под две платформы, тестирование на устройствах обеих систем, публикация в разные магазины, платформенные интеграции и обновления под новые версии ОС делаются для каждой платформы отдельно. Подробнее о структуре бюджета — в статье «Сколько стоит разработка мобильного приложения».
«Потом легко переписать на натив»
Переписать можно, но это почти новый проект. Если вы заранее знаете, что продукт будет требовать глубокой интеграции с устройством, лучше закладывать это в выбор сразу. Kotlin Multiplatform здесь удобен тем, что позволяет переносить общую логику постепенно.
Риски и вопросы долгосрочной поддержки
Технология — это обязательство на годы. Перед выбором стоит оценить:
- Зрелость и сообщество. Регулярность релизов, количество поддерживаемых библиотек, наличие ответов на типичные вопросы.
- Зависимость от плагинов. Каждый сторонний плагин для доступа к функции устройства — это код, который нужно обновлять вместе с ОС. Заброшенный плагин может заблокировать обновление всего приложения.
- Требования магазинов. Google Play и Apple ежегодно поднимают минимальные требования: в 2026 году Google Play с 31 августа принимает новые приложения и обновления только с целевым API level 36 (Android 16), а App Store с 28 апреля — только сборки из Xcode 26 с SDK iOS 26. Кроссплатформенный фреймворк должен успевать поддерживать такие требования, а команда — вовремя обновлять проект.
- Рынок специалистов. Сможете ли вы найти другую команду, если текущий исполнитель уйдёт? Для популярных технологий — да; для экзотических — сложнее и дороже.
- Данные пользователей. Каждая библиотека аналитики, карт или крэш-репортов получает часть данных. Для приложений с аккаунтами это вопрос не только архитектуры, но и 152-ФЗ — подробнее в статье «Персональные данные в мобильном приложении».
- Российская специфика. Проверьте, как выбранный стек работает с сервисами, доступными в России: RuStore Push и платежи, AppMetrica, отечественные карты, SMS-шлюзы. У популярных технологий есть официальные или поддерживаемые сообществом SDK.
Обязательные обновления под новые версии ОС и требования магазинов стоит сразу заложить в бюджет — как это посчитать, разобрано в разделе о расходах после релиза в статье «Сколько стоит разработка мобильного приложения».
Что спросить у исполнителя о технологии
Если выбор технологии предлагает подрядчик, его рекомендацию полезно проверить несколькими вопросами. Хороший исполнитель ответит на них конкретно и без обид — это нормальная часть подготовки проекта. Общий порядок выбора исполнителя описан в статье «Как выбрать подрядчика для разработки приложения».
- Почему именно этот стек для нашего проекта? Ответ должен опираться на ваши функции и ограничения, а не на «мы всегда так делаем».
- Какие функции устройства потребуют платформенного кода? Попросите перечислить их и оценить отдельно — это самые рискованные части кроссплатформенного проекта.
- Какие сторонние плагины и SDK будут использованы? Кто их поддерживает, когда обновлялись в последний раз, есть ли замена, если библиотеку забросят.
- Сколько приложений на этой технологии команда выпустила и поддерживает сейчас? Опыт поддержки важнее опыта запуска.
- Как будут выполняться ежегодные требования Google Play и App Store? Кто и в какие сроки обновляет фреймворк, зависимости и настройки сборки.
- Сможет ли другая команда продолжить работу? Есть ли документация по архитектуре, автоматическая сборка, передаются ли исходный код и доступы к аккаунтам магазинов.
Ответы стоит зафиксировать письменно: они пригодятся и при сравнении предложений, и через год, когда приложение придётся обновлять.
Алгоритм выбора за 5 шагов
- Выпишите функции, связанные с устройством: камера, геолокация, Bluetooth, фоновая работа, виджеты, биометрия, платежи. Отметьте, какие из них критичны для первой версии.
- Определите аудиторию и платформы. Нужны ли обе мобильные ОС сразу? Нужны ли веб и планшеты?
- Оцените требования к интерфейсу. Строго системный вид или фирменный дизайн? Насколько сложны анимации?
- Посмотрите на команду. Какие компетенции уже есть у вас или у выбранного подрядчика? Кто будет поддерживать продукт через два года?
- Сделайте технический прототип рискованной функции. Если сомневаетесь, что фреймворк справится с конкретной задачей (например, работа с Bluetooth-оборудованием), проверьте это за 1–2 недели до основного договора.
Решение и его обоснование стоит зафиксировать в техническом задании — это пригодится при смене исполнителя и планировании поддержки после релиза. Структура ТЗ описана в статье «Техническое задание на мобильное приложение».
Кроссплатформенность подходит, если
- Основная ценность — данные и сценарии, а не возможности устройства
- Нужны iOS и Android одновременно
- Бюджет и команда ограничены
- Нет требований к новейшим функциям ОС в день релиза
- Выбранная технология популярна и у подрядчика есть опыт
Частые вопросы
Что лучше в 2026 году — Flutter или React Native?
Обе технологии зрелые и подходят для большинства бизнес-приложений. Flutter удобнее для фирменного интерфейса, одинакового на всех платформах; React Native — если в компании есть JavaScript-разработчики и важны системные компоненты. Решающим фактором чаще оказывается опыт конкретной команды.
Можно ли сделать банковское или медицинское приложение на Flutter или React Native?
Технически да, такие примеры есть. Но требования к безопасности, сертификации и аудиту кода в этих отраслях выше, и часть компаний выбирает нативный стек, чтобы минимизировать сторонние зависимости. Решение принимается вместе со специалистами по безопасности.
Приложение на кроссплатформенном фреймворке пропустят в App Store?
Да. Магазины оценивают приложение по правилам (функциональность, контент, приватность, стабильность), а не по технологии, на которой оно написано.
Что такое Kotlin Multiplatform простыми словами?
Это способ писать общую логику приложения (работу с сервером, данными и правилами) один раз на Kotlin и использовать её в iOS- и Android-версиях. Интерфейс при этом можно оставить нативным или тоже сделать общим с помощью Compose Multiplatform.
Можно ли сначала сделать PWA, а потом приложение?
Да, это распространённый путь. PWA помогает проверить спрос и сценарии. Серверную часть и API можно спроектировать так, чтобы потом использовать их и в мобильном приложении.
Нужны ли нативные разработчики, если выбран кроссплатформенный фреймворк?
Желательно иметь к ним доступ. Для интеграции с системными функциями, решения проблем сборки и публикации иногда требуется знание Swift или Kotlin, особенно в нестандартных задачах.
Итог
Выбирайте технологию от задачи: перечислите функции устройства, требования к интерфейсу, платформы и ресурсы команды на годы вперёд. Для типового бизнес-приложения кроссплатформенный фреймворк даёт лучший баланс цены и качества; нативная разработка — для продуктов, где устройство и производительность определяют ценность; PWA — для быстрой проверки спроса. Какое бы решение вы ни приняли, зафиксируйте его причины письменно и учтите в бюджете поддержку.