Привет! На связи Саша Ворожищев. Я руковожу направлениями Flutter и iOS в AGIMA. И сегодня хочу снова поднять вопрос о разнице между Cross-platform и Native. Каждый год технологии в мобильной разработке делают шаг вперед, и поэтому споры о том, какая технология лучше, вспыхивают с новой силой. В этой статье попробуем расставить точки над i: что и в каком случае использовать.
Что нужно знать о мобильной разработке
Первое, что важно сказать: я пишу эту статью не для разработчиков. Моя главная задача — рассказать проджект-менеджерам, бизнес-заказчикам, продакт-оунерам, какое приложение для какой цели подходит. Поэтому я собрал самую базовую, но самую важную для понимания информацию в один текст. Он поможет перед стартом проекта определить, какой тип приложения вам нужен.
А начну с азов. Существует три основных способа разработки мобильных приложений:
Для разработки под Apple на данный момент актуальны следующие технологии: UIKit, SwiftUI + богатый iOS SDK, язык программирования Swift и Objective-C. Для Android — Android SDK, Jetpack Compose; языки: Java 8, Kotlin.
К ним же относятся так называемые WebView — приложения, обернутые тонким слоем нативного кода, который использует SDK браузера для открытия веб-приложения. Они тоже распространяются через сторы. Для них актуальны классические веб-технологии — HTML, CSS, Javascript.
Сюда относятся такие представители, как Ionic или Cordova. Как правило, такие приложения отличаются ограниченным доступом к нативным возможностям устройства, низкой производительностью, неотзывчивым интерфейсом и достаточно сложной поддержкой готового продукта.
Но в этой статье про веб-приложения я говорить не будут. У нас другая цель.
К последним относятся:
При кросс-платформенной разработке мы в AGIMA используем Flutter, поэтому рассказывать я буду про него. Другими словами, в этой статье я сравниваю нативную разработку и Flutter.
Немного о Flutter
Технологию Flutter создали инженеры компании Google. Они собрали позитивный и негативный опыт всех существующих кросс-платформенных решений и вывели рецепт идеальной кросс-платформы:
Flutter-приложения пишутся на языке Dart. Он компилируется в нативный код той платформы, для которой готовится сборка. Поэтому UI-элементы, анимации, переходы между экранами работают так же хорошо, как работали бы в нативном приложении.
Flutter имеет доступ ко всем фичам поддерживаемых платформ. Технологии платформенных каналов позволяют обращаться из Dart-кода напрямую к открытым интерфейсам платформы: камере, GPS, сенсорам, файловой системе устройства и т. д.
- Нужно понимать, что иметь доступ к фичам и активно их использовать — разные вещи. Можно использовать камеру из Flutter, но разрабатывать развитый 3D-сканер на основе набора датчиков устройства на кросс-платформенной технологии нерентабельно. Это повлечет за собой разработку библиотек на нативной части, вследствии чего вместо использования только команды нативных разработчиков, которые занялись бы и интерфейсом, придется искать еще и команду Flutter-разработчиков.
Flutter-индустрия развивается. Это сказывается и на ситуации на рынке труда. Порог вхождения в технологию низкий: фреймворк относительно простой. Язык привычный: Dart — объектно-ориентированный язык, по синтаксису напоминает смесь Java и JS. Поэтому всё больше специалистов приходит во Flutter из смежных сфер: Android, iOS, Web.
Еще кейсы на платформе Flutter можно посмотреть тут.
Плюсы и минусы кросс-платформы
Главное преимущество Flutter — единая кодовая база. Благодаря этому у Flutter много плюсов:
На Flutter существуют и минусы, которые могут стать угрозой для бюджета на поздних этапах работ:
Плюсы и минусы натива
Как правило, старт разработки нативного проекта происходит медленнее, чем кросс-платформенного. Возможных причин несколько: загруженность, поиск хороших нативных разработчиков, радикально разные подходы к дизайну. Фича может иметь трудозатраты в 2 раза выше, чем при кросс-платформе. Одни и те же задачи ставятся по-разному, имеют разную сложность и требуют разных экспертиз.
При этом нативные приложения эффективнее работают с устройством, меньше весят, меньше потребляют оперативной памяти и батареи. Перечислю плюсы нативной разработки.
Поскольку технологии, используемые при разработке платформозависимых приложений, напрямую связаны с этой платформой, собственный нативный код имеет прямой доступ ко всем функциям операционной системы.
А более простое взаимодействие приложения с функциями мобильных устройств повышает общую производительность приложения. Особенно при представлении графического или мультимедийного контента.
Следовательно, создание нагруженных приложений с использованием нативного кода может снизить время отклика, вероятность сбоев и зависаний. Ниже представлены результаты теста с простым списком с изображениями. Видно, что нативное приложение выигрывает на фоне кросс-платформенных решений. На более новых моделях телефонов разница будет не такой значительной, но тенденцию можно видеть. Результаты остальных тестов тут.
Нативные приложения задумываются и разрабатываются, чтобы решать конкретные задачи на конкретной платформе. Это приводит к лучшему соответствию возможностей приложений аппаратным возможностям устройств, включая Bluetooth, NFC, камеру, GPS и т. д.
Это соответствие необходимо, когда приложение должно использовать такие данные, как физическое и географическое местоположение и др.
Поскольку нативные приложения напрямую интегрируются с мобильной операционной системой, воспринимая и используя все доступные возможности «железа», пользователи могут перемещаться по привычному интерфейсу без хлопот. Это приводит к положительному пользовательскому опыту (UX) и к стабильному повторному использованию.
К примеру, сейчас при большом количестве разных вариантов разрешений экранов смартфонов важно иметь приложение, оптимизированное под такой экран, чтобы пользователю было удобно этим приложением пользоваться.
Среди разработчиков нативная разработка — всё еще самый популярный способ создания приложений, поэтому собрать команду проще, чем на кросс-платформе. Ниже приведены данные из HH.ru на конец 2022 года по России. Как видно по скриншотам, даже при не самой тщательной выборке соискателей на нативную разработку гораздо больше, чем на Flutter.
Минусы нативной разработки:
Создание отдельных приложений под каждую операционную систему может продлить процесс разработки. Один и тот же программный код не может быть развернут на разных платформах, и программистам потребуется больше времени для преобразования и перезаписи кода. Это увеличивает затраты и время разработки.
Если компания хочет для каждой из платформ отдельные приложения, она будет вынуждена нанять дополнительных программистов-специалистов. Например, один разработчик будет сосредоточен на разработке приложений для iOS, а другой — для Android, что еще больше увеличивает расходы.
О технологиях и пользовательском опыте
Главный вопрос при выборе технологии, опыт какого качества необходим пользователю. И вот несколько критериев, влияющих на пользовательский опыт:
Стоимость разработки
Если проект несложный, то выбор кросс-платформенной разработки позволяет сэкономить как минимум в 1,5 раза, так как вы, по сути, разрабатываете не отдельные продукты для разных платформ, а один для всех. Но если проект разрастается, то весы начинают склоняться в другую сторону: нативная разработка может оказаться выгоднее.
- Усредненная «формула»: один Flutter-разработчик зачастую может выполнять задачи 2 нативных разработчиков (iOS, Android) в те же сроки. В свою очередь, если в приложении много нативных функций, бывает удобно сочетать нативную разработку (например, для библиотек) и Flutter (для создания единой логики и UI), либо вообще перейти на нативную разработку.
Еще выбор разработки на Flutter отлично подойдет для выпуска MVP для демонстрации и, при желании, сверстывания этой логики в Web-интерфейс.
Приведем ход разработки проекта без платформозависимых функций. Например, небольшой магазин или программа лояльности с каталогом. Представим, что один и тот же проект разрабатывают параллельно две компании с идентичными подходами к работе и квалификацией инженеров.
Конфигурации команд
| Вид | Кол-во дизайнеров | Кол-во разработчиков | Кол-во тестировщиков | Заголовок 5 | Заголовок 6 | Заголовок 7 | Заголовок 8 | Заголовок 9 |
|---|---|---|---|---|---|---|---|---|
| Native | 1 дизайнер | 3 Android 3 iOS | 1-2 QA | Нужен блок с табличкой для статей на вихре | Нужен блок | Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок |
| Flutter | 1 дизайнер | 4 разработчика | 1 QA | Нужен блок с табличкой для статей на вихре | Нужен блок | Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок |
Получается, что Flutter в этом примере экономит нам 45,6% на разработке, 70,5% на QA с учетом использования автотестов в обеих командах, а также 33,3% на дизайне приложения.
Конечно, проекты бывают разные. Где-то Flutter может сберечь 15% бюджета, а где-то до 50%. Кроме того, возможно календарное преимущество при проектировании, так как вам не нужно синхронизировать логику между платформами.
Резюме
В качестве резюме предлагаю простую схему, которая поможет определиться с технологиями.
А если вкратце, то вот: