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

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

Что значат эти слова на практике

• Нативная разработка — два отдельных приложения: для iOS на Swift, для Android на Kotlin. Две кодовые базы, обычно две команды или как минимум два профильных разработчика. Каждое приложение использует родные инструменты платформы.
• Кроссплатформенная разработка — одна кодовая база, из которой собираются приложения для обеих платформ. Самые распространённые инструменты — Flutter и React Native. Большая часть логики и интерфейса пишется один раз.
• Промежуточный вариант — общая бизнес-логика и раздельный интерфейс. Так работает, например, Kotlin Multiplatform: расчёты, работа с сервером и данными пишутся один раз, а экраны — родными средствами каждой платформы.
• Отдельно стоит PWA — веб-приложение, которое устанавливается на телефон из браузера без магазина приложений. Это уже не мобильная разработка в строгом смысле, но для части задач она закрывает потребность; подробно — в статье PWA: приложение без App Store.

Где нативная разработка действительно выигрывает

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

• Тяжёлая графика, анимация и игры, работа с камерой в реальном времени, дополненная реальность.
• Глубокая работа с железом: Bluetooth-устройства, датчики, фоновая геолокация с точными требованиями к расходу батареи.
• Функции, которые платформа выпускает первой: виджеты, новые системные интеграции, специфические возможности часов и других устройств. В нативе они доступны сразу, в кроссплатформе — когда появится поддержка в инструменте или пока кто-то не напишет мост.
• Продукты, для которых приложение — и есть бизнес, с большой аудиторией и командой, которая может содержать двух профильных разработчиков постоянно.
• Требования к максимальному соответствию стилю каждой платформы: когда пользователи iOS и Android должны получить привычный именно им интерфейс до мелочей.

Где кроссплатформа — разумный выбор по умолчанию

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

• Приложение для клиентов сервиса: запись, заказ, история, бонусы, push-уведомления.
• Личный кабинет, который дублирует и расширяет кабинет на сайте.
• Внутреннее приложение для сотрудников: курьеров, мастеров, выездных менеджеров.
• MVP — первая версия для проверки гипотезы, когда важнее быстро выйти и собрать обратную связь, чем вылизать каждую анимацию.
• Проекты с ограниченным бюджетом на поддержку: одна команда вместо двух, одно исправление вместо двух.

Сравнение по пунктам, которые важны бизнесу

• Первая версия. Нативно — два приложения, значит, большая часть работы делается дважды. Кроссплатформенно — общий код плюс доработки под особенности каждой платформы. Разница в трудозатратах заметная, но не двукратная: дизайн, бэкенд, тестирование и публикация нужны в обоих случаях.
• Обновления. В нативе каждая новая функция проходит через две команды и выходит синхронно, только если вы это специально организуете. В кроссплатформе функция пишется один раз и выходит на обеих платформах одновременно.
• Ошибки. В кроссплатформе ошибка в общем коде проявится сразу везде, зато и исправляется один раз. В нативе ошибки живут независимо — иногда это плюс, чаще — двойная работа.
• Производительность. Для типового бизнес-приложения пользователь разницы не заметит. Для графики, сложных анимаций и работы с железом натив выигрывает.
• Найм и смена подрядчика. Нужны специалисты под конкретный стек: Swift и Kotlin или Flutter (язык Dart) либо React Native (JavaScript/TypeScript). Разработчиков на React Native проще найти среди веб-специалистов, потому что язык общий с сайтом.
• Зависимость от инструмента. Кроссплатформенный фреймворк — дополнительный слой между вами и платформой. Когда Apple или Google меняют правила, нативные приложения адаптируются напрямую, кроссплатформенные — через обновление фреймворка и библиотек.

Условный пример: как прикинуть разницу в трудозатратах

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

Вопросы, на которые стоит ответить до выбора

• Что приложение делает такого, чего не может сайт? Если ответ «ничего, просто хотим быть в сторе», возможно, приложение пока не нужно — сначала прочитайте разбор приложение или мобильная версия сайта.
• Нужна ли работа с камерой, Bluetooth, фоновой геолокацией или другими возможностями устройства? Если да — какие именно и насколько они критичны.
• Кто ваши пользователи: на каких телефонах они сидят, какая доля iOS и Android? Это видно в Метрике по посетителям сайта.
• Кто будет поддерживать приложение через год? Своя команда, подрядчик, фрилансер? Под какой стек вы реально сможете найти людей?
• Что будет с бэкендом? Приложение почти всегда работает с сервером: API, база данных, админка, отправка уведомлений. Это отдельная часть проекта, часто — самая важная.
• Как часто вы планируете выпускать обновления? Если продукт будет активно развиваться, стоимость каждого релиза важнее стоимости первой версии.
• Должно ли приложение работать без интернета? Офлайн-режим с последующей синхронизацией реализуем при любом подходе, но его сложность стоит обсудить заранее — это одна из самых дорогих частей мобильного проекта.
• Есть ли у вас веб-версия того же сервиса? Если кабинет на сайте уже написан на React, связка с React Native позволяет частично переиспользовать логику и людей; если сайта нет, это соображение не работает.

Что часто забывают при планировании

Независимо от выбранного подхода, приложение — это не только код экранов. В план и бюджет сразу стоит заложить:

• Серверную часть и API, через которые приложение получает и отправляет данные.
• Push-уведомления: настройку сервисов доставки, сценарии, сегментацию и правила, чтобы не превратиться в спам — с частотой и поводами для отправки, о которых договорились заранее.
• Аналитику: какие события считаем, как связываем установки с покупками.
• Публикацию в App Store, Google Play и RuStore: у каждого магазина свои правила проверки, требования к описанию и политике конфиденциальности. Проверка может вернуть приложение на доработку.
• Обработку персональных данных: если приложение хранит имена, телефоны и историю заказов, на него распространяются те же требования 152-ФЗ, что и на сайт.
• Поддержку после запуска: новые версии iOS и Android выходят каждый год, и приложение нужно проверять и обновлять под них.

Как выглядит жизнь после запуска при каждом подходе

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

В нативном варианте обе задачи уходят в две очереди — iOS-разработчику и Android-разработчику. Если один из них в отпуске или занят срочной ошибкой, раздел выйдет на одной платформе раньше, чем на другой, и половина клиентов какое-то время будет видеть разные версии. Тестировщик проверяет каждую платформу отдельно. Зато, если на iOS что-то пошло не так, Android это не задевает.

В кроссплатформенном варианте задачу делает один разработчик, одна сборка уходит в оба магазина, а тестирование сосредоточено на проверке особенностей устройств. Цена этой простоты — зависимость от фреймворка: раз в какое-то время приходится обновлять сам Flutter или React Native и библиотеки к ним, и такое обновление иногда занимает заметное время без видимой для бизнеса пользы. Это нормальная плата, но её стоит заранее включить в бюджет поддержки, а не удивляться ей.

Можно ли передумать потом

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

Типичные ошибки при выборе

• Выбирать по технологии, которую знает подрядчик. Если студия умеет только натив, она будет доказывать, что кроссплатформа плохая, и наоборот. Спросите, в каких случаях они сами отказались бы от своего стека.
• Считать только первую версию. Решение определяет стоимость каждого следующего обновления на годы вперёд.
• Переходить на натив «на всякий случай». Если в приложении нет требований, которые кроссплатформа не закрывает, вы платите за запас, который не понадобится.
• Выбирать кроссплатформу для продукта, построенного вокруг камеры, графики или устройств. Сэкономленное на старте уйдёт на обходные решения.
• Не обсуждать передачу исходников. Код, аккаунты разработчика в магазинах и ключи подписи приложения должны принадлежать вам — иначе обновить приложение без прежнего подрядчика не получится.

Короткий алгоритм выбора

• Сначала проверьте, нужно ли приложение вообще или достаточно хорошего сайта и PWA.
• Если приложение нужно — выпишите функции, которые завязаны на возможности устройства.
• Если таких функций нет или они стандартные (камера для фото, геолокация, уведомления), начинайте с кроссплатформы.
• Если есть тяжёлая графика, работа с железом или жёсткие требования к отзывчивости — рассматривайте натив или гибрид с общей логикой.
• В любом случае заложите бэкенд, публикацию, аналитику и поддержку — это не зависит от выбранного подхода.

Вывод

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