PWA vs Native: где приложения для iOS и Android больше никогда не пригодятся

К прогрессивным веб-приложениям у разработчиков, бизнеса и пользователей все еще очень много вопросов о безопасности и технических возможностях. Но и адвокаты PWA не молчат. Так, например, Давид Хейнемейер Ханссон считает, что нативные мобильные приложения уже не обязательны для B2B-стартапов. Я Василь, СТО Clevertec. Мы с командой обсудили аргументы за и против PWA и делимся результатами с вами.

Кратко о понятиях

PWA – веб-сайт, который функционирует аналогично нативному приложению. Любой смартфон может запускать PWA из своего браузера.

Нативное приложение – мобильное приложение, которое разработано специально для операционной системы и в зависимости от нее устанавливается на смартфон из стора: Google Play Store, Apple App Store или другого.

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

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

Когда начали противопоставлять веб и нативные приложения?

Мысль о том, что web догонит и вытеснит приложения, появилась еще 16 лет назад. Стив Джобс презентовал идею веб-приложений, которые выглядят и ведут себя как мобильные приложения.

В начале 2010-х была мысль, что этот момент вот-вот настанет. Но натив только укреплял свои позиции.

Время пришло. К тому же год назад вышло обновление iOS с некоторыми существенными для PWA функциями. Для нас как для команды с опытом разработки финтех-приложений и мобильных банков это означает, что теперь мы можем делать (и делаем) PWA по функциональности и пользовательскому опыту практически неотличимые от натива.

Кстати, в феврале Apple здорово пошумели: объявили, что в iOS 17.4 отключат поддержку PWA для пользователей из Евросоюза. Это значило, что веб-приложения больше не смогут присылать уведомления и хранить данные пользователей. Правда уже в начале марта решение отменили из-за большого резонанса.

Находим и поясняем аргументы в пользу PWA

1. Деньги. Бизнес всегда считает затраты. Стоимость разработки прогрессивного веб-приложения будет примерно на треть меньше нативной разработки.

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

   Косвенный бенефит PWA – экономия сил и средств на управление командой. У нативных приложений их всегда две, потому что универсальных разработчиков для Android и iOS сейчас не найти. Управлять двумя командами и синхронизировать разработку между ними и серверной частью сложнее, чем работать с одной более однородной командой.

2. Доступ независимо от операционной системы

   Сейчас веб технологически вырос, и параллельно развивается тенденция на фрагментацию мобильных операционных систем. О разработке своих собственных OC говорят Xiaomi, Huawei. И эта фрагментация пойдет совсем не на руку нативу. 

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

   Про независимость от сторов скажем одной строкой. С одной стороны это плюс, с другой – может отпугивать пользователей, т.к. приложения не проверяются, как в сторах. 

3. Скорость обновления

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

4. Удобства для пользователя

   Технология предполагает, что на рабочем столе размещается PWA со своей иконкой. Это выглядит абсолютно как приложение. Пользователь даже не подозревает, что это самом деле веб.

   И еще PWA занимает на устройстве на порядок меньше места, чем нативное приложение. Сравните: PWA обычно “весят” единицы мегабайт, а мобильные приложения – десятки или даже сотни мегабайт.

Разоблачаем “узкие” места PWA

Адвокаты нативных приложений обычно выдвигают неоспоримые аргументы против PWA. Но мы поспорим и с ними.

Что насчет быстродействия?

Быстродействие действительно вызывало опасения. Технически PWA всё-таки медленнее натива. Но с современными устройствами эта разница практически незаметна для приложений банковского типа. Она, возможно, будет заметна на слабых девайсах, каких-то старых моделях, но на большинстве современных – нет.

Как быть с разницей UI/UX на разных платформах? 

Стайл-гайды по UX у Android и iOS разные, они предоставляют разный пользовательский опыт. И хотя сейчас платформы идут навстречу друг другу в этом плане, различия все же есть. Допустим, в Android есть жест “назад”, а в iOS – только “Домой”. Их не очень много, но они есть и пока это недостаток PWA. Который, кстати,  можно нивелировать. Это зависит от мастерства разработчиков. Любая кроссплатформенная технология, в том числе PWA, может мимикрировать. Она понимает, что работает на iOS, и перестраивает интерфейс в привычный для пользователя.

В PWA нельзя собрать данные пользователей

Для бизнеса было бы неплохо следить за пользователями, составить портрет, собрать дополнительные данные для маркетинговых целей. У PWA-приложений для этого действительно меньше возможностей по сравнению с нативным приложением. 

Но с другой стороны – больше возможностей для приватности. Здесь меньше средств для того, чтобы перехватывать пароли, подслушивать, без предупреждения отслеживать местоположения и действия пользователя, «портить» данные других приложений на устройстве. Это не очень очевидно, но технически именно так: зловредные приложения (вирусы, трояны) практически невозможны, и пользователи от этого выигрывают.

Могут PWA и натив работать в связке?

Попробуем поискать обход ограничений PWA, объединив его с возможностями мобильного приложения.

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

Это называют гибридным приложением. В нем совмещена часть преимуществ PWA и нативного приложения.

И что же, всем придется переходить на прогрессивные веб-приложения?

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

Переход – это инвестиция, и не маленькая. Но с прицелом в будущее. Если бизнес планирует существовать еще долго и развиваться, то скорее всего, это будет оправданно. Возможно, в этом случае можно будет убить нативное приложение и продолжать развивать только PWA. 

Сейчас мы не видим признаков, что натив по каким-то причинам потеснит PWA в отрасли банковских приложений

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

В каких случаях мы все-таки не рекомендуем PWA?

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

• Если вам нужно фоновое отслеживание. Некоторые особенности аппаратуры по-прежнему недоступны в PWA. Нельзя получить доступ к локации, микрофону, когда устройство заблокировано. Для приложений типа банковских это не ограничение, но, например, музыкальный плеер или навигатор сделать не получится. 

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

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

Долгое время это приложение существовало как нативное, потому что не было соответствующей веб-библиотеки. И это было сдерживающим фактором для развития. Сейчас нужная библиотека появилась, но до этого момента прошли годы. 

Но ни один бизнес не согласится ждать этого события в бездействии. 

Вместо вывода

Потому что вывод здесь, как и в любом сравнении технологий, не может быть однозначным. Какой путь выбрать – зависит от конкретных задач и особенностей бизнеса. 

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

А какие по-вашему перспективы у прогрессивных веб-приложений? Давайте обсудим.

Если интересная техническая сторона, наши разработчики уже рассказали:

• Web APIs, которые функционально приближают веб-приложения к нативным

• Playwright и Allure как хорошая практика для разработки веб-приложения