Почему PWA еще не победили нативные приложения?

Кевин Бассет — основатель Progressier, программного инструмента, используемого более чем 5000 приложений для работы вне магазинов приложений.

На бумаге PWA — идеальная альтернатива нативным приложениям: одна кодовая база, мгновенные обновления, не требующие одобрения, отсутствие комиссий за встроенные покупки. Что не так?

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

Итак… Чего им еще не хватает в 2022 году? Почему они еще не стали форматом по умолчанию для приложений?

Проблема идентичности PWA

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

В 2022 году поведение по умолчанию по-прежнему заключается в том, чтобы искать приложения в Google Play или App Store. Как ни странно, установить приложение прямо с веб-сайта и быстрее, и удобнее. Но пользователи до сих пор не привыкли к этому без специальных подсказок и рекламных элементов.

В основе проблемы лежит вопрос доверия. Загрузка приложения из магазина означает, что соответствующая третья сторона (Google или Apple) подтверждает, что загрузка приложения безопасна.

Но вот в чем дело: PWA не нуждаются в одобрении Google и Apple… потому что они уже гарантированно безопасны — по задумке. PWA не может читать контакты вашего телефона, отправлять SMS от вашего имени или получать доступ к каким-либо функциям вашего телефона, которые могут раскрыть вашу личную информацию.

Ценностное предложение «магазина приложений» двоякое: логистика (установка вашего приложения на устройстве пользователя) и продвижение (увеличение количества людей, которые узнают о вашем приложении). Возможно, магазины приложений уже не так хорошо справляются с последним. А логистика установки PWA встроена в сам браузер.

В 2022 году вся парадигма магазина приложений становится избыточной.

Push-уведомления на iOS

Web Push is coming to Safari 16 on macOS Ventura. It sends notifications even if Safari is closed. Is built with the same web technologies as other browsers. Doesn’t require an Apple Developer Program membership. And is coming to iOS and iPadOS next year.https://t.co/XLX9oNtHWP pic.twitter.com/QqA6zniEQe

— Jen Simmons (@jensimmons) June 6, 2022

После многих лет, казалось бы, безнадежного ожидания, Apple наконец объявила, что веб push-уведомления появятся на iOS в 2023 году. Это отличная новость. До сих пор вы могли отправлять уведомления пользователям Android/Windows/macOS, но не пользователям iOS.

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

При условии, что Apple правильно реализует push-уведомления (например, в соответствии со спецификациями W3), ситуация вот-вот изменится. Вы сможете уведомлять пользователей как на Android, так и на iOS с минимальными усилиями — и без необходимости размещать свои приложения в Google Play и App Store.

При этом веб-разработчики настолько злоупотребляют Web Push API (например, новостные сайты запрашивают доступ при первом посещении), что люди стали ненавидеть эти подсказки. В результате в некоторых случаях Chrome (и другие браузеры) автоматически блокирует запросы на push-уведомления, из-за чего разработчикам с законными вариантами использования сложнее запросить доступ к этой функции.

Одним из главных пунктов в моем личном списке желаний было бы предоставление PWA более высокого авторитета, чем обычному веб-сайту, после установки (но не настолько, как нативное приложение). Привлечение людей к установке вашего PWA свидетельствует о том, что они ему доверяют — они не просто наткнулись на ваш сайт.

Несколько примеров того, во что может вылиться более высокий авторитет:

• Установленным PWA может автоматически предоставляться доступ к Push API.
• Ограничение доступа к Push API только для установленных PWA. Обычные веб-сайты вообще не смогут запрашивать доступ. Прощай спам.
• Объединение запросов к нескольким API-интерфейсам браузера в рамках запроса на установку. Например, при установке PWA сможет автоматически запрашивать доступ к Push API, API геолокации или API микрофона — с переключателями, позволяющими пользователям детально разрешать или запрещать каждый из них в отдельности.
• Или Chrome может просто автоматически не блокировать push-уведомления по запросу из PWA.

Собственная подсказка об установке в iOS

Установка PWA на iOS требует показа пользователям кастомных инструкций

В настоящее время для установки приложения на iOS требуется открыть панель «Поделиться» и нажать кнопку «Добавить на главный экран». В основном это работает, но это не так просто, как установка нативного приложения для iOS.

Если бы Safari реализовал поддержку события beforeInstallPrompt, процесс стал бы проще. Или, по крайней мере, Apple может изменить формулировку «Добавить на главный экран» на «Установить приложение» — Android сделал именно это несколько лет назад.

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

Например, невозможно отличить настоящий Safari (у которого есть кнопка «Добавить на главный экран») и представление SFSafariViewController (у которого ее нет). Для справки, последний используется рядом встроенных в приложения браузеров, например, iOS-приложением Твиттера.

В результате у вас нет другого выбора, кроме как показать свои пользовательские инструкции… даже если такой опции нет. Немного сбивает с толку пользователей, которые могут не увлекаться подобными техническими заморочками, то есть 99.99% пользователей.

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

Улучшенные обновления манифеста после установки

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

У Google есть целая статья об этом, но я сделаю для вас TL;DR: ни одно из свойств, которые вы действительно хотите изменить, не может быть изменено. Поэтому после установки вы не сможете обновить внешний вид приложения на домашнем экране пользователя.

По крайней мере, так было до недавнего времени.

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

Is this a new Chrome behavior for desktop installed PWAs? I guess that it may happen when the manifest change and Chrome tries to update the installed icon to reduce phishing attempts, but I'm not sure.

Even if that's the case, it doesn't seem right for this case anyway. https://t.co/QNTPZGnIO3

— Maximiliano Firtman (@firt) August 13, 2022

https://twitter.com/meduzen/status/1558432138067955713

Лучшее управление scope

Если и есть область, в которой PWA действительно сильны, так это программатик создание приложений.

Один из моих клиентов в Progressier — компания, занимающаяся разработкой коммерческого программного обеспечения для фотографов. Фотографы используют это программное обеспечение для создания уникальных свадебных галерей для своих клиентов.

С Progressier каждая из этих галерей представляет собой уникальное приложение со своим названием (имя молодоженов) и иконкой (фото пары). С 10,000 таких галерей было бы просто невозможно управлять этим каким-либо другим способом.

Однако не обошлось без нескольких узких мест и подводных камней.

Хотя обычно предпочтительнее размещать каждое PWA на собственном субдомене (например, pwa1.example.com и pwa2.example.com), часто это невозможно. В этом случае второй лучший вариант — разместить каждый в своем собственном каталоге (например, example.com/pwa1/ и example.com/pwa2/).

Управление областями действий (scope) очень нелогично из-за того, что я называю проблемой завершающей косой черты. В двух словах, example.com/pwa1/ является допустимым scope, а example.com/pwa1 (обратите внимание на отсутствующую косую черту) — нет.

Если вы используете последний вариант, браузеры вместо этого будут рассматривать область действия как example.com/ (корневой домен) — проблема в том, что даже нет сообщения об ошибке или предупреждения. Просто молча не работает.

Я бы хотел, чтобы браузеры были чуточку умнее и автоматически обрабатывали конечные слеши в scope. Они могли бы просто автоматически исправить example.com/pwa1 на example.com/pwa1/. Я не вижу случаев, когда первое не является ошибкой, а разработчик на самом деле имел в виду второе.

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

Скриншоты на десктопе

Старое приглашение на установку (слева и посередине) и новое приглашение на установку (справа)

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

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

Свойство screenshots манифеста приложения в настоящее время ничего не делает на десктопе, но есть правильное предложение также отображать эти скриншоты в десктопном  Chrome. Вы уже можете проверить это, используя флаг командной строки:

--enable-features=DesktopPWAsDetailedInstallDialog

https://twitter.com/alexey_rodionov/status/1547467531060883456

Как насчет нативных функций?

Должны ли PWA когда-либо получить доступ к вашим контактам? Просмотру календаря? Отправки SMS/MMS? Установки будильника? Лично я бы сказал, что не должны — никогда.

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

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

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

Если учесть тот факт, что каждый день на Bubble, Softr и других no-code платформах создается все больше приложений, кажется, что мы движемся именно в этом направлении.

Лично я считаю, что это отличная новость для разработчиков, пользователей и веба в целом.

Источник