Привет, Хабр. Мы уже сравнивали натив и 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)


  1. supercat1337
    01.11.2024 09:01

    Кроссплатформу/натив вместе с web view не рассматривали? В этом случае можно будет отображать UI довольно легко и использовать возможности устройства.


    1. Clevertec_dev Автор
      01.11.2024 09:01

      Да, рассматривали и делали сами. Действительно решает проблему доступа к возможностям устройства, но остается вопрос со сторами. В контексте этого сравнения он важен


      1. Pavel_SD
        01.11.2024 09:01

        Подскажите пожалуйста, что за вопрос со сторами?


        1. Clevertec_dev Автор
          01.11.2024 09:01

          Для компаний, потерявших доступ к сторам, важный момент, что PWA нигде публиковать не надо. Вообще про сторы еще будут подробности в следующей части, или можно посмотреть на доске уже сейчас. Ссылка есть в тексте


  1. gmtd
    01.11.2024 09:01

    У вас нет этой Миро доски в текстовом варианте?


    1. Clevertec_dev Автор
      01.11.2024 09:01

      В общем-то эта статья и есть текстовый вариант брейншторма, зафиксированного на доске


  1. gmtd
    01.11.2024 09:01

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

    А почему вы так уверены? У меня иной опыт (native <=> PWA).

    А вообще, мне кажется, нужно отталкиваться от необходимого функционала. Если доступ к мобилке нужен, только натив. Если нет - только PWA или webview на ней. Будущее Flutter слишком туманно, а текущий функционал слишком не очень.


    1. Clevertec_dev Автор
      01.11.2024 09:01

      мне кажется, нужно отталкиваться от необходимого функционала. 

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


  1. AuToMaton
    01.11.2024 09:01

    На этапе идеи и сбора требований может быть важно показать или попробовать прототип, а то и десяток прототипов. Тут преимущество у КП и PWA.

    Зачем искать специалистов по Dart? Их можно подготовить быстрее чем за неделю. Может быть имелись в виду специалисты по Flutter? И тут вспоминается Delphi - всё хорошо пока что-то не хорошо и нужно выходить за пределы. Так что в большой группе, где есть специалисты по нативу, хотя бы двое, Flutter много лучше чем в малой где их нет. И с PWA то же самое.

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

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

    Натив имеет преимущество в том, что конкуренция между командами может улучшать итоговый результат.

    Если вдруг вспомнить что кроме Андроид, iOS и PWA есть ещё Windows, macOS и Web, то статью стоит перечитать. Ничего принципиально не изменится, но восприятие весов факторов поплывёт. Да и КП, особенно не Flutter, может побочным продуктом давать PWA.


    1. HemulGM
      01.11.2024 09:01

      И тут вспоминается Delphi - всё хорошо пока что-то не хорошо и нужно выходить за пределы

      Можно развернуть тезис?


      1. AuToMaton
        01.11.2024 09:01

        И Flutter и Delphi

        • Требуют изучения языка мало применяемого ещё где-то.

        • Имеют собственную систему элементов управления.

        • Включают в себя много компонентов или библиотек или как кому угодно.

        • Позволяют написать много неплохо работающих приложений.

        • При необходимости выйти за пределы необходимо изучить натив.

        Иными словами, рано или поздно выясняется - приходится знать и Delphi или Flutter, и натив, и технику связи между нативом и Delphi или Flutter. То есть натив нужно знать на уровне, на котором и Delphi и Flutter просто не нужны. Тогда зачем тратились силы?

        В обоих случаях есть случаи когда либо выходить за пределы не нужно, либо проблема решается путём привлечения разных специалистов. История Delphi общеизвестна…


        1. HemulGM
          01.11.2024 09:01

          Так, если речь идёт о прототипе, то вряд-ли потребуется выход за пределы. В то же время, если для pwa потребуется выйти за пределы, то у вас вообще мало что получится.