Кроссплатформенная разработка на Flutter или React Native закрывает большинство задач бизнеса: один код работает на iOS и Android, выпуск и поддержка обходятся дешевле. Нативная разработка нужна, когда приложение упирается в возможности устройства: сложная графика, фоновая работа с датчиками, новые системные функции в день выхода. Выбор определяет список функций и бюджет на поддержку, а не мода на фреймворк.
Коротко
Нативное приложение пишут отдельно под каждую систему, кроссплатформенное собирают из одной кодовой базы для обеих. Нативная разработка — это два приложения, на Kotlin для Android и на Swift для iOS, и каждое обращается к системным интерфейсам напрямую, без промежуточных слоёв.
Кроссплатформенная разработка — это одна кодовая база плюс платформенный слой, из которых собираются приложения для iOS и Android. Flutter пишут на Dart, React Native — на JavaScript или TypeScript, Kotlin Multiplatform — на Kotlin.
Граница между общим и платформенным кодом зависит от функций: чем больше их завязано на конкретное устройство, тем больше кода придётся писать отдельно под каждую систему. Сам проект в обоих случаях проходит одни и те же этапы: аналитика, дизайн, разработка приложения для iOS и Android, тестирование и публикация.
Универсального победителя нет: кроссплатформа выигрывает по срокам и стоимости поддержки, нативная разработка — по доступу к устройству и скорости работы с новыми версиями систем. Сравнивайте подходы по параметрам, которые попадут в смету и в план поддержки.
| Критерий | Нативная разработка | Кроссплатформенная разработка |
|---|---|---|
| Кодовая база | Две: Kotlin для Android, Swift для iOS | Одна общая плюс платформенный слой |
| Выход на обе платформы | Дольше: каждая функция делается дважды | Быстрее: одна реализация на обе платформы |
| Доступ к функциям устройства | Прямой, к любым системным интерфейсам | Через готовые плагины или собственный нативный модуль |
| Интерфейс | Системные компоненты и правила каждой платформы | Общий дизайн, платформенные детали настраиваются отдельно |
| Команда | Разработчики Android и iOS, два набора тестов | Один основной стек плюс нативные навыки для плагинов |
| Новые возможности iOS и Android | Доступны сразу с выходом инструментов разработчика | После поддержки во фреймворке или через свой нативный модуль |
| Поддержка после запуска | Каждая правка делается и тестируется дважды | Одна правка выходит на обе платформы |
| Главный риск | Бюджет и сроки | Зависимость от фреймворка и сторонних плагинов |
Нативный код оправдан, когда приложение большую часть времени работает с камерой, датчиками и модулями связи, а не с экранами и данными.
В таких проектах кроссплатформенный фреймворк всё равно придётся дополнять нативными модулями под обе системы, и экономия исчезает.
Кроссплатформенный подход выигрывает, когда приложение по сути остаётся интерфейсом к вашим данным и процессам.
Работа с устройством в таких приложениях обычно сводится к камере для QR-кодов, геолокации и push-уведомлениям. Для этих функций у Flutter и React Native есть готовые плагины, поэтому нативного кода остаётся немного.
Выбирайте инструмент по тому, что должно стать общим: во Flutter это интерфейс и логика, в React Native — логика на JavaScript за системными компонентами, в Kotlin Multiplatform — бизнес-логика, а интерфейс остаётся на ваше усмотрение.
| Инструмент | Язык | Как строится интерфейс | Когда подходит |
|---|---|---|---|
| Flutter | Dart | Рисуется собственным движком, одинаково на всех устройствах | Важны единый фирменный интерфейс и предсказуемая анимация |
| React Native | JavaScript или TypeScript | Из системных компонентов iOS и Android | В компании есть веб-команда на JavaScript и общая с сайтом логика |
| Kotlin Multiplatform | Kotlin | Нативный на каждой платформе или общий на Compose Multiplatform | Уже есть нативное Android-приложение или интерфейс должен остаться родным для платформы |
Две известные причины подтормаживаний кроссплатформенных приложений устранены в самих фреймворках. Flutter рисует интерфейс движком Impeller, который компилирует шейдеры заранее, а не во время работы приложения: на iOS это движок по умолчанию, на Android — с версии 3.27 на устройствах с API 29 и выше. В React Native 0.76 новая архитектура стала режимом по умолчанию: асинхронный «мост» между JavaScript и нативным кодом заменён прямыми вызовами через JSI.
Google официально поддерживает Kotlin Multiplatform для общей бизнес-логики Android и iOS, а с Compose Multiplatform от JetBrains общим можно сделать и интерфейс. Переписывать приложение целиком для перехода не нужно: общий код добавляют постепенно.
Совет Выбирайте инструмент, под который в вашем городе можно найти разработчика на замену: приложение переживёт нескольких специалистов. Перед решением посмотрите свежие вакансии и резюме по каждому фреймворку.
Обещание «один код на две платформы» верно для экранов и бизнес-логики, но не для каждой системной функции. Если нужной возможности нет в готовых плагинах, разработчик пишет платформенный модуль: код на Kotlin для Android и на Swift для iOS. Во Flutter для этого есть платформенные каналы, в React Native — нативные модули.
Поэтому считайте не долю общего кода, а список функций, для которых плагина нет. Обычно это системы управления корпоративными устройствами, оборудование вроде весов, принтеров чеков и сканеров, а также SDK партнёров, выпущенные только для одной платформы.
Каждая такая интеграция — это две нативные реализации и специалист, который умеет их писать и обновлять. Проверьте внешние интеграции до оценки проекта:
На выбор влияют четыре местные особенности: устройства клиентов, платежи, Telegram и язык интерфейса. Первое — устройства. По данным StatCounter за август 2026 года, на Android пришлось около 83 % просмотров веб-страниц с мобильных телефонов в Узбекистане, на iOS — около 17 %. Это доля трафика, а не число устройств, но перекос заметный: многим продуктам разумно выйти сначала на Android и добавить iOS вторым шагом.
Совет Прежде чем откладывать iOS, проверьте, с каких устройств приходят ваши платящие клиенты: в аналитике сайта, данных о заказах или отчётах рекламы. Если продукт платный и рассчитан на премиальный сегмент, доля iOS среди покупателей может оказаться выше, чем в среднем по стране.
Второе — платежи. Документация Payme по-прежнему ссылается на официальный Android SDK, но его репозиторий 2 августа 2023 года переведён в архив, а SDK для iOS нет. Карту в приложении привязывают через клиентские методы Subscribe API или открывают страницу оплаты Payme с адресом возврата после оплаты. Оба способа работают из общего кода без нативного модуля, а подтверждение оплаты ваш сервер получает напрямую от Payme.
Третье — Telegram. Запись, заказы и уведомления можно вынести в личный кабинет внутри Telegram: без установки из магазина и без ежегодных взносов. Так мы сделали регистрацию на UzFranchise Expo: гости регистрировались на трёх языках и получали QR-билеты прямо в чате бота. Бот для заявок и записи мы делаем от 1 200 $, поэтому сравните этот вариант с приложением, прежде чем утверждать бюджет.
Четвёртое — язык интерфейса. Приложению для местного рынка обычно нужны узбекский и русский, часто ещё английский. В общей кодовой базе строки переводятся один раз, в нативном проекте — отдельно для Android и iOS, и расхождения между версиями приходится вылавливать вручную.
Разработка — только первый платёж. Дальше приложение живёт по правилам магазинов: взносы и требования к обновлениям одинаковы для любого подхода, а стоимость доработок — нет.
Важно С 31 августа 2026 года Google Play принимает новые приложения и обновления только с целевым уровнем Android 16 (API 36), а уже опубликованные приложения должны быть нацелены минимум на API 35, иначе их не увидят новые пользователи на более свежих версиях Android. Продлить срок можно по запросу до 1 ноября 2026 года. Apple с 28 апреля 2026 года принимает только сборки из Xcode 26 с SDK iOS 26.
Начинайте не с фреймворка, а со списка того, что приложение должно делать.
Мы в Syntra Systems проходим эти шаги вместе с заказчиком до оценки. Если функции обращаются к устройству редко, а обе платформы нужны сразу, собираем кроссплатформенное приложение и оставляем нативными только те места, где без этого не обойтись. Если приложение в основном работает с камерой, датчиками и модулями связи, делаем его нативно и не тратим бюджет на промежуточные слои.
Дальше ведём проект одной командой: интерфейс, бэкенд, интеграции с CRM и платёжными системами, публикация в обоих магазинах и поддержка после запуска.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Это частый путь: продукт стартует на Flutter или React Native, а нативная версия появляется, когда этого требуют нагрузка или новые функции. Переписывать придётся интерфейс и работу с устройством, а бэкенд, данные и карточки в магазинах останутся прежними.
В типичном бизнес-приложении со списками, формами и уведомлениями разницу замечают редко. Она проявляется в сложной анимации, при долгой работе камеры и когда система получает новую функцию, которую фреймворк ещё не поддерживает.
Гибридное приложение показывает веб-страницы внутри встроенного браузера (WebView). Flutter и React Native собирают полноценное приложение: Flutter рисует интерфейс своим движком, React Native выводит системные компоненты. Гибридный подход позволяет переиспользовать сайт, но сильнее ограничен возможностями браузера.
Фреймворк сам по себе на проверку не влияет. Отказы связаны с содержанием: приложение не даёт ничего сверх сайта, нарушает правила оплаты или не объясняет, зачем ему запрошенные разрешения.
Готовой библиотеки Payme для iOS нет, а репозиторий для Android с августа 2023 года в архиве. Поэтому карту привязывают через методы Payme прямо из приложения или открывают страницу оплаты Payme с возвратом в приложение. Оба способа работают в общем коде для iOS и Android, а подтверждение оплаты приходит на ваш сервер напрямую от Payme.
Каталог, заказы, профили и уведомления хранятся на сервере, а приложение только показывает эти данные. Сервер с базой и резервными копиями нужен при любом подходе и оплачивается отдельно от магазинов приложений. Если у бизнеса уже есть сайт или CRM, приложение подключают к ним, а не строят вторую систему с нуля.
Существующее Android-приложение можно сохранить: Google официально поддерживает Kotlin Multiplatform — способ писать общую логику, например расчёты и работу с сетью, один раз для Android и iOS. Общий код добавляют постепенно, по частям, без переписывания приложения целиком.
Попросите обосновать выбор списком функций: какие обращаются к устройству, для каких есть готовые плагины и что придётся писать нативно. Ответ «мы всегда делаем на этом фреймворке» означает, что задачу не разбирали.
Источники
Фото на обложке: Arpit Brandings, Pexels
