Короткий ответ: выбор по 10 критериям
Кроссплатформенная разработка обычно разумна, если обе платформы решают одну продуктовую задачу, интерфейс в основном брендовый, критичные интеграции заранее проверены, а один продуктовый ритм важнее независимого развития iOS и Android. Нативная разработка чаще выигрывает, если одна платформа главная, системное поведение составляет ценность продукта, тяжёлая функция работает на пределе устройства или в компании уже есть сильные Swift- и Kotlin-команды.
| Критерий | Когда общий код уместен | Когда отдельный код уместен |
|---|---|---|
| 1. Пользовательский опыт | Общий брендовый интерфейс | Глубокие правила каждой платформы |
| 2. Производительность | Обычные экраны и сетевые сценарии | Тяжёлая графика, видео, вычисления |
| 3. Оборудование и функции телефона | Готовые типовые подключения | Новые или глубокие функции системы |
| 4. Фоновая работа | Ограниченные, проверенные задачи | Фон составляет ядро продукта |
| 5. Команда и ответственность | Одна команда выпускает обе версии | Есть опытные команды для iPhone и Android |
| 6. Магазины | Синхронный план релизов | Независимые версии и возможности |
| 7. Тестирование | Общие сценарии и единая аналитика | Много платформенных веток |
| 8. Общий код | Совпадают правила и экраны | Различия затрагивают весь продукт |
| 9. Полная стоимость | Меньше лишнего дублирования | Исключения дороже двух реализаций |
| 10. Миграция и срок жизни | Новый продукт, границы модулей ясны | Зрелые приложения уже работают |
Примените матрицу к своей задаче: выберите одну функцию, без которой продукт теряет смысл, и выпишите устройство, разрешения, работу в фоне, сбои и владельца обновлений. Если в критичном пункте остаётся знак вопроса, технологию выбирать рано: сначала нужен технический прототип.
Что именно сравниваем: четыре разных подхода
Нативный подход означает отдельные приложения на Swift/Objective-C для экосистемы Apple и Kotlin/Java для Android. Команда получает прямой доступ к платформенным средствам и может выпускать разные функции независимо. Цена состоит из двух реализаций пользовательского слоя и необходимости согласовывать поведение между ними.
Например, если продукт сначала нужен только владельцам iPhone и зависит от новой возможности iOS, общий слой может не окупить себя. В таком случае полезно отдельно проверить путь создания приложения для iOS, а не платить за вторую платформу заранее.
Flutter строит общий интерфейс и логику на Dart, а системные возможности подключает через плагины или собственный нативный код. React Native использует JavaScript или TypeScript и React, связывая общий продуктовый слой с нативными компонентами и модулями. В обоих случаях «общая кодовая база» не отменяет Swift/Kotlin там, где продукт выходит за пределы готовых библиотек. Подробный разбор границ, плагинов и проверок Flutter уже есть в статье «Разработка приложения на Flutter»; здесь не повторяем внутренности фреймворка, а сравниваем варианты на уровне решения бизнеса.
Веб-оболочка показывает веб-интерфейс внутри приложения. Она может подойти для простого кабинета или внутреннего сервиса, но не равна Flutter или React Native: поведение браузерного слоя, работа без сети, доступность, жесты и интеграции с системой требуют отдельной оценки. Если задача в основном контентная, оболочка иногда добавляет магазины и поддержку, не создавая заметной пользы пользователю.
1. UX: одинаковый бренд не означает одинаковое поведение
Пользователь iPhone ожидает знакомую навигацию, системные разрешения, жест возврата, работу клавиатуры и доступность. У пользователя Android свои привычные модели. Кроссплатформенный интерфейс может выглядеть едино, но команда всё равно решает, где сохранить общий бренд, а где уважить правила платформы. Это влияет не на эстетический спор, а на число ошибок, обращений в поддержку и скорость освоения продукта.
Представьте банковскую форму с биометрией, системным выбором файла и подтверждением платежа. Нарисовать одинаковые кнопки легко. Сложнее правильно вернуть человека после системного экрана, восстановить незаполненные поля и озвучить ошибку экранным диктором. Для брендового каталога адаптации обычно локальны. В продукте, ценность которого состоит в привычном для iOS или Android поведении, различия могут затронуть каждый экран.
Проверка: соберите список не макетов, а действий: ввод, возврат, разрешение, ошибка, слабая сеть, крупный шрифт, экранный диктор. Отметьте, где ожидаемое поведение платформ различается.
2. Производительность и тяжёлые сценарии
Для каталога, профиля, формы и обмена данными с сервером название технологии редко определяет успех само по себе. Важнее качество изображений, число запросов, работа со списками, кэширование и дисциплина команды. Но видеомонтаж, дополненная реальность, непрерывный поток с камеры, сложная анимация, обработка звука или очень жёсткая задержка меняют разговор: здесь надо измерять конкретную цепочку на целевом устройстве.
Допустим, ключевая функция одновременно получает кадр камеры, распознаёт объект и рисует подсказку. Демонстрация на флагманском телефоне не отвечает, что произойдёт при нагреве, входящем звонке, нехватке памяти и на нижней границе поддерживаемых устройств. Нативный код даёт самый прямой путь к инструментам платформы, но и он не гарантирует скорость без измерений. Для общего кода критичны ещё переходы к платформенным слоям.
Поэтому в требования записывают наблюдаемое условие: какой сценарий, на каком устройстве, при какой нагрузке и что считается приемлемым. Если условие неизвестно, его нельзя честно заменить словом «быстро».
3–4. Оборудование, системные API и фоновая работа
Камера, карты, геолокация, Bluetooth, NFC, платежные терминалы, медицинские устройства, CarPlay/Android Auto, системные виджеты и фоновые процессы часто становятся местом, где общая часть заканчивается. Наличие готовой библиотеки отвечает лишь на вопрос «можно ли вызвать API». Оно не подтверждает весь нужный сценарий, одинаковое поведение платформ, поддержку конкретного оборудования и своевременное обновление после новой версии ОС.
Особенно осторожно оценивают фон. iOS и Android управляют жизненным циклом приложения, батареей и разрешениями по-разному. Официальное руководство Android предлагает разные механизмы для отложенной и срочной работы, а заметные пользователю задачи выделяет отдельно. Одно средство не подходит для всего. Значит, «продолжать работу после закрытия» сначала раскладывают на точные события, частоту, допустимую задержку и объяснимую пользователю пользу.
Паспорт критичной интеграции
Действие: что делает пользователь.
Оборудование: модели и версии ОС.
Разрешения: первый запрос и отказ.
Фон: что должно продолжаться.
Сбой: понятный запасной путь.
SDK: владелец и обновления.
Проверка: измеримый результат прототипа.
Ответственный: кто чинит отдельный код платформы.
5. Команда, найм и ответственность
Один репозиторий уменьшает число передач между командами, но может создать зависимость от одного специалиста, который знает и общий слой, и обе платформы. Два нативных приложения требуют больше координации, зато сильные существующие команды сохраняют привычные инструменты, процессы выпуска и диагностики. Переписывать зрелый код ради формального объединения часто дороже, чем оставить две устойчивые реализации.
Вопрос найма шире числа резюме. Кто дежурит при сбое? Кто читает нативный журнал падения? Кто обновляет сторонний SDK, сертификаты и сборочный контур? Кто может заменить ключевого разработчика? Если на каждый ответ звучит одно имя, технология не решила организационный риск.
Хорошая модель владения фиксирует ответственного за продуктовый сценарий, общий слой и каждый критичный нативный модуль. Документация должна позволить новой команде собрать приложение, воспроизвести сбой и выпустить обновление, а не только понять структуру папок.
6. Релизы и магазины: общей публикации не бывает
App Store и Google Play остаются отдельными контурами независимо от технологии. Нужны аккаунты, подписи, сборки, карточки, сведения о конфиденциальности, проверка платежей, управление версиями и ответы на замечания. Правила меняются: Apple прямо называет App Review Guidelines живым документом и возлагает на разработчика ответственность за сторонние SDK. Поэтому соответствие магазинам требует постоянной работы, а не одного последнего дня проекта.
На 3 августа 2026 года есть две особенно наглядные границы. С 28 апреля Apple принимает новые загрузки для iOS и iPadOS только со сборкой на SDK 26 или новее. А с 31 августа Google Play потребует от новых мобильных приложений и обновлений целевой уровень Android 16, то есть API 36; для доступности уже опубликованных мобильных приложений новым пользователям действует отдельное требование API 35. Кроссплатформенный фреймворк не отменяет Xcode, целевой API, две сборки и повторную проверку устройств.
Кроссплатформенность особенно полезна, когда продукт хочет выпускать одну функцию на обеих платформах почти синхронно. Нативный подход удобнее, когда iOS и Android развиваются разными темпами или получают разные возможности. Представьте, что партнёрский SDK доступен на Android раньше. Общий интерфейс всё равно должен скрыть функцию на iOS, аналитика должна различить ветки, а поддержка должна объяснить разницу пользователям.
План выпуска включает внутреннее тестирование, поэтапное развёртывание, возможность отката серверной функции и удалённые переключатели. Они уменьшают цену ошибки, но не заменяют проверку сборки магазина.
7. Тестирование и наблюдаемость: общий код не равен общему результату
Проверка бизнес-правила может быть общей. Но клавиатура, разрешения, системные диалоги, уведомления, ссылки, фон, обновление поверх старой версии и восстановление после выгрузки приложения проверяются отдельно. Добавьте разные размеры экранов, версии ОС и производителей Android, и станет ясно, почему обещание «тестируем один раз» создаёт долг.
Наблюдаемость означает, что команда видит падения, зависания, сетевые ошибки и шаги критичного сценария с разрезом по версии приложения, ОС и устройству. Для нативных исключений полезно отдельно отмечать версию SDK и результат вызова. Иначе общий экран маскирует две разные причины сбоя.
Минимальный контур приёмки строят от риска: реальные устройства для критичных интеграций, автоматические проверки общего поведения, платформенные сценарии и ручная проверка того, что нельзя надёжно автоматизировать. Количество тестов не заменяет покрытие самого дорогого отказа.
8–9. Общий код и цена исключений
Полезно делить продукт на три слоя. Первый включает действительно общие правила: расчёты, валидацию, модели данных, сетевые контракты. Второй включает интерфейс, который может быть общим, но адаптируется к платформе. Третий включает системные интеграции и сборку. Например, расчёт цены можно проверить один раз, а запуск сканера и возврат из системного окна нужно принять отдельно на iPhone и Android. Чем яснее границы, тем проще заменить библиотеку, протестировать сбой и оценить перенос.
Ошибка начинается с цели «максимизировать процент общего кода». Команда заталкивает в общий слой условные ветки, хотя две маленькие нативные реализации были бы понятнее. Цель должна быть другой: уменьшить полезное лишнее дублирование, не пряча различия платформ. Иногда повтор отдельной функции становится осознанной платой за независимость и ясность.
У исключения должен быть контракт: входные данные, результат, ошибки, запасной путь, ответственный и тесты. Если исключение касается критичной функции и у команды нет подтверждённой реализации, в матрице ставят ?, а не оптимистичный плюс. Дальше делают небольшой технический прототип только для этого риска.
10. Полная стоимость, миграция и срок жизни продукта
Полная стоимость владения включает не только первую разработку. Сложите проектирование, две сборки, серверную часть, дизайн, тестирование, магазины, аналитику, поддержку пользователей, обновления фреймворка и SDK, устранение уязвимостей, обучение команды и возможный перенос. Сравнивать варианты можно лишь на одинаковом составе функций и горизонте. Универсальный процент экономии здесь был бы выдумкой.
Представьте два работающих приложения на Swift и Kotlin с понятными владельцами и стабильными релизами. Полная переделка ради одного репозитория не добавит клиенту новой возможности, зато потребует заново пройти навигацию, интеграции и тесты. Первый вопрос здесь простой: какую пользу получит человек после миграции?
Миграция редко означает «переключить технологию». Серверные контракты, знания о продукте и часть дизайна сохраняются. Интерфейс, навигацию, управление состоянием, нативные интеграции, сборки и значительную часть тестов переносят или переписывают. Поэтому условия выхода фиксируют заранее: например, критичный SDK перестал поддерживаться, платформы получили разные планы или стоимость нативных исключений стабильно превышает пользу общего слоя.
Для более широкой оценки бюджета полезна статья о составе стоимости мобильного приложения: она помогает не потерять сервер, аналитику, публикацию и сопровождение, когда сравнение технологий сузилось до часов разработчиков.
Power: общий код не отменяет интеграцию и тестирование
В публичном плане продукта Power на 6–26 апреля 2026 года мы разделили работу на четыре видимые части: дизайн 6–12 апреля, Flutter-разработку 13–19 апреля, отдельный интеграционный день 19 апреля и тестирование со стабилизацией 20–26 апреля. План не доказывает универсальный срок. Он показывает полезный принцип: общий продуктовый слой должен закончиться проверяемой сборкой, а интеграция и исправления остаются отдельной работой.
Попросите показать те же границы в своей оценке: где заканчиваются экраны, когда проверяются устройства и SDK, кто принимает сборки для каждой платформы и когда исправляются найденные ошибки. Если всё спрятано в одном блоке «разработка приложения», календарь не объясняет, как команда доведёт общий код до двух рабочих релизов.
Взвешенная матрица: как получить решение, а не красивую сумму
Сначала бизнес ставит каждому критерию вес от 1 до 5: единица почти не влияет на успех, пятёрка означает, что провал блокирует продукт или релиз. Затем команда оценивает пригодность каждого подхода от 1 до 5. Единица означает высокий риск, тройка требует проверки или оговорок, пятёрка обозначает прямой и контролируемый путь. Вес принадлежит продукту, а оценка должна опираться на прототип, аудит SDK, измерение или план команды.
Универсальные баллы здесь только создадут ложную точность. Сначала ответьте на вопросы ниже, а затем поставьте оценки для нативного подхода, Flutter, React Native и веб-оболочки применительно к своему продукту.
| Критерий | Вопрос перед оценкой | Чем подтвердить ответ |
|---|---|---|
| Пользовательский опыт | Какие действия должны быть привычными именно для iOS или Android? | Интерактивный прототип и проверка ключевого пути |
| Скорость критичного пути | Где задержка или рывок делают продукт неудобным? | Замер на самом слабом целевом устройстве |
| Оборудование и API | Какие камеры, датчики, Bluetooth-, NFC- или платёжные функции обязательны? | Прототип с реальным устройством и SDK поставщика |
| Фон и жизненный цикл | Что должно продолжаться после блокировки экрана или перезапуска? | Тест ограничений батареи и фоновой работы на обеих ОС |
| Команда и ответственность | Кто исправит нативный модуль и выпустит срочное обновление? | Названный ответственный, нужные навыки и план замены |
| Релизы и магазины | Должны ли платформы выпускаться и откатываться независимо? | План публикации, отката и работы с замечаниями магазинов |
| Тестирование и ошибки | Какие устройства и версии систем создают основной риск? | Матрица устройств, журнал сбоев и тест критичного пути |
| Общая часть и исключения | Какие правила действительно общие, а где код начнёт расходиться? | Карта модулей и список платформенных исключений |
| Полная стоимость | Сколько стоят разработка, два релиза, тесты, поддержка и зависимости? | Две сметы на одном составе функций и горизонте поддержки |
| Миграция и срок жизни | Какая зависимость может вынудить команду переписать часть продукта? | Карта зависимостей, границы модулей и план выхода |
Шкала оценки: 1 означает высокий риск. При 3 путь возможен, но нужна проверка или оговорка. Оценка 5 означает прямой и контролируемый путь. Знак ? ставят, если доказательств пока нет.
Для каждого варианта посчитайте сумму вес × оценка. Но сначала примените правило стоп-фактора: провал по критичному требованию нельзя перекрыть несколькими пятёрками по желательным пунктам. Например, удобный найм не компенсирует невозможность надёжно работать с обязательным устройством. Правило неизвестного: знак вопроса по критичному критерию останавливает выбор до прототипа. Команда заранее записывает, какой результат превратит ? в оценку от 1 до 5.
Уберите варианты со стоп-фактором, затем сравните суммы оставшихся. Если два подхода близки, не округляйте в пользу любимого фреймворка. Назначьте следующую дешёвую проверку: прототип интеграции, тест на устройстве, аудит библиотеки или разговор с человеком, который будет отвечать за релизы.
Когда приложение не нужно
Представьте услугу, которой клиент пользуется один раз в год: открыть ссылку, заполнить короткую форму и получить документ. Установка, регистрация, место на телефоне и обновления добавят препятствия, а не ценность. Адаптивный сайт сохранит прямой вход из поиска и сообщения.
PWA подходит части веб-сценариев с установкой и ограниченной работой без сети. Telegram Mini App может быть рациональнее, если аудитория уже приходит из Telegram и сценарий не требует глубокой системной интеграции. Портфолио 13FOX показывает, что одну задачу можно решать мобильным, веб- или Telegram-форматом. Сначала сравните эти варианты: продукт не обязан начинаться с приложения. Полезно также спросить, можно ли проверить спрос веб-версией или служебным прототипом. Материал о разработке приложения под ключ поможет оценить весь процесс, если регулярный мобильный сценарий всё же подтверждён.
Не делайте приложение ради присутствия в магазине. Оно оправдано, когда установка улучшает повторяющееся действие: уведомления, работа без сети, камера, геолокация, оборудование или быстрый персональный доступ.
Официальные источники
Платформенные сведения сверены 3 августа 2026 года. Перед проектированием и релизом проверяйте актуальные версии первичных документов.
- Поддерживаемые платформы Flutter и официальный обзор архитектуры Flutter.
- Платформенный код React Native и официальное руководство по нативным модулям.
- App Store Review Guidelines, требования к загрузке в App Store и Apple Human Interface Guidelines.
- Руководство Android по фоновой работе и официальная дизайн-система Material 3.
- Требования Google Play к целевому уровню Android API.
FAQ
Что лучше: нативное или кроссплатформенное приложение?
Универсального победителя нет. Кроссплатформенный подход обычно силён, когда iOS и Android решают одну задачу, а системные исключения известны и ограничены. Нативный подход чаще оправдан, когда одна платформа приоритетна, привычное для неё поведение составляет ценность продукта или критичный сценарий глубоко зависит от камеры, Bluetooth, NFC, видео, фона либо новой функции системы.
Кроссплатформенная разработка всегда дешевле?
Нет. Она может уменьшить дублирование интерфейса и бизнес-логики, но не отменяет две сборки, магазины, устройства, системные разрешения, тестирование и сопровождение сторонних наборов инструментов. Сравнивайте полную стоимость владения на одинаковом составе функций, включая отдельную работу для iOS и Android, обновления и возможную миграцию.
Как выбрать между Flutter и React Native?
Сначала проверьте продуктовые ограничения, а затем соответствие команды и экосистемы. Для критичных интеграций сравните зрелость библиотек, возможность написать собственный нативный модуль, наблюдаемость ошибок и план обновлений. Выбор языка или популярность фреймворка не заменяют технический прототип самого рискованного сценария.
Когда нужен технический прототип перед выбором технологии?
Прототип нужен, если в матрице есть знак вопроса по критичному сценарию: фоновая геолокация, Bluetooth, NFC, камера, видео, карты, платёжный набор инструментов, системный виджет или жёсткое требование к задержке. Проверяют не демонстрационный экран, а конкретный риск на целевых устройствах и версиях операционных систем.
Можно ли начать кроссплатформенно, а затем перейти на нативную разработку?
Можно, но переход не бесплатен. Сохраняются серверная часть, продуктовые знания, дизайн и иногда отдельные библиотеки, однако интерфейс, навигацию, состояние, интеграции, сборки и тесты часто приходится переносить. До старта зафиксируйте границы модулей и условия, при которых миграция станет рациональной.
Когда мобильное приложение вообще не нужно?
Если человек редко выполняет короткое действие, а продукту не нужны глубокие системные функции, работа без сети или постоянный значок на экране, сайт, PWA или Telegram Mini App могут быть проще. Приложение оправдано не фактом публикации в магазине, а регулярным сценарием, который действительно выигрывает от установки.
Сравним подходы на вашем самом сложном сценарии
Что прислать: список функций первой версии, целевые платформы и устройства, обязательные наборы инструментов поставщиков, требования к фону, работе без сети, скорости и ритму релизов.
Что получите: на первой встрече мы заполним веса, отделим общее ядро от работы для отдельных платформ и обозначим вопросы для прототипа. Результатом станет сопоставимая карта вариантов со стоп-факторами, рисками и следующими проверками. Если задачу разумнее закрыть сайтом, устанавливаемым веб-сервисом, Telegram Mini App или одной платформой, мы скажем об этом до большой разработки.