Привет, Хабр. Мы уже сравнивали натив и 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 критически важен, это может стать сильным аргументом.
Впереди этапы тестирования, обновления и поддержки и самое интересное — оценка стоимости. Об этом расскажем в следующей части уже скоро.
Если ждать не хочется, мы собрали основные пункты сравнения на этой доске.
Мы с командой потратили не один час на обсуждение этих сравнений и немало спорили. Если хочется поспорить с нами — ждем в комментариях, призовем коллективный разум для ответа.
Комментарии (12)
gmtd
01.11.2024 09:01У вас нет этой Миро доски в текстовом варианте?
Clevertec_dev Автор
01.11.2024 09:01В общем-то эта статья и есть текстовый вариант брейншторма, зафиксированного на доске
gmtd
01.11.2024 09:01В то же время нативные приложения самые быстрые.
А почему вы так уверены? У меня иной опыт (native <=> PWA).
А вообще, мне кажется, нужно отталкиваться от необходимого функционала. Если доступ к мобилке нужен, только натив. Если нет - только PWA или webview на ней. Будущее Flutter слишком туманно, а текущий функционал слишком не очень.
Clevertec_dev Автор
01.11.2024 09:01мне кажется, нужно отталкиваться от необходимого функционала.
да, тут и не было идеи стать адвокатом чего-то одного. Везде свои плюсы и минусы, вес аргументов зависит от потребностей в конкретной ситуации
AuToMaton
01.11.2024 09:01На этапе идеи и сбора требований может быть важно показать или попробовать прототип, а то и десяток прототипов. Тут преимущество у КП и PWA.
Зачем искать специалистов по Dart? Их можно подготовить быстрее чем за неделю. Может быть имелись в виду специалисты по Flutter? И тут вспоминается Delphi - всё хорошо пока что-то не хорошо и нужно выходить за пределы. Так что в большой группе, где есть специалисты по нативу, хотя бы двое, Flutter много лучше чем в малой где их нет. И с PWA то же самое.
Не только натив должен учитывать гайдлайны, но и КП. При этом нативные разработчики делают это на автомате, проблема в том, что либо нативным разработчикам нужно доверять, либо очень грамотный специалист по интерфейсу делает больше работы.
В разработке натив проще всего. На каждой платформе средства разработки полируются многие годы и идеально (ладно, абы как но лучше альтернатив) подогнаны под неё. Сложности начинаются когда пытаются создать универсальных солдат и/или когда командам не доверяют и некий менеджер пытается в микроменеджмент.
Натив имеет преимущество в том, что конкуренция между командами может улучшать итоговый результат.
Если вдруг вспомнить что кроме Андроид, iOS и PWA есть ещё Windows, macOS и Web, то статью стоит перечитать. Ничего принципиально не изменится, но восприятие весов факторов поплывёт. Да и КП, особенно не Flutter, может побочным продуктом давать PWA.
HemulGM
01.11.2024 09:01И тут вспоминается Delphi - всё хорошо пока что-то не хорошо и нужно выходить за пределы
Можно развернуть тезис?
AuToMaton
01.11.2024 09:01И Flutter и Delphi
Требуют изучения языка мало применяемого ещё где-то.
Имеют собственную систему элементов управления.
Включают в себя много компонентов или библиотек или как кому угодно.
Позволяют написать много неплохо работающих приложений.
При необходимости выйти за пределы необходимо изучить натив.
Иными словами, рано или поздно выясняется - приходится знать и Delphi или Flutter, и натив, и технику связи между нативом и Delphi или Flutter. То есть натив нужно знать на уровне, на котором и Delphi и Flutter просто не нужны. Тогда зачем тратились силы?
В обоих случаях есть случаи когда либо выходить за пределы не нужно, либо проблема решается путём привлечения разных специалистов. История Delphi общеизвестна…
HemulGM
01.11.2024 09:01Так, если речь идёт о прототипе, то вряд-ли потребуется выход за пределы. В то же время, если для pwa потребуется выйти за пределы, то у вас вообще мало что получится.
supercat1337
Кроссплатформу/натив вместе с web view не рассматривали? В этом случае можно будет отображать UI довольно легко и использовать возможности устройства.
Clevertec_dev Автор
Да, рассматривали и делали сами. Действительно решает проблему доступа к возможностям устройства, но остается вопрос со сторами. В контексте этого сравнения он важен
Pavel_SD
Подскажите пожалуйста, что за вопрос со сторами?
Clevertec_dev Автор
Для компаний, потерявших доступ к сторам, важный момент, что PWA нигде публиковать не надо. Вообще про сторы еще будут подробности в следующей части, или можно посмотреть на доске уже сейчас. Ссылка есть в тексте