Короткий ответ: выбор по 10 критериям
Кроссплатформенная разработка обычно разумна, если обе платформы решают одну продуктовую задачу, интерфейс в основном брендовый, критичные интеграции заранее проверены, а один продуктовый ритм важнее независимого развития iOS и Android. Native чаще выигрывает, если одна платформа главная, системное поведение составляет ценность продукта, тяжёлая функция работает на пределе устройства или в компании уже есть сильные Swift- и Kotlin-команды.
| Критерий | В пользу cross-platform | В пользу native |
|---|---|---|
| 1. UX | Общий брендовый интерфейс | Глубокие правила каждой платформы |
| 2. Производительность | Обычные экраны и сетевые сценарии | Тяжёлая графика, видео, вычисления |
| 3. Hardware/API | Зрелые типовые интеграции | Новые или глубокие системные API |
| 4. Фоновая работа | Ограниченные, проверенные задачи | Фон — ядро продукта |
| 5. Команда | Один ответственный контур | Две зрелые платформенные команды |
| 6. Магазины | Синхронный план релизов | Независимые версии и возможности |
| 7. QA | Общие сценарии и единая аналитика | Много платформенных веток |
| 8. Общий код | Совпадают правила и экраны | Исключения пронизывают продукт |
| 9. Владение | Команда умеет поддержать нативные края | Стек уже встроен в организацию |
| 10. TCO | Меньше полезного дублирования | Исключения дороже двух реализаций |
Главная мысль: решение принимает не средний экран, а самый сложный платформенный сценарий. Найдите его до оценки.
Что именно сравниваем: четыре разных подхода
Native — отдельные приложения на Swift/Objective-C для экосистемы Apple и Kotlin/Java для Android. Команда получает прямой доступ к платформенным средствам и может выпускать разные функции независимо. Цена — две реализации пользовательского слоя и необходимость согласовывать поведение между ними.
Flutter строит общий интерфейс и логику на Dart, а системные возможности подключает через плагины или собственный нативный код. React Native использует JavaScript или TypeScript и React, связывая общий продуктовый слой с нативными компонентами и модулями. В обоих случаях «общая кодовая база» не отменяет Swift/Kotlin там, где продукт выходит за пределы готовых библиотек. Подробный разбор границ, плагинов и проверок Flutter уже есть в статье «Разработка приложения на Flutter»; здесь не повторяем внутренности фреймворка, а сравниваем варианты на уровне решения бизнеса.
Web wrapper показывает веб-интерфейс внутри оболочки приложения. Он может подойти для простого кабинета или внутреннего сервиса, но не равен Flutter или React Native: поведение браузерного слоя, работа без сети, доступность, жесты и интеграции с системой требуют отдельной оценки. Если задача в основном контентная, оболочка иногда добавляет магазины и поддержку, не создавая заметной пользы пользователю.
1. UX: одинаковый бренд не означает одинаковое поведение
Пользователь iPhone ожидает знакомую навигацию, системные разрешения, жест возврата, работу клавиатуры и доступность. Пользователь Android — свои привычные модели. Кроссплатформенный интерфейс может выглядеть едино, но команда всё равно решает, где сохранить общий бренд, а где уважить правила платформы. Это влияет не на эстетический спор, а на число ошибок, обращений в поддержку и скорость освоения продукта.
Представьте банковскую форму с биометрией, системным выбором файла и подтверждением платежа. Нарисовать одинаковые кнопки легко. Сложнее правильно вернуть человека после системного экрана, восстановить незаполненные поля и озвучить ошибку экранным диктором. Для брендового каталога адаптации обычно локальны; для продукта, чья ценность — «ощущаться частью iOS или Android», они могут распространиться на каждый экран.
Проверка: соберите список не макетов, а действий — ввод, возврат, разрешение, ошибка, слабая сеть, крупный шрифт, экранный диктор. Отметьте, где ожидаемое поведение платформ различается.
2. Производительность и тяжёлые сценарии
Для каталога, профиля, формы и обмена данными с сервером название стека редко определяет успех само по себе. Важнее качество изображений, число запросов, работа со списками, кэширование и дисциплина команды. Но видеомонтаж, дополненная реальность, непрерывный поток с камеры, сложная анимация, обработка звука или очень жёсткая задержка меняют разговор: здесь надо измерять конкретную цепочку на целевом устройстве.
Допустим, ключевая функция одновременно получает кадр камеры, распознаёт объект и рисует подсказку. Демонстрация на флагманском телефоне не отвечает, что произойдёт при нагреве, входящем звонке, нехватке памяти и на нижней границе поддерживаемых устройств. Native даёт самый прямой путь к инструментам платформы, но и он не гарантирует скорость без измерений. Для cross-platform критичны ещё переходы между общим и нативным слоями.
Поэтому в требования записывают наблюдаемое условие: какой сценарий, на каком устройстве, при какой нагрузке и что считается приемлемым. Если условие неизвестно, его нельзя честно заменить словом «быстро».
3–4. Hardware, системные API и фоновая работа
Камера, карты, геолокация, Bluetooth, NFC, платежные терминалы, медицинские устройства, CarPlay/Android Auto, системные виджеты и фоновые процессы — типичные места, где общая часть заканчивается. Наличие готовой библиотеки отвечает лишь на вопрос «можно ли вызвать API». Оно не подтверждает весь нужный сценарий, одинаковое поведение платформ, поддержку конкретного оборудования и своевременное обновление после новой версии ОС.
Особенно осторожно оценивают фон. iOS и Android управляют жизненным циклом приложения, батареей и разрешениями по-разному. Официальное руководство Android предлагает выбирать между асинхронной работой, WorkManager, foreground service и другими средствами по задаче, а не использовать один механизм для всего. Значит, «продолжать работу после закрытия» сначала раскладывают на точные события, частоту, допустимую задержку и объяснимую пользователю пользу.
Паспорт критичной интеграции
Действие: что делает пользователь.
Оборудование: модели и версии ОС.
Разрешения: первый запрос и отказ.
Фон: что должно продолжаться.
Сбой: понятный запасной путь.
SDK: владелец и обновления.
Проверка: измеримый результат прототипа.
Ответственный: кто чинит нативный край.
5. Команда, найм и ответственность
Один репозиторий уменьшает число передач между командами, но может создать зависимость от одного специалиста, который знает и общий слой, и обе платформы. Два нативных приложения требуют больше координации, зато сильные существующие команды сохраняют привычные инструменты, процессы выпуска и диагностики. Переписывать зрелый код ради формального объединения часто дороже, чем оставить две устойчивые реализации.
Вопрос найма шире числа резюме. Кто дежурит при сбое? Кто читает нативный журнал падения? Кто обновляет сторонний SDK, сертификаты и сборочный контур? Кто может заменить ключевого разработчика? Если на каждый ответ звучит одно имя, технология не решила организационный риск.
Хорошая модель владения фиксирует ответственного за продуктовый сценарий, общий слой и каждый критичный нативный модуль. Документация должна позволить новой команде собрать приложение, воспроизвести сбой и выпустить обновление, а не только понять структуру папок.
6. Релизы и магазины: общей публикации не бывает
App Store и Google Play остаются отдельными контурами независимо от технологии. Нужны аккаунты, подписи, сборки, карточки, сведения о конфиденциальности, проверка платежей, управление версиями и ответы на замечания. Правила меняются: Apple прямо называет App Review Guidelines живым документом и возлагает на разработчика ответственность за сторонние SDK. Поэтому соответствие магазинам — постоянная работа, а не последний день проекта.
Кроссплатформенность особенно полезна, когда продукт хочет выпускать одну функцию на обеих платформах почти синхронно. Native удобнее, когда iOS и Android развиваются разными темпами или получают разные возможности. Представьте, что партнёрский SDK доступен на Android раньше. Общий интерфейс всё равно должен скрыть функцию на iOS, аналитика — различить ветки, а поддержка — объяснить разницу пользователям.
План выпуска включает внутреннее тестирование, поэтапное развёртывание, возможность отката серверной функции и удалённые переключатели. Они уменьшают цену ошибки, но не заменяют проверку сборки магазина.
7. QA и наблюдаемость: общий код — не общий результат
Тест бизнес-правила может быть общим. Но клавиатура, разрешения, системные диалоги, уведомления, ссылки, фон, обновление поверх старой версии и восстановление после выгрузки приложения проверяются отдельно. Добавьте разные размеры экранов, версии ОС и производителей Android — и станет ясно, почему обещание «тестируем один раз» создаёт долг.
Наблюдаемость означает, что команда видит падения, зависания, сетевые ошибки и шаги критичного сценария с разрезом по версии приложения, ОС и устройству. Для нативных исключений полезно отдельно отмечать версию SDK и результат вызова. Иначе общий экран маскирует две разные причины сбоя.
Минимальный контур приёмки строят от риска: реальные устройства для критичных интеграций, автоматические проверки общего поведения, платформенные сценарии и ручная проверка того, что нельзя надёжно автоматизировать. Количество тестов не заменяет покрытие самого дорогого отказа.
8–9. Общий код и цена исключений
Полезно делить продукт на три слоя. Первый — действительно общие правила: расчёты, валидация, модели данных, сетевые контракты. Второй — интерфейс, который может быть общим, но адаптируется к платформе. Третий — системные интеграции и сборка. Чем яснее границы, тем проще заменить библиотеку, протестировать сбой и оценить перенос.
Ошибка начинается с цели «максимизировать процент общего кода». Команда заталкивает в общий слой условные ветки, хотя две маленькие нативные реализации были бы понятнее. Цель должна быть другой: уменьшить полезное дублирование, не пряча различия платформ. Иногда дублирование — осознанная плата за независимость и ясность.
У исключения должен быть контракт: входные данные, результат, ошибки, запасной путь, ответственный и тесты. Если исключение касается критичной функции и у команды нет подтверждённой реализации, в матрице ставят ?, а не оптимистичный плюс. Дальше делают небольшой технический прототип — spike — только на этом риске.
10. TCO, миграция и срок жизни продукта
Полная стоимость владения — не только первая разработка. Сложите проектирование, две сборки, серверную часть, дизайн, QA, магазины, аналитику, поддержку пользователей, обновления фреймворка и SDK, устранение уязвимостей, обучение команды и возможный перенос. Сравнивать варианты можно лишь на одинаковом составе функций и горизонте. Универсальный процент экономии здесь был бы выдумкой.
Миграция редко означает «переключить технологию». Серверные контракты, знания о продукте и часть дизайна сохраняются. Интерфейс, навигацию, управление состоянием, нативные интеграции, сборки и значительную часть тестов переносят или переписывают. Поэтому условия выхода фиксируют заранее: например, критичный SDK перестал поддерживаться, платформы получили разные планы или стоимость нативных исключений стабильно превышает пользу общего слоя.
Для более широкой оценки бюджета полезна статья о составе стоимости мобильного приложения: она помогает не потерять сервер, аналитику, публикацию и сопровождение, когда сравнение стека сузилось до часов разработчиков.
План поставки: общий код не отменяет интеграцию и QA
Разработка общего продуктового слоя должна заканчиваться проверяемой сборкой, после которой отдельно идут интеграция, подготовка тестовых версий и стабилизация. Совместная кодовая база не отменяет эти этапы и не превращает их в автоматический результат выбора фреймворка.
В плане подрядчика должны быть видны границы: где заканчивается разработка экранов, когда проверяются интеграции, кто принимает сборки и какой запас заложен на исправления. Без этих ответов календарь не доказывает, что Flutter или другой общий стек подойдёт вашей задаче.
Взвешенная матрица: как получить решение, а не красивую сумму
Сначала команда присваивает каждому критерию вес: критично, важно, желательно или не имеет значения. Затем каждый вариант получает оценку: + подходит, 0 нейтрально, − создаёт существенный риск, ? данных не хватает. Вес отражает продукт, а знак — доказательства, не предпочтение разработчика.
| Критерий | Вес | Native | Flutter | React Native | Web wrapper |
|---|---|---|---|---|---|
| Платформенный UX | ___ | ___ | ___ | ___ | ___ |
| Тяжёлый сценарий | ___ | ___ | ___ | ___ | ___ |
| Hardware/API | ___ | ___ | ___ | ___ | ___ |
| Фоновая работа | ___ | ___ | ___ | ___ | ___ |
| Команда и замена людей | ___ | ___ | ___ | ___ | ___ |
| Независимость релизов | ___ | ___ | ___ | ___ | ___ |
| QA и диагностика | ___ | ___ | ___ | ___ | ___ |
| Общие правила продукта | ___ | ___ | ___ | ___ | ___ |
| Поддержка экосистемы | ___ | ___ | ___ | ___ | ___ |
| TCO и миграция | ___ | ___ | ___ | ___ | ___ |
Правило veto: минус по критичному требованию нельзя перекрыть несколькими плюсами по желательным. Например, удобный найм не компенсирует невозможность надёжно работать с обязательным устройством. Правило неизвестного: знак вопроса по критичному критерию останавливает выбор до прототипа. Команда заранее записывает, какой результат превратит ? в плюс, ноль или минус.
После заполнения не обязательно считать баллы. Сначала удалите варианты с veto, затем сравните оставшиеся по важным критериям и цене владения. Если два подхода близки, организационная совместимость и обратимость решения обычно ценнее иллюзии математической точности.
Когда приложение не нужно
Представьте услугу, которой клиент пользуется один раз в год: открыть ссылку, заполнить короткую форму и получить документ. Установка, регистрация, место на телефоне и обновления добавят препятствия, а не ценность. Адаптивный сайт сохранит прямой вход из поиска и сообщения.
PWA подходит части веб-сценариев с установкой и ограниченной работой без сети. Telegram Mini App может быть рациональнее, если аудитория уже приходит из Telegram и сценарий не требует глубокой системной интеграции. Полезно также спросить, можно ли сначала проверить спрос веб-версией или служебным прототипом. Материал о разработке приложения под ключ поможет оценить весь процесс, если регулярный мобильный сценарий всё же подтверждён.
Не делайте приложение ради присутствия в магазине. Оно оправдано, когда установка улучшает повторяющееся действие: уведомления, работа без сети, камера, геолокация, оборудование или быстрый персональный доступ.
Официальные источники
Платформенные сведения сверены 30 июля 2026 года. Перед проектированием и релизом проверяйте актуальные версии первичных документов.
- Поддерживаемые платформы Flutter и официальный обзор архитектуры Flutter.
- Новая архитектура React Native и официальное руководство по нативным модулям и компонентам.
- App Store Review Guidelines и Apple Human Interface Guidelines.
- Руководство Android по фоновой работе и официальная дизайн-система Material 3.
- Требования Google Play к целевому уровню Android API.
FAQ
Что лучше: нативное или кроссплатформенное приложение?
Универсального победителя нет. Кроссплатформенный подход обычно силён, когда iOS и Android решают одну задачу, а системные исключения известны и ограничены. Native чаще оправдан, когда одна платформа приоритетна, платформенный UX составляет ценность продукта или критичный сценарий глубоко зависит от камеры, Bluetooth, NFC, видео, фона либо нового системного API.
Кроссплатформенная разработка всегда дешевле?
Нет. Она может уменьшить дублирование интерфейса и бизнес-логики, но не отменяет две сборки, магазины, устройства, платформенные разрешения, тестирование и сопровождение сторонних SDK. Сравнивайте полную стоимость владения на одинаковом составе функций, включая нативные исключения, QA, обновления и возможную миграцию.
Как выбрать между Flutter и React Native?
Сначала проверьте продуктовые ограничения, а затем соответствие команды и экосистемы. Для критичных интеграций сравните зрелость библиотек, возможность написать собственный нативный модуль, наблюдаемость ошибок и план обновлений. Выбор языка или популярность фреймворка не заменяют технический прототип самого рискованного сценария.
Когда нужен технический прототип перед выбором стека?
Прототип нужен, если в матрице есть знак вопроса по критичному сценарию: фоновая геолокация, Bluetooth, NFC, камера, видео, карты, платёжный SDK, системный виджет или жёсткое требование к задержке. Проверяют не демонстрационный экран, а конкретный риск на целевых устройствах и версиях операционных систем.
Можно ли начать кроссплатформенно, а затем перейти на native?
Можно, но переход не бесплатен. Сохраняются серверная часть, продуктовые знания, дизайн и иногда отдельные библиотеки, однако интерфейс, навигацию, состояние, интеграции, сборки и тесты часто приходится переносить. До старта зафиксируйте границы модулей и условия, при которых миграция станет рациональной.
Когда мобильное приложение вообще не нужно?
Если пользователь редко выполняет короткое действие, не нужны глубокие системные функции, работа без сети и постоянное присутствие на телефоне, адаптивный сайт, PWA или Telegram Mini App могут быть проще. Приложение оправдано не фактом публикации в магазине, а регулярным сценарием, который действительно выигрывает от установки.
Сравним подходы на вашем самом сложном сценарии
Пришлите список функций первой версии, целевые платформы и устройства, обязательные SDK, требования к фону, работе без сети, производительности и ритму релизов. На первой встрече 13FOX заполнит с вами веса, отделит общее ядро от нативных исключений и обозначит неизвестные, для которых нужен прототип. На выходе вы получите сопоставимую карту вариантов с veto, рисками и следующими проверками — без обещания цены и срока до входных данных. Если задачу разумнее закрыть сайтом, PWA, Mini App или одной платформой, скажем об этом до большой разработки.