Apple ищет способ дать сайтам больше места на внешнем экране iPhone Duo

Что произошло, почему это важно и что взять в работу.

Apple открыла публичное обсуждение ограничений верстки под внешний экран фолдера — разработчикам стоит заранее заложить адаптив под узкие и «обрезанные» панелями Safari вьюпорты.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

5,4 дюйма, из которых часть забирает Safari

Внешний экран iPhone Duo — 5,4 дюйма по диагонали. Маленький. И заметная доля этого маленького экрана уходит не сайту, а правой панели управления Safari. Сайт упирается в невидимую стену и дальше не растягивается.

Это не мелкая жалоба из тредов. Обзорщики заметили первыми, Apple признала следом. 23 октября 2026 года в посте про новшества Safari 27.1 Джен Симмонс из команды WebKit написала прямо: сейчас веб-страницы технически не могут выходить за панель управления на внешнем дисплее, и компания думает, как это исправить.

Для владельца бизнеса звучит далеко. На практике — очередная ступенька в длинной лестнице «адаптивность», по которой SMB спотыкается с 2010-х. Просто на этот раз её поставили не дизайнеры, а производитель устройства, и поставили публично.

Что именно сказала Apple

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

We would like to give web designers and developers the ability to design and use that space in more creative ways. Perhaps you want to extend your header background across the full width of the display, for example.

Дальше интереснее. Очевидный технический ход существует, и Apple его не принимает. Речь про метатег viewport с параметром viewport-fit="cover", который разрешает контенту заезжать под системные элементы. Компания называет такой путь рискованным: слишком много сайтов не размечают безопасные зоны и не учитывают safe-area, поэтому текст, кнопки и формы просто окажутся под панелью. Читаемо? Нет. Кликабельно? Тоже нет.

Вместо готового рецепта — приглашение к разговору. Apple ищет вариант «надёжнее и проще в использовании» и просит разработчиков присылать идеи. Обещает подробности позже. Сроков нет.

We are investigating if there’s a better way to accomplish the same result — something more foolproof and perhaps easier for you to use. If you have ideas, we’d love to hear them.

Как мы сюда приехали: короткая история вьюпорта

Верстка под чужой экран — старая боль. Сначала сайты рисовали под 960 пикселей и удивлялись, когда на телефоне всё разъезжалось. Потом появился адаптив и медиазапросы. В 2017 году Apple вырезала в экране вырез под камеру, и в CSS пришли переменные вида safe-area-inset — отступы, которые учитывают «мёртвые» края. Дизайнеры научились отодвигать кнопки от челки, но многие просто залили шапку цветом и забыли.

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

Apple, к её чести, на этот раз не выпускает API молча и не перекладывает шишки на рынок. Публичное обсуждение до реализации — редкий формат. Обычно сначала релиз, потом гневные посты, потом патч. Здесь наоборот.

Почему «просто включить cover» — плохая идея

Параметр viewport-fit="cover" действует на весь сайт целиком. Включили — и все элементы, прижатые к краю, поехали под панель. У кого-то под ней окажется декоративный фон, у кого-то кнопка «Оставить заявку». Разница между этими двумя случаями — вся разница между красивой шапкой и слитым лидом.

Apple говорит: многие сайты не учитывают такие зоны. Переводя на язык денег — производитель не хочет массово ломать чужие страницы одним флагом в браузере. Логично. У веба нет централизованного релиз-менеджера, который пройдёт по миллионам сайтов и расставит отступы.

Отсюда и пауза. Компания ищет механизм, который нельзя применить «неправильно». Возможно, это будет отдельный набор переменных, возможно — режим с явным согласием сайта, возможно — что-то на уровне разметки секций. Мы не знаем. Знать и не надо: важнее, что периода неопределённости хватит на то, чтобы привести свои страницы в порядок.

Три сценария и что каждый ломает

Третий пункт — единственный, который не зависит от того, что Apple решит через полгода. Отступы по safe-area, аккуратные переносы, отсутствие жестко прибитых к краю элементов. Скучная работа, которая однажды экономит вам конверсию.

Что это меняет для бизнеса

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

Дальше простая арифметика внимания. Узкий вьюпорт означает меньше видимого текста в первом экране. Заголовок в две строки превращается в четыре. Оффер уезжает за границу видимости. Пользователь видит меню, логотип и обрывок фразы. Вопрос «почему не кликают» получает ответ на уровне вёрстки, а не оффера.

Отдельная зона риска — плавающие элементы. Sticky-панель с кнопкой связи, баннер с согласием на cookie, всплывающее окно скидки. Всё это любит фиксироваться по правому краю. На экране, где справа живёт панель браузера, такой блок либо перекроется, либо накроет контент сам. И то и другое плохо выглядит в глазах клиента.

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

Что взять в работу на этой неделе

Ниже — шаги, которые не зависят от финального решения Apple. Полезны и без iPhone Duo: узкие экраны никуда не денутся.

1. Проверьте ширину 320–360 пикселей. Не в эмуляторе, а в реальном браузере с включённым ограничением. Смотрите первый экран: виден ли оффер целиком, не рвётся ли заголовок на шесть строк.
2. Добавьте отступы по safe-area. Внутренние поля у контейнеров, которые касаются краёв, решают проблему вырезов и панелей сразу. Дёшево, безопасно, заметно не всем.
3. Отвяжите важное от правого края. Кнопки, формы, плавающие блоки. Пусть их позиция определяется потоком, а не absolute-координатой.
4. Проверьте таблицы и прайсы. Горизонтальный скролл на узком экране — нормальный выход, обрезанная колонка с ценой — нет.
5. Зафиксируйте поведение шапки. Если фон шапки — картинка, задайте ей такое кадрирование, чтобы обрезка по любому краю не убивала смысл.
6. Не включайте cover вслепую. Пока Apple не назовёт механизм, этот флаг даёт вам те же риски, о которых она предупреждает, без компенсации.

Шесть пунктов — это не проект на квартал. День работы верстальщика плюс проверка на двух-трёх устройствах. Сравните с ценой переверстки в момент, когда новый стандарт уже прилетел.

Где подвох

Главный риск — принять обсуждение за обещание. Apple прямо пишет: изучаем, присылайте идеи, подробности позже. Между «изучаем» и «выпустили» проходит иногда год, иногда ничего не проходит. Строить планы на конкретный API нельзя.

Второй подвох — эмуляторы. Скриншот в инструментах разработчика показывает ширину, но не показывает, как ведёт себя браузерная панель, как перестраивается вьюпорт при сгибе, как реагирует фиксированная шапка. Проверять надо руками.

Третий — вера в то, что «адаптив уже есть, значит всё хорошо». Адаптив по брейкпоинтам и адаптив по безопасным зонам — разные вещи. Первый отвечает на вопрос «сколько места», второй — «где именно это место заканчивается». Второй вопрос SMB-сайты часто игнорируют.

Вердикт

Apple поступила правильно, отказавшись от лёгкого пути. Включить cover одним движением и разломать половину веба — сомнительная щедрость. Публичное приглашение к обсуждению тоже плюс: рынок получает время, а не сюрприз.

Но время — не бесплатное. Пока компания ищет «более надёжный способ», ваш сайт уже сейчас показывают на 5,4-дюймовом экране с панелью справа. Никакой будущий стандарт не отменит проверку на узкой ширине и отступы по безопасным зонам.

Поэтому короткий вердикт: ждать — можно, бездействовать — нет. Приведите контейнеры в порядок, отвяжите кнопки от правого края, проверьте первый экран на 320 пикселях. Это те деньги, которые вы не потратите на аврал позже. И да, если у вас в команде есть веб-разработчик с идеями по механике — Apple их ждёт. Повод написать в WebKit есть ровно сейчас, пока решение не приняли без вас.