Что нового появилось в Safari после обновления
Браузер Safari является самым популярным на всех устройствах Apple. Даже на Маках пользователи предпочитают использовать именно его, не устанавливая сторонние решения. Это как минимум положительно сказывается на времени автономной работы Макбуков, а как максимум — позволяет задействовать всю довольно богатую функциональность встроенного браузера. Вышедшие недавно операционные системы iOS 16.1, iPadOS 16.1 и macOS Ventura тоже привнесли в Safari новые функции.
А каким браузером на устройствах Apple пользуетесь вы?
❗️ПЕРЕД ЧТЕНИЕМ СТАТЬИ РЕКОМЕНДУЕМ ПОДПИСАТЬСЯ НА НАШ ДЗЕН
Для установки новой версии Сафари на Айфон, Айпад и Мак достаточно обновить систему. Если же вы хотите продолжить пользоваться macOS Monterey или macOS Big Sur на компьютере, то можете обновить только сам браузер без обновления системы. Смотрим, какие функции появились в Safari и все ли из них действительно полезны.
Safari 16 — что нового
Для обновления Safari до версии 16.1 в macOS Monterey и macOS Big Sur сделайте следующее:
- Перейдите в системные настройки.
- Выберите раздел “Обновление ПО”.
- Нажмите “Дополнительная информация” и установите новую версию Сафари.
Safari будет присылать аккуратное уведомление в правом верхнем углу экрана.
Что же нового появилось в браузере Apple, что его необходимо обязательно обновить? Первое и самое заметное — это Push-уведомления от сайтов. Теперь различные сайты и веб-приложения которые поддерживают эту функцию, могут отправлять вам уведомления, даже если браузер не запущен. Например, если на каком-то ресурсе вышла интересная статья, и вы разрешили ему отправку уведомлений, то браузер уведомит вас об этом, и будет достаточно просто перейти по ссылке и погрузиться в чтение.
❗️ПОДПИСЫВАЙТЕСЬ НА НАШ ТЕЛЕГРАМ-КАНАЛ, ЧТОБЫ НЕ ПРОПУСТИТЬ САМЫЕ СВЕЖИЕ НОВОСТИ
Эта функциональность уже давно есть в большинстве сторонних браузеров. Google Chrome поддерживает ее уже не первый год. Поэтому Apple здесь явно в роли догоняющих. Но лучше поздно, чем никогда. Дополнительно в настройках уведомлений появятся соответствующие параметры для каждого сайта, на котором они активированы. Push-уведомления в Safari используют ту же систему уведомлений Apple, что и все устройства компании, поэтому вероятность что-то пропустить будет минимальная.
Войти на сайт без пароля
Одной из самых интересных новых функций Сафари является Apple Passkey. В отдельном материале мы подробно рассказывали, что это такое, а потом тестировали ее на iPhone с iOS 16. Теперь эта возможность доступна на Маках и Айпадах. В двух словах напомню: Apple Passkey — это возможность логиниться на сайтах и в приложениях без использования пароля. В момент регистрации вы задаете логин для своей учетной записи и вместо пароля выбираете Passkey. Подтверждаете свою личность с помощью биометрии, и на компьютере, смартфоне или планшете создается ключ входа.
Apple Passkey — небольшая революция в мире безопасности.
При попытке зайти в вашу учетную запись сайт или приложение запрашивает к нему доступ. Вам достаточно просто воспользоваться Touch ID или Face ID, и идентификация будет пройдена. Не придется ничего вводить и бояться, что пароль будет забыт или утерян. Все хранится в связке ключей на всех ваших устройствах. Достаточно создать Passkey на смартфоне, и он автоматически появится на планшете или компьютере. Удобно? Мягко говоря, да.
Safari на iPad
Планшетная версия Safari тоже не обошлась без серьезных изменений. Так как центральной функцией iPadOS 16.1 стал Stage Manager, позволяющий с удобством расставлять окна приложений на экране планшета, то под него пришлось создавать дополнительный размеры окна Safari. Если на старых планшетах и предыдущих версиях iPadOS браузер имел следующие размеры:
Дополнительные размеры окон для Safari выглядят вот так.
- Полноэкранный.
- На половину экрана в режиме Split View.
- На ⅔ экрана в режиме Split View.
- На ⅓ экрана в режиме Split View.
- Плавающее окошко Slide Over.
❗️ПОДПИСЫВАЙСЯ НА ТЕЛЕГРАМ-КАНАЛ СУНДУК АЛИБАБЫ. РЕБЯТА ЗНАЮТ ТОЛК В КРУТЫХ ТОВАРАХ С АЛИЭКСПРЕСC
Теперь к этим размерам добавилось еще несколько специально созданных для комфортного использования Stage Manager. Если старые версии более прямоугольные, то при активации Постановщика окошки принимают квадратный вид. Но самое интересное, что растянуть Сафари на экран от края до края в таком режиме не получится. Все завязано исключительно на оконное использование.
Обновление Safari
Из менее заметного появилась поддержка анимированных изображений AVIF. Теперь многие сайты станут выглядеть намного живее и красивее. А для просмотра отдельных анимаций не придется устанавливать другой браузер.
Нажав на верхнюю кнопку, вы поделитесь только выбранным окном, а не всем экраном.
Для новых iPad Pro, представленных 18 октября в Safari 16.1, появилась эксклюзивная функция. Так как планшеты поддерживают использование Apple Pencil без касания экрана на расстоянии до 12 мм, то специально под это появился предпросмотр ссылок и активация анимаций при наведении на них карандаша.
❗️ПОДПИШИСЬ НА НАШ ПУЛЬС. БУДЕШЬ УЗНАВАТЬ ВСЕ НОВОЕ САМЫМ ПЕРВЫМ
Плюс ко всему, в macOS Ventura появилась возможность транслировать в приложения конкретное окно Сафари, а не полностью весь экран. Что делает использование такого способа демонстрации более безопасным. Никто не будет видеть, чем вы занимаетесь в других окнах или какие файлы размещены у вас на рабочем столе.
Обновление Safari до последней версии
Если для вашего устройства доступно обновление Safari, можно обновить macOS, iOS, iPadOS или visionOS, чтобы загрузить его.
Обновление Safari для Mac, iPhone, iPad или Apple Vision Pro
- Чтобы обновить Safari на Mac, обновите macOS.
- Чтобы обновить Safari на iPhone либо iPad, обновите iOS или iPadOS.
- Чтобы обновить Safari на Apple Vision Pro, обновите visionOS.
Обновление Safari для Windows
Компания Apple больше не предлагает обновления Safari для Windows или других операционных систем ПК. Safari 5.1.7 для Windows, выпущенная в 2010 году и теперь устаревшая, была последней версией, созданной для Windows.
Если на веб-сайте отображается сообщение, что браузер устарел
Если на веб-сайте указано, что Safari устарел, даже если используется последняя версия macOS, iOS, iPadOS или visionOS, возможно, проблема связана с веб-сайтом. Если вы уверены, что хотите использовать веб-сайт, обратитесь к его владельцу или разработчику за инструкциями касательно наиболее эффективного использования.
Оновлення Safari до останньої версії
Якщо для вашого пристрою доступне оновлення Safari, ви можете отримати його, оновивши macOS, iOS, iPadOS або visionOS.
Оновлення Safari для Mac, iPhone, iPad або Apple Vision Pro
- Щоб оновити Safari на Mac, оновіть macOS.
- Щоб оновити Safari на iPhone чи iPad, оновіть iOS або iPadOS.
- Щоб оновити Safari на Apple Vision Pro, оновіть visionOS.
Оновлення Safari для Windows
Компанія Apple більше не пропонує оновлення Safari для Windows або інших операційних систем ПК. Версія Safari 5.1.7 для Windows, випущена в 2010 році й тепер застаріла, була останньою, зробленою для Windows.
Якщо на вебсайті вказано, що ваш браузер застарів
Якщо на веб-сайті вказано, що браузер Safari застарів, хоча ви використовуєте останню версію macOS, iOS, iPadOS або visionOS, це може вказувати на проблему з веб-сайтом. Якщо ви впевнені, що хочете використовувати вебсайт, зверніться до його власника або розробника за інструкціями щодо найефективнішого використання.
Релизы Safari — это ад для разработчиков
На прошлой неделе выкатили Safari 16.4, и для нас это стало кошмаром. Мы разрабатываем браузерное приложение для создания игр под названием Construct. Ранние версии Safari 16.4 ломали открытие проектов, предпросмотр проектов и весь контент, опубликованный при помощи Construct, каждый раз по-разному. Я захотела поделиться своим опытом, чтобы пользователи, разработчики, регуляторы и сама Apple знали, через что нам пришлось пройти из-за, казалось бы, рутинного релиза Safari.
Разработчики большинства браузеров предоставляют предрелизные версии для предварительного тестирования. Например, ежедневно обновляются Chrome Canary и Firefox Nightly, кроме того, существуют более редкие dev- и beta-релизы. Apple предоставляет Safari Technology Preview (STP), но она совместима только с macOS, и не обновляется по какому-нибудь открыто опубликованному графику. Похоже, это происходит примерно раз в две недели. Предрелизные браузеры обычно довольно шероховаты и содержат очевидные проблемы, которые достаточно быстро устраняют. Однако когда они начинают переходить в состояние беты, необходимо присмотреться повнимательнее. Поэтому когда 16 февраля было заявлено о выпуске Safari 16.4 beta 1 (тоже без какого-либо публичного графика), мы начали присматриваться и обнаружили множество проблем.
Сбои открытия проектов
Проекты Construct хранятся в файлах zip; для их считывания мы используем популярную библиотеку zip.js, которая, в свою очередь, использует Compression Streams API (если он поддерживается). В Safari 16.4 добавили поддержку Compression Streams API, однако она почему-то оказалась несовместимой с zip.js, поэтому открытие проектов в Construct завершалось сбоями. Потенциально это означает, что многие случаи применения zip.js в вебе тоже поломаны.
Я надлежащим образом отправила issue 17 февраля. После неразберихи с тем, была ли эта issue дубликатом другой (она не была), инженеры Apple изучили и выявили проблему, после чего сказали, что её устранят к 27 февраля. В конечном итоге, неплохой ответ, к чести сотрудников Apple.
Затем 8 марта вышел Safari Tech Preview 165. В нём по-прежнему присутствовал баг. Релиз Safari 16.4 казался близким, но мы не знали точно, потому что его график был неизвестен. Что нам делать? Они внесли изменение, но проблема сохранилась? Или исправление ещё не внесено? Но почему они так поступили, если после исправления прошло уже больше недели? Должны ли мы предположить, что Safari будет выпускать сломанные потоки сжатия, и выпустить аварийный патч, чтобы обойти эту проблему? Они ведь не будут рисковать тем, что сломают для всех zip.js? Даже если мы это сделаем, мы не знали, сколько у нас осталось времени. Должны ли мы вместо этого ничего не делать и надеяться, что Safari 16.4 выпустят с работающим исправлением? Но тогда мы не узнаем, произойдёт ли катастрофа, пока версию браузера не выкатят. Это ужасная дилемма.
Я спросила, будет ли выпущено исправление в Safari 16.4, но инженер ответил мне про STP. К сожалению, это не было ответом на вопрос: нет никаких конкретных гарантий, что присутствующее в STP перейдёт в Safari 16.4.
В конечном итоге мы решили посмотреть, с чем выйдет Safari 16.4. Следует учесть, что во время событий, описанных в этом посте, мы не могли открывать большинство проектов в Construct. Также учтите, что единственный способ узнать, что же реально выпустят в версии браузера — это просто вручную тестировать каждый релиз Safari, то есть нам придётся тратить время на выяснение того, что Apple уже наверняка знает. После пары недель мучительного ожидания 23 марта вышел STP 166, а затем 27 марта наконец-то выкатили Safari 16.4. Между ними был всего один рабочий день. Что я могла сделать за этот день? Ничего: на пятницу и всю следующую неделю я взяла отпуск. Я никак не могла узнать, когда брать отпуск в свободное от релиза Safari время, потому что публичный график релизов отсутствует. Поэтому лично проверить, всё ли работает, я могла не раньше 3 апреля, через целую неделю спустя после всемирного релиза Safari 16.4. До этого момента я не могла быть полностью уверена, что наше ПО будет работать в Safari. К счастью, оно работало. Оно работало и в STP 166, хотя эта информация и не особо полезна.
Всех этих трудностей во многом можно было избежать, если бы Apple просто указала для issue версию, в которой она исправлена, как это делают другие разработчики браузеров. Небольшая доля прозрачности существенным образом изменила бы наше планирование.
Сломанный предпросмотр проектов
Следующей обнаруженной проблемой стало то, что предпросмотр проектов в Construct просто показывал пустой экран. Упс! Это тоже серьёзная проблема для нас. Я снова отправила issue. Инженеры Apple снова помогли в изучении и проделали хорошую работу. Я опущу подробности, потому что они очень сложны и не особо относятся к делу. Если вкратце, Service Worker важны для предпросмотра проектов в Construct, а мы случайно использовали баг Chrome, из-за чего наш Service Worker оказался поломанным в Safari 16.4. То есть в этом случае в проблеме на самом деле был виновен Google (Google, пожалуйста, устраните её), и решить её должны были мы.
Снова возникла ужасная дилемма, но на этот раз хуже: казалось, релиз Safari уже близок. На этот раз проблему определённо нужно решать нам. Сколько у нас есть времени? Это важный вопрос. У нас есть собственный график релизов Construct с бета-релизами для тестирования и стабильным релизом каждую пару месяцев, который мы выкатываем для всех. Если бы мы знали дату релиза Safari, то смогли бы сравнить графики. Если время есть, можно расслабиться и уделить время исследованию, а наше исправление попадёт к пользователям по обычному графику релизов до апдейта Safari. Но если Safari выпустят на следующий день, налицо экстренная ситуация: Construct поломан и мы должны исправить его до завтра, чтобы избежать недовольства пользователей! В этом и заключается разница между рутинным багом и экстренной ситуацией.
Разумеется, мы понятия не имели, что Safari не запланирована для релиза на следующий день. Некоторые сотрудники Apple пытались намекнуть нам о расписании, которого, очевидно, не могли раскрывать, но нам не удалось добиться ничего более конкретного, чем «скоро». Поэтому мы были вынуждены считать это экстренным случаем и действовать соответственно. Усугубляло ситуацию то, что разработка при помощи Service Worker сложна, у них есть различные трудности, из-за чего их сложнее кодить. Поэтому нам пришлось забросить другую работу, проделать сложную работу по экстренному графику, а затем сразу же выкатить её всем пользователям, что рискованно: что, если мы где-то ошиблись и сломали что-то другое?
Всего этого хаоса можно было бы избежать, если бы Apple просто опубликовала график релизов, как это делает каждый разработчик браузеров. Снова небольшая доля прозрачности позволила бы нам избежать множества проблем. К счастью, всё прошло хорошо и мы не сломали ничего другого, однако у нас возникла новая головная боль: похоже, Safari кэшировала старый скрипт Service иначе, чем другие браузеры. Я так и не разобралась, почему это происходило, но это создавало риск серьёзного ухудшения ситуации.
В конечном итоге, Safari 16.4 выкатили примерно месяц спустя. Мы могли бы работать спокойно. Экстренные действия были не нужны и оказались пустой тратой времени.
Поломан весь контент, опубликованный в Construct
Среди всего этого я упустила ещё более серьёзную проблему. Оказалось, что в Safari 16.4 все веб-игры, опубликованные Construct за последние несколько лет, оказывались сломанными.
Проблема заключается в том, что Construct использует OffscreenCanvas (если он доступен), чтобы выполнять игру в Web Worker для улучшения характеристик производительности. В Safari 16.4 добавили поддержку OffscreenCanvas, но только контекст «2d» — поддержки WebGL по-прежнему не было. Для рендеринга Construct требуется WebGL. Поэтому он видел, что OffscreenCanvas поддерживается, создавал воркера, создавал OffscreenCanvas, затем получал null для контекста WebGL, после чего происходит сбой и пользователь видел пустой экран. На самом деле, это была самая крупная проблема из всех. Из-за него ломался весь объём имеющегося веб-контента. Мы выпустили второй экстренный патч для исправления (снова пройдя через все эти хлопоты), но поскольку этот контент публиковался нашими пользователями по всему вебу в течение нескольких лет, обновлять его было практически невозможно. Он охватывал тысячи игр на сайтах наподобие itch.io, Newgrounds, Poki и нашем собственном; обучающие материалы, используемые компаниями; образовательные материалы, используемые учителями; интерактивные киоски в музеях… и так далее. Это всё ещё оставалось потенциальной катастрофой.
Это застало нас врасплох. Мы распознавали OffscreenCanvas, просто проверяя, задан ли он (то есть typeof OffscreenCanvas !== «undefined» ). Я не ожидала, что браузер выпустят с частью контекстов, и предполагала, что он будет иметь равенство со стандартным элементом . Почему бы этому не быть? В документации MDN ничего не говорится о несогласованной доступности контекстов. В 2018 году Chrome выпустил OffscreenCanvas со всеми контекстами. В 2022 году Firefox выпустил OffscreenCanvas со всеми контекстами. Впервые браузер выпустил несогласованную поддержку контекстов.
Apple заявила, что это, очевидно, допускается спецификацией, и что функциональность распознаётся ошибочно с нашей стороны. Прочитав соответствующую спецификацию, я всё ещё не могу сказать, будучи веб-разработчиком, а не программистом браузеров, очевидно ли то, что это допустимо. Но допустим, что так и есть, в конце концов, разработчики браузеров дольше изучают спецификации, чем большинство веб-разработчиков.
Во-первых, насколько я понимаю, цель спецификаций — сохранение веб-совместимости: в HTML Design Principles говорится, что нужно поддерживать существующий контент. Например, когда выяснилось, что имя нового метода flatten Array ломает веб-сайты, в спецификации его переименовали во flat , чтобы он ничего не ломал. Это демонстрирует, что спецификация отражает реальность веба, а не является оправданием её нарушения. Поэтому предлагаемое мной решение заключалось бы в том, что необходимо изменить спецификацию, указав в ней, что HTML canvas и OffscreenCanvas должны поддерживать одинаковые контексты. Это позволяет избежать проблемы веб-совместимости, с которой мы столкнулись (и, возможно, столкнулись остальные), да и во всём остальном кажется более целостным. Safari тогда следовало отложить реализацию OffscreenCanvas до того, как появится поддержка WebGL, и тогда бы весь соответствующий веб-контент продолжил работать.
Во-вторых, даже если спецификация признана корректной и авторы решат отказаться от её изменения, разве Apple не волнует веб-совместимость? Почему бы не отложить выпуск OffscreenCanvas, вне зависимости от того, что написано в спецификации? Это было бы прагматичным решением для повышения веб-совместимости. Можно было перенести релиз и потратить время на добавление поддержки WebGL. Я уверена, что большинство опытных разработчиков ПО делало что-то подобное за свою карьеру: на поздних этапах обнаружена проблема с новой фичей, поэтому ты отключаешь фичу, откладываешь её выпуск на следующий релиз по графику и тратишь освободившееся время на её правильную реализацию. Safari выпустила OffscreenCanvas на четыре года и шесть месяцев позже выпуска его полной поддержки в Chrome, но он при этом ломает большую часть контента; наверно, было бы лучше выпустить его четыре года и девять месяцев спустя после Chrome с полной реализацией, сохраняющей веб-совместимость? Зачем выбирать поспешный вариант, который что-то ломает? Я приложила максимум усилий, чтобы убедить Apple отложить выпуск, но мне просто расплывчато ответили, что фича, вероятно, будет выпущена без изменений.
На мой взгляд, это пример того, как Apple использует формальность, чтобы не менять свой график. Мы столкнулись с катастрофой, и чтобы избежать её, Apple достаточно было отложить выпуск одной из множества новых фич Safari 16.4. В конечном итоге, разработчики добавили специальную браузерную хитрость, обнаруживающую наш движок и отключающую для него OffscreenCanvas. Это действительно позволило нам избежать катастрофы с совместимостью. Однако всем остальным, кто сделал ту же ошибку, не повезло — хак браузера специально для нашего движка не спасёт их.
Личное примечание
В обычной ситуации я бы этого не сказала, но мне кажется, важно подчеркнуть масштаб проблемы. Лично для меня это были невероятно напряжённые несколько недель. Иногда меня тошнило от беспокойства, в том числе и вне работы. Неопределённость сводит с ума: возможно, произойдёт катастрофа, а может быть, всё будет в порядке. Я не знаю, что произойдёт, и не знаю, когда мы об этом узнаем. Каждый день в течение нескольких недель мог стать обычным днём или обернуться катастрофой, и мы никак не могли узнать, каким он будет, и даже не знали, какая из многочисленных потенциальных проблем будет причиной катастрофы. И хотя обычно всё не так плохо, предыдущие релизы Safari тоже вызывали подобные проблемы.
Мы всего лишь люди, и подобные ситуации влияют на нас. Должна сказать, что строила эту компанию более десятка лет, от работы на ноутбуках дома до успешного бизнеса с 250 тысячами активных пользователей ежемесячно. Я сталкивалась с катастрофами, критикой, недовольными пользователями, внезапными неожиданными сбоями серверов по праздникам, и так далее. Это может быть непросто, но ты справляешься с этим, как профессионал. Однако ситуация с релизом Safari стала одной из худших и самых стрессовых рабочих ситуаций. И самое раздражающее заключается в том, что всего этого можно было избежать: Apple могла бы внести очень простые изменения, избавившие бы нас от большей части стресса, однако она годами постоянно не вносит такие изменения.
Хочу подчеркнуть, что это не критика каких-то конкретных сотрудников Apple. Ни один человек из Apple не стал причиной этого стресса — я специально сказала, что многие из них хорошо делают свою работу, и у Apple нет недостатка в умных и трудолюбивых людях. Проблема заключается в политиках управления релизами Apple. Такие аспекты, как полное отсутствие прозрачности, вызывают большую долю неопределённости, и мне кажется, что именно эти корпоративные политики ответственны за стресс, которому подвергаюсь я и, вероятно, другие веб-разработчики. Моя единственная цель здесь в том, чтобы осветить реальность, с которой сталкиваются разработчики при работе с релизами Safari, и в том, чтобы попытаться повлиять на изменения в политиках Apple, которые, по моему мнению, влияют на это.
История релизов Apple
Релизы Safari обычно не настолько плохи, однако подобные вещи случались в прошлом и тоже вызывали большой стресс и хаос. Это показывает, что ничего не поменялось, и на самом деле ситуация даже усугубляется. Вот краткое описание предыдущих проблем, которые у нас возникали с Safari.
- iOS 11.2.2 ломала WebAssembly. Она ломала отдельные части Википедии, весь опубликованный контент Construct, а может, и что-то ещё. Большой части проблем можно было избежать простым отключением WebAssembly, чтобы всё откатилось к fallback. Вместо этого компания оставила его включённым, но поломанным до релиза iOS 11.3 несколькими месяцами позже. Тем временем Apple не предоставляла никакой существенной поддержки. Мы получили помощь только от инженера Википедии, который поделился обходным решением, которое они обнаружили.
- Safari 11.1 сломала MessageChannels таким образом, что это поломало Construct, из-за чего нам пришлось годами поддерживать обходные решения.
- Safari 14 выпущена с поломанным методом replaceChildren(), вызывавшим глитчи в Construct.
- Safari 14 поломала localStorage, а затем поломала IndexedDB
- Даже когда проблемы устраняются, это всё равно может вызывать стресс и неопределённость. Проблема с аудио в Safari 15 создавала риск поломки воспроизведения аудио во всём контенте Construct. Она была устранена до полного релиза Safari 15, но заранее Apple этого никак не подтверждала. Мне снова пришлось проверять всё самой.
- Баг с WebGL в Safari 15.0-15.4 приводил к рендерингу пустого экрана для части контента Construct. Проблему устранили в Safari 15.5, но нам так об этом и не сообщили, мы выяснили это, вручную проверяя каждый релиз Safari.
- Годами мы мечтали об едином открытом формате аудиофайлов, который воспроизводится во всех браузерах. WebM Opus почти готов: он поддерживается всеми браузерами, в том числе и Safari на macOS, но не поддерживается только в Safari на iOS и iPadOS. Это единственное препятствие для использования этого формата во всех браузерах, которое бы устранило существенные затруднения с поддержкой аудио в вебе. Однако непонятно, работает ли Apple над этим вообще; я создала issue примерно год назад, но чётко о намерениях компании так никто и не сказал.
- В Safari 16 есть проблема, в некоторых ситуациях ломавшая воспроизведение аудио в Construct. Похоже, никакого существенного ответа от Apple на неё не было, несмотря на то, что отчёт отправлен примерно полгода назад. Мы по-прежнему поддерживаем обходное решение, тоже вызывающее другие затруднения.
- Иногда issue пропадают в пустоту. Эта issue была отправлена около года назад, но вразумительной реакции от Apple не было. Сравните это с тем, как реагировали на схожую проблему Firefox, отчёт о которой был передан примерно в то же время.
Такие серьёзные проблемы возникают у нас только с Apple и Safari. Редко появляются подобные затруднения с какими-то другими разработчиками браузеров, а когда они возникают, то есть полная прозрачность относительно того, что с ними будут делать, так что мы можем строить планы.
Как решить эту проблему
Вкратце ответ будет таким: «поступайте так же, как другие разработчики браузеров». Ни один другой разработчик браузеров не создаёт таких серьёзных проблем, и по большей мере это вызвано их гораздо более совершенными процессами разработки для веб-разработчиков наподобие нас. Они включают в себя:
- Прозрачность: говорите разработчикам, в каких релизах будут выпускаться исправления багов, и публикуйте график релизов. Одно это позволит избавиться от огромной доли неопределённости.
- Обновляйте Safari независимо от ОС: Safari — единственный оставшийся браузер в отрасли, привязанный к своей ОС. Это ставит высоченный барьер перед обновлением Safari. Похоже, даже небольшой, но критичный апдейт вынужден ожидать следующего апдейта всей системы. Разумеется, это увеличивает время решения даже серьёзных проблем: вместо недель или дней требуются месяцы. Если бы команда разработки Safari контролировала собственный цикл релизов и разумно им управляла, то это существенно снизило бы влияние подобных проблем.
- Больше предрелизных опций тестирования: нужен эквивалент Chrome Canary и Firefox Nightly, обновляющийся ежедневно и независимо от ОС, способный быстро итеративно решать проблемы и подтверждать их устранение. И такая версия, и STP также должны быть доступны на iOS и iPadOS, поскольку сейчас единственный способ тестирования предрелиза Safari на iOS — это полный апдейт до бета-системы, что медленно и неудобно.
- Коммуникация: ошибки иногда случаются, и если проблемы вызваны поломками в Safari, Apple должна сообщать всем, что происходит, что она делает с этим, когда ожидается решение и что пока могут делать разработчики. Чаще всего ответом становится тишина, из-за чего складывается ощущение, что компании попросту плевать. Я подозреваю, что сотрудники Apple заботятся о решении проблем, но снаружи это часто выглядит плохо.
Заключение
В конечном итоге всё заработало. Но посмотрите на те усилия, которые нам пришлось предпринять просто для того, чтобы всё продолжило работать после рутинного релиза Safari. Возможно, со следующим релизом нам предстоит пройти через всё это снова, и со следующим после него тоже, и есть вероятность того, что рано или поздно кто-то что-то пропустит и мы снова столкнёмся с катастрофой… и когда я думаю об этом, меня снова начинает подташнивать.
Я хотела бы любить Safari. В нём используются отличные технологии. В последнем релизе выпущено множество крутых фич, от которых в обычных условиях я была бы в восторге. Очевидно, что у компании нет недостатка в талантливых сотрудниках, способных быстро разобраться в подробностях технической проблемы, и я хочу чётко заявить, что у меня нет никаких личных проблем ни с кем из Apple. Печально то, что я боюсь релизов Safari. Apple совершенно точно могла бы сделать их гораздо лучше. Процесс релизов ужасно поломан и оставался таким несколько лет. Во многих случаях сложности можно было бы устранить лишь небольшим вмешательством Apple. Однако компания упорно придерживается одного процесса и никогда не проявляла интереса в его изменении. А разработчики вроде меня проходят через ад разработки, решая возникающие в результате этого проблемы: необязательное нарушение нормальной работы, трата времени на выяснение того, что Apple уже знает, но не говорит нам, ощущение стресса и неопределённости из-за надвигающихся катастроф без возможности узнать, когда и что случится. На мой взгляд, это выглядит как политика пренебрежения разработчиками.
Я отчаянно хочу, чтобы Apple менялась. Я хочу, чтобы Safari был прекрасным браузером. Я хочу разрабатывать потрясающий контент, превосходно работающий в Safari. Я хочу обеспечивать сильную конкуренцию браузеров ради совершенствования веба. Откровенно говоря, я хочу, чтобы Apple поменялась и ради моего ментального здоровья. Если Apple не поменяется, то единственное, что мне останется — это уговаривать людей переходить на Chrome или Firefox и просить регуляторов заставить компанию поменять отношение. Несмотря на недавнюю юридическую активность, мне кажется, этот релиз показывает, что проблемы с релизами Safari усугубляются, а не уменьшаются; тем временем, Apple, похоже, больше заинтересована в борьбе с требованиям, чем в решении этих проблем. В конечном итоге мы окажемся в монокультуре Chromium, что будет плохо для веба и принесёт собственные проблемы. Но если это произойдёт, то я должна сказать, что на этом этапе я ни капли не буду жалеть об отсутствии необходимости иметь дело с релизами Safari.