iOS 11.3 поддерживает PWA, но…

внешний интерфейс iOS PWA
iOS 11.3 поддерживает PWA, но…

Увидел хорошую статью про PWA на медиуме, перевел и поделился с вами после работы

Рекламируйте мой блог как обычно:sangle7.com


оригинал:medium.com/@FIR too/Fat baby play-…

25 января Рики Монделло опубликовал твит, за которым последовалпримечания к обновлению бета-версии Safari 11.1Также упоминается в манифесте веб-приложения и сервисных работниках. , а это значит, что кроссплатформенное PWA становится реальностью, посмотрим, что изменится

Обновление 8 февраля: бета-версия 2 была выпущена, как и блог webkit.Блог о том, как сервис-воркеры работают на платформе, на основе этого блога, эта статья была дополнена некоторым содержанием.

Тестировать не просто

Тестировать эти новые функции на iOS непросто, потому что инструменты разработчика в Safari в настоящее время не позволяют нам видеть Service Workers на iOS, кроме того, MessageChannel, который позволяет нам общаться с Service Workers, также доступен на iOS. еще не существует. Тем не менее, я часами занимался исследованиями, и помимо некоторых ошибок, которые команда WebKit обязательно исправит в финальной версии, я сосредоточусь на сравнении PWA для iOS и PWA для Android.

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

18 месяцев назад (полтора года?), я опубликовалНе используйте метатеги iOS безответственно в своих прогрессивных веб-приложениях..Некоторые компании (такие как Twitter и Flipkart) в свое время обратили внимание на эти проблемы и либо удалили метатеги на iOS, либо исправили их.

Проблема тогда заключалась в том, что некоторые компании решили поддерживать домашний экран iOS через метатег Apple, и они даже не тестировали его и не осознавали разницу между PWA Android и iOS.

К сожалению, большинство проблем такие же, как я говорил 18 месяцев назад, с одним большим отличием: теперь вам не нужно подписываться на iOS через вкладки; iOS добавит поддержку манифеста веб-приложения, поэтому ваш PWA автоматически станет iOS PWA. Но Apple не ведет себя как Android в PWA, а это значит: Купертино, у нас проблемы.

Установленные программы, которые можно использовать только онлайн

Если вы установите PWA на домашний экран, сервис-воркеры будут зарегистрированы, но не будут работать, это связано с тем, что у сервис-воркеров нет веб-приложения в качестве клиента, поэтому не ожидайте, что в первой бета-версии Может работать в автономном режиме, но я думаю, что это должна быть ошибка, которая будет исправлена ​​в будущей бета-версии.

Недоступно в автономном режиме

Совершенно другие сервис-воркеры

Этот абзац добавлен 8 февраля.

Apple добавила Service Workers API, но представление Apple о том, как это работает и что мы можем с ним делать, отличается от того, что было раньше.Самая большая разница заключается в следующем:

«Чтобы сохранить только полезную для пользователя информацию о хранилище, WebKit удалит неиспользуемые регистрации сервис-воркеров через несколько недель. Кэши, которые не будут открываться через несколько недель, также будут удалены. Веб-приложения должны иметь возможность правильно обрабатывать отдельные кеш, записи в кеше и случай удаления Service Worker».
WebKit.org/blog/8090/me…

Это огромное изменение!В Chrome, Firefox, Samsung Internet и других браузерах регистрация сервис-воркеров никогда не будет удалена автоматически, мы можем использовать их в будущем, поэтому официально установка PWA позволит нам работать в автономном режиме в будущем. Но, по словам Apple, нет никакой гарантии, что Service Workers и кеши будут доступны в будущем. Не исключено, что пользователь вернется в веб-приложение «через несколько недель». Я знаю, что веб-приложения по-прежнему будут работать в сети, но тогда мы не можем гарантировать ключевую концепцию PWA: доступ в автономном режиме.

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

В мире Apple «через несколько недель» PWA перезагрузится с сервера и перерегистрирует новый Service Worker, повторно кэшированные файлы. Это огромная нагрузка для PWA, даже если пользователь устанавливает веб-приложение на рабочий стол, через несколько недель пользователь по-прежнему не может получить доступ к содержимому в автономном режиме, а видит только полноэкранное сообщение «Интернета нет».

также,Шаг Apple также ограничивает другие API-интерфейсы Service Workers., такие как фоновая синхронизация и веб-передача, основаны на постоянном состоянии регистрации Service Workers.

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

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

Хорошо, что по крайней мере у нас есть определение Service Workers и свободное место для хранения ответов в хранилище кеша. До 50 МБ на раздел. МиБ? Этоmebibyte, 50 МБ — это около 52,5 МБ. Раздел? Разделы — это новая концепция в Service Workers, связанная с фреймами. Если в вашем веб-приложении нет междоменных iframe, подойдет только один раздел (ваш домен и порт). Из соображений конфиденциальности Apple доработала спецификацию Service Workers, когда Service Worker регистрируется из междоменного iframe, создается новый раздел. Сервисные работники будут нести ответственность только за запросы от клиентов в том же разделе.

Я не думаю, что определение того, какими должны быть сервис-воркеры, изменилось. Было несколько дискуссий между командой Safari и командой Chrome (я опубликовал два года назадэта статьяВ то время я участвовал в некоторых из этих дискуссий в Твиттере), я думаю, это просто еще одна глава того же обсуждения. Apple не участвовала в обсуждении необходимости замены AppCache, и тут мы получаем результат: они пошли с другой реализацией.

PWA: атаки клонирования

Service Workers API доступен в Safari, HTTPS в веб-представлении (например, в браузерах приложений Chrome, Firefox и Facebook), на домашнем экране (Web.app) и в приложениях, добавленных в Safari View Controller (например, при нажатии на Twitter в iOS). связь).

Звучит хорошо, правда? Что ж, вот важная проблема: в Safari движок не разделяет Service Workers и кэш-хранилище в веб-представлении каждого приложения и в веб-приложении на домашнем экране, что означает, что пользователи могут иметь несколько копий всех файлов.

Вы можете подумать: эй, Макс, то же самое касается различных браузеров для Android (Chrome, Firefox, Opera, Samsung Internet, UC Web). Ну, вы правы, но есть другой вариант использования. В Android веб-представления ОС не поддерживают сервис-воркеры, а PWA на главном экране использует те же сервис-воркеры и кеш браузера, которому принадлежит значок. Кроме того, загрузка одного и того же веб-приложения в разных браузерах на одном и том же устройстве не является типичным вариантом использования Android.

Теперь предположим, что вы являетесь пользователем iOS и часто используете PWA, например Twitter Lite. Если вы явно хотите использовать его, вы можете открыть свой (псевдо) браузер, например Chrome или Firefox на iOS. Вы получите копию заявления. Предполагая, что вы добавите его и на главный экран, там будет вторая копия приложения. Поскольку в iOS вы не можете изменить браузер по умолчанию, если вы получаете ссылку на почту в Твиттере, вам нужно открыть ее в Safari, поэтому третья копия приложения «установится» на ваше устройство. это все? еще нет. Если вы используете Facebook или некоторые газетные приложения и другие приложения, которые дают вам возможность просмотра в приложении, когда вы нажимаете ссылку на свою учетную запись Twitter или Twitter, у вас будет еще одна копия! К счастью, Safari View Controller, по-видимому, разделяет Service Workers и кэши с Safari.

Три разных Service Worker одного и того же PWA на одном устройстве (их можно отличить по id), слева направо: Safari, Chrome и Facebook

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

Поддержка манифеста веб-приложения

Если у вашей HTML-ссылки есть манифест, Safari использует его вместо старых нестандартных метатегов apple-mobile-*. Здорово! Однако, что касается бета-версии 1, у нее также есть некоторые особенности поведения, которые вы, возможно, не ожидаете по сравнению с Android.

Начнем с того, какие свойства игнорируются (но это бета 1, я не знаю, какие свойства будут поддерживаться в будущем, а какие нет):

  • Имя приложения: значок может использовать только короткие имена
  • Цвета темы и фона: нет раскрашиваемой строки состояния и экрана-заставки.
  • Icon: Вчера я видел, что несколько авторов PWA были довольны тем, что их решение заработало после установки в их случае, что не совсем так. Значок взят из в большинстве настроек PWA, но не из манифеста веб-приложения. Я думаю, Apple исправит это в будущей бета-версии, я хочу, чтобы иконки были размером 120x120 и 180x180.
  • Ориентация экрана: не может быть заблокирована
  • Витрина: полноэкранный режим: он работает независимо (вы все еще можете получить полноэкранный режим с черной полупрозрачной строкой состояния, хотя теперь он помечен как устаревший)
  • Showcase: минимальный пользовательский интерфейс, который действует как стандартный ярлык для браузеров.

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

Кроме того, CSS Media queries для режима отображения работает правильно.

Область действия и связывание в автономном режиме

Объем манифеста отличается при создании ссылок с помощью элемента . Должна ли ссылка открываться в оболочке PWA или в браузере?

Браузеры Android обычно открывают URL-адреса в контексте PWA и открывают другие ссылки в браузере или на пользовательских вкладках. Если вы не укажете область манифеста веб-приложения, Android обычно использует папку манифеста в качестве области действия, что является ожидаемым поведением.

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

iOS перезагружает PWA каждый раз

К сожалению, ошибка (или функция?) веб-приложения Home Screen на iOS все еще существует. Всякий раз, когда вы покидаете PWA, вы теряете контекст, а когда пользователь возвращается, PWA загружается с нуля.

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

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

отсутствие способностей

К сожалению, канонические события баннера веб-приложения или манифеста, такие как установка приложения, не поддерживаются, поэтому вам нужно найти другой способ отслеживать его (вы можете использовать хэш start_url и navigator.standalone для отслеживания)

Как и ожидалось, нет поддержки веб-push-уведомлений, хотя сегодня push-уведомления находятся на грани смерти. Кроме того, нет поддержки фоновой синхронизации или Web Share API. Последнее досадно, потому что с точки зрения iOS использование нативной среды SocialKit должно быть простым.

Проблемы и ошибки UX

Как я уже говорил в своей предыдущей статье, у iOS есть некоторые отличия, такие как:

  • В iOS нет физической или логической кнопки или жеста «Назад». Он всегда должен предоставляться в пользовательском интерфейсе. Это означает, что вы не можете использовать механизм входа OAuth в качестве страницы верхнего уровня (не можете вернуться). Вот вам пример PWA для Twitter Lite, у меня нет возможности вернуться или отменить операцию. Даже если я ввожу свою электронную почту, я не могу снова попасть на страницу входа.
невозвратный твитер лайт
  • На iOS вы не можете использовать прозрачные значки, большинство PWA используют круглые значки на Android, а на iOS соответствующие прозрачные части будут черными, что не кажется хорошей идеей.
Иконки PWA при добавлении в iOS имеют прозрачный фон, несовместимый со стандартами iOS.
  • Ошибка строки состояния, которая, вероятно, существует уже пять лет на iOS, все еще существует. Если ничего не делать, исчезает строка состояния пользователя, ни часов, ни батареи, ни значка вайфай. Решение по-прежнему заключается в использовании метатега строки состояния, который теперь принимает белый, черный и черный полупрозрачный цвета в качестве цветов фона, обеспечивая более подходящее полноэкранное представление (обратите внимание, что он совместим с iPhone X). По какой-то неизвестной причине черная и черная полупрозрачность теперь помечены как устаревшие и будут удалены в будущем. Я думал, что цвет темы в манифесте будет иметь приоритет, но почему он должен быть белым, а не черным?
Сравните Tinder с метатегами и Twitter без метатегов, где значок в строке состояния не виден.

У нас все еще есть время, чтобы внести изменения

У Apple еще есть возможность внести некоторые изменения, чтобы сделать нашу жизнь проще. В то же время у нас также есть время, чтобы проверить наш PWA, например.

  • Значки: добавьте значки размера iOS без прозрачных краев.
  • Если есть какие-либо теги , вам нужно добавить кнопку «Назад» в интерфейс
  • Область действия в манифесте веб-приложения
  • Что делать, если вы просите пользователя выйти из приложения и вернуться, учитывая логику перезагрузки
  • Как побудить пользователей установить ваше приложение (подсказка по обновлению для поддержки iOS)
  • Как отслеживать установки PWA

Есть другие идеи? помнить вTwitterПодпишитесь на меня, я буду тестировать новые бета-версии и часто обновлять информацию.