Битва титанов: натив, кроссплатформа и PWA — ищем плюсы и минусы на каждом этапе разработки

от автора

Привет, Хабр. Мы уже сравнивали натив и PWA в этой статье, но без кроссплатформы эта картина действительно была неполной. Поэтому мы запарились, разложили разработку на этапы и на каждом нашли честные плюсы и минусы каждой технологии. Погнали.

Дисклеймер о кроссплатформе

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

Дисклеймер о PWA

Мы в Clevertec работаем с финтехом, в том числе создаем банковские приложения: веб и нативные. В последние годы в нашей геозоне PWA стали мастхэвом для банков, которые столкнулись с проблемами в сторах. Мы сами разработали несколько PWA для банков, поэтому все аргументы добыты на практике.

Идея и сбор требований

Здесь ничем не удивим, но первый этап разработке нельзя скипнуть. Трудозатраты здесь одинаковы для всех технологий. Отличия, обусловленные спецификой платформы, обычно несущественны в масштабах основной функциональности.

Сбор команды

Натив. Пока выглядит так: нужны две команды, Android и iOS. Но Huawei, Xiaomi собираются создавать свои платформы и в обозримом будущем для таких случаев может понадобиться или больше команд, или дополнительные усилия со стороны одной из существующих, чтобы адаптировать приложение под новые потребности. 

Значит, и затраты будут возрастать. Это нужно учитывать.

Flutter. Команда разработки одна, но нужно учитывать, что это специалисты с Dart. Найти их оказалось сложнее, чем мы предполагали. 

В подтверждение собрали информацию на HH.RU о количестве разработчиков на рынке и средних зарплатах. Доступных спецов по Flutter в десятки раз меньше, и стоить они могут дороже остальных.

Кстати, с кроссплатформой на ReactNative будет проще: фреймворк похож на React, затраты на переобучение веб-разработчиков небольшие, даже если специфических специалистов нет.

PWA. Нужна одна команда веб-разработчиков. Причем независимо от фреймворка. Прогрессивное веб-приложение можно строить на любом. Поэтому такую команду собрать проще и она с большой вероятностью обойдется дешевле, чем Flutter.

Проектирование интерфейса

Натив должен учитывать гайдлайны платформы, и по-другому приложение не пропустят маркеты. То есть сама архитектура натива определяет интерфейс.

В то же время нативные приложения самые быстрые. 

Кроссплатформа и PWA в этом плане проще. Интерфейс проектируется один раз. И если Flutter все же должен учитывать особенности нативных платформ, то в вебе все компоненты общие.

Вместе с тем все не нативное — это выбор между упрощением кода и сохранением всех фишек пользовательского опыта. Что делать, например, с разницей жестов «домой» и «назад», которые понятны пользователям Android и iOS?

Тренд на унификацию пользовательского опыта уже заметен у гигантов. Мобайл и десктоп, натив и PWA уже сейчас вообще не отличимы, например у Вк, Х (экс Twitter).

Разработка

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

Кроссплатформа. Разработка намного проще, один код, общий пайплайн. Но уже меньше возможностей взаимодействовать с устройствами. Хотя и гораздо больший потенциал в этом, чем у PWA.

PWA. Все так же проще кодовой базой, но еще меньше возможностей в работе с функциями устройств. 

Но нет и не будет в ближайшее время:

  • фоновой работы (не получится воспроизводить медиа в фоне и отслеживать геолокацию, например)

  • возможности создать виджеты на рабочем столе

  • интеграции с нативными базами смартфона (мультимедиа, контакты)

Если примерить на наш опыт, то в банковских приложениях эти функции не критичны. А проблемы шеринга файлов и контактов, работы с камерой и другие успешно решаются с помощью Web API и хороших разработчиков. Статья об этом уже написана, загляните: Web APIs, которые функционально приближают веб-приложения к нативным.

Есть еще один вопрос — скорость разработки. Снова на практическом примере из финтеха.

С PWA реально выйти в релиз за 3–4 месяца. За счет скорости сбора команды, меньших усилий на тестирование и без ожидания проверок в сторах.

С нативными приложениями наш минимальный путь до релиза занимал 6 месяцев. Когда показатель time‑to‑market критически важен, это может стать сильным аргументом.

Впереди этапы тестирования, обновления и поддержки и самое интересное — оценка стоимости. Об этом расскажем в следующей части уже скоро.

Если ждать не хочется, мы собрали основные пункты сравнения на этой доске.

Мы с командой потратили не один час на обсуждение этих сравнений и немало спорили. Если хочется поспорить с нами — ждем в комментариях, призовем коллективный разум для ответа.


ссылка на оригинал статьи https://habr.com/ru/articles/855066/