Кроссплатформенное или нативное приложение: что выбрать

Нативное приложение пишется отдельно для каждой платформы на её родных инструментах: для iOS — Swift, для Android — Kotlin. Кроссплатформенное пишется один раз на общем фреймворке и собирается под обе платформы. Самые распространённые фреймворки — Flutter и React Native. Выбор между подходами — один из первых технических вопросов проекта.

Как работает кроссплатформа

Flutter

Фреймворк от Google на языке Dart. Рисует интерфейс собственным движком, поэтому приложение выглядит одинаково на всех устройствах.

React Native

Фреймворк от Meta на JavaScript или TypeScript. Использует нативные компоненты платформ, а логика описывается в коде, похожем на веб-разработку с React.

Kotlin Multiplatform

Подход, при котором общая бизнес-логика пишется на Kotlin, а интерфейс может быть нативным для каждой платформы или общим.

Сравнение по критериям

Где кроссплатформа выигрывает

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

Где нативная разработка оправдана

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

Нативные модули

Кроссплатформенный проект не означает отказ от нативного кода. Если нужна функция, которой нет во фреймворке, разработчики пишут нативный модуль для каждой платформы и подключают его. Это нормальная практика, но таких модулей должно быть немного, иначе преимущество одной кодовой базы теряется.

Команда и рынок специалистов

Учитывайте, кого вы сможете нанять для поддержки. Если в компании уже есть веб-разработчики на React, им проще перейти на React Native. Flutter-разработчиков становится больше, но язык Dart используется в основном именно во Flutter. Нативных iOS- и Android-разработчиков нужно двое как минимум.

Как принять решение

1. Опишите ключевые функции и отметьте те, что требуют глубокой работы с устройством
2. Оцените, насколько важны плавность и соответствие стилю каждой платформы
3. Посмотрите на бюджет и сроки первой версии
4. Подумайте, кто будет поддерживать приложение через год-два
5. Попросите исполнителя сделать прототип самой сложной функции на выбранном фреймворке

Вопросы исполнителю до старта

Когда подрядчик предлагает конкретный подход, попросите обосновать его применительно к вашему проекту, а не в целом:

• какие функции из вашего списка потребуют нативных модулей и кто будет их писать;
• какие опубликованные приложения команда сделала на предлагаемом фреймворке;
• как организовано тестирование на iOS и Android, включая недорогие смартфоны;
• как часто команда обновляет фреймворк и зависимости в проектах, которые поддерживает;
• что придётся переделывать, если через несколько лет понадобится сменить подход.

Ответ «мы всегда так делаем» без привязки к вашим функциям — повод запросить второе мнение у независимого разработчика.

Ошибки выбора

Выбор нативной разработки «потому что так качественнее» для простого каталога, что удваивает расходы. Выбор кроссплатформы для приложения, построенного вокруг сложной работы с оборудованием, и бесконечные доработки нативных модулей. Фреймворк, который знает только один разработчик в команде.