iOS и Safari: родной плеер, от которого не уйти

Кратко

На любой платформе, кроме iOS, можно подключить собственный видеодекодер – на iOS это невозможно, поскольку Apple требует использовать системные фреймворки для декодирования независимо от того, работает ли ваш код в Safari, в WKWebView внутри стороннего приложения или в нативном приложении на AVFoundation. «Родной» плеер на iOS – это не одна, а три отдельные поверхности: AVPlayer в нативном приложении (полный контроль, поддержка FairPlay, полный набор «телевизионных» возможностей), элемент <video> в мобильном Safari (нативная поддержка HTTP Live Streaming, или HLS, с рядом проблемных особенностей атрибутов) и относительно новый Managed Media Source API, который Apple представила в Safari 17.1 в ноябре 2023 года, чтобы дать библиотекам вроде hls.js возможность воспроизводить не-HLS-источники на iPhone. Статья подробно разбирает все три поверхности: что они умеют и чего не умеют в 2026 году, в чём отличаются от остальной веб-платформы (автозапуск, инлайн-воспроизведение, Low-Latency HLS, MPEG-DASH, Widevine) и какую из них действительно стоит выбрать для вашего продукта. К статье прилагается одностраничный чек-лист с подводными камнями.

Зачем это вам

Если ваш продукт транслирует видео на телефон, планшет, MacBook, Apple TV или экран CarPlay, обойти медиастек Apple невозможно – каждый байт декодированного видео на современных устройствах Apple проходит через системные фреймворки. Задача вашего приложения сводится к выбору одной из трёх публичных поверхностей, которые будут взаимодействовать с этими фреймворками от вашего имени. Неправильный выбор усложняет всю остальную потоковую архитектуру: вы отдаёте манифесты MPEG-DASH, которые не воспроизводятся в Safari на iPhone; тратите спринт на баг автовоспроизведения, который оказывается пропущенным HTML-атрибутом; реализуете поддержку Widevine DRM и обнаруживаете, что ни один пользователь iPad не может посмотреть ни одного защищённого контента; ставите цель – задержка в прямом эфире не более полсекунды, – а iOS Safari отказывается её обеспечивать без специального профиля Low-Latency HLS от Apple. Эта статья даёт структурное представление: что работает на какой поверхности, какие возможности она разрешает и какие – запрещает. Это позволяет принимать продуктовые и архитектурные решения одновременно, с первого раза, без дорогостоящих переделок под iOS за два релиза до запуска.

Одно правило, которое надо принять сразу

Прежде чем двигаться дальше, примите одно правило: на iOS и iPadOS декодирование видео осуществляет система, а не ваше приложение. Требования App Store и правила Web Content Filter в WebKit это закрепляют – каждый браузер, поставляемый в App Store, независимо от разработчика, исторически использует внутри WebKit. Это означает, что Chrome для iOS, Firefox для iOS, Edge для iOS и любой другой «браузер», который можно установить из App Store, – это WebKit на iOS в чужой обёртке. Закон ЕС Digital Markets Act (DMA) в iOS 17.4 приоткрыл узкую дверь для альтернативных движков внутри Евросоюза, но к концу 2025 года ни один коммерческий браузер на iOS не вышел с движком, отличным от WebKit (Open Web Advocacy, Apple's Browser Engine Ban Persists Even Under the DMA, 2025). На практике в 2026 году стоит планировать так: WebKit на iOS – везде.

Архитектурные ограничения серьёзны. Вы не сможете использовать libwebrtc в iOS Safari. Вы не сможете декодировать AV1 на любом iPhone, просто подключив JavaScript-декодер AV1 – будет работать только то, что поддерживает аппаратная часть устройства. Вы не сможете комбинировать декодеры так, как это возможно на десктопной Linux-системе. Существует три публичных способа попросить систему воспроизвести видео – и оставшаяся часть статьи подробно их описывает.

Три поверхности воспроизведения

Эти три поверхности соответствуют трём программным слоям, которые устройство Apple предоставляет вашему коду. Первая – HTML-элемент <video> в мобильном Safari. Вторая – Managed Media Source API, доступный через тот же <video>-элемент, но только на iOS 17.1 и новее: он позволяет JavaScript-библиотеке подавать сегменты побайтно, вместо указания URL. Третья – AVPlayer внутри нативного приложения для iOS / iPadOS / tvOS, написанного на Swift или Objective-C; это единственная поверхность, которая обеспечивает полный доступ к системным возможностям: режим «картинка в картинке» от операционной системы, FairPlay DRM с аппаратно защищённым ключом, Spatial Audio, интеграцию с экраном блокировки и AirPlay. Выберите одну из них до того, как приступать к написанию архитектурного документа.

Нажмите, чтобы увеличить

Дальше статья последовательно рассматривает три поверхности, а в конце объединяет их в ключевое правило.

Поверхность 1 – нативный HLS в мобильном Safari

Первая поверхность – та, которую Apple ожидает увидеть на большинстве сайтов, и одновременно самая простая в реализации: напишите стандартный HTML-элемент <video>, укажите в атрибуте src URL манифеста HTTP Live Streaming (небольшой текстовый файл с расширением .m3u8, в котором перечислены доступные качества и сегменты), и оставьте всё остальное на Safari. Это путь, под который Apple оптимизировала браузер шестнадцать лет назад, выпустив в 2009 году первую версию HLS; путь, описанный в спецификации HLS Authoring Specification for Apple Devices (регулярно обновляется; на момент написания актуальна редакция от сентября 2025 года); и путь с наименьшим расходом батареи из трёх, поскольку конвейер воспроизведения не выходит за пределы декодера, демультиплексора и контроллера адаптивного битрейта, разработанных Apple.

Механизм доступен JavaScript через метод canPlayType на элементе video. Вызов video.canPlayType('application/vnd.apple.mpegurl') в современном мобильном Safari возвращает "maybe" или "probably" – стандартный межбраузерный сигнал о том, что движок поддерживает формат. Внутри собственных приложений Apple используется тот же путь: HLS-URL передаётся в AVPlayer; декодер под капотом остаётся тем же.

Цена за «Safari всё делает сам» – отказ от четырёх вещей, к которым веб-разработчики привыкли на любой другой платформе. Первая – алгоритм выбора варианта качества: Safari запускает фирменную Apple-логику адаптивного битрейта, переопределить её нельзя, и выбор следующего рендишена делает код внутри ОС, на который вы можете повлиять только подсказками уровня плейлиста – атрибутами VIDEO-RANGE, RESOLUTION и BANDWIDTH в мастер-плейлисте. Вторая – тонкая телеметрия: вы получаете стандартные HTML5 media-события (loadedmetadata, playing, waiting, stalled, ended, error) и AirPlay-событие webkit-playback-target-availability-changed, но не получаете хук на каждую загрузку сегмента, как в hls.js, и поверхность метрик, которую можно навесить на Mux Data или Conviva, уже. Третья – покрытие форматов: нативный Safari проигрывает HLS – и только HLS; он не проигрывает DASH (MPEG Dynamic Adaptive Streaming over HTTP), не проигрывает прогрессивный WebM, а <video src="manifest.mpd"> просто не загружается. Четвёртая – шифрование: единственный web-DRM Safari – FairPlay Streaming, применяемый к HLS-контенту через тег EXT-X-KEY в плейлисте с методом ключа com.apple.streamingkeydelivery`. Widevine в Safari нет – ни на iOS, ни где-либо ещё; PlayReady тоже нет. Если ваш каталог мульти-DRM, на iOS у вас FairPlay.

Два из четырёх ограничений – собственный ABR Apple и FairPlay как единственный DRM – это политические решения, с которыми остальная индустрия научилась мириться, потому что за ними стоят реальные преимущества: эффективное энергопотребление, режим picture-in-picture, AirPlay 2 на Apple TV, Spatial Audio и весь стек доступности iOS, включая субтитры, дружественные к VoiceOver, и аудиоописания. Два других – ограниченная телеметрия и поддержка только HLS – и стали причиной появления второй поверхности.

Обрыв атрибутов воспроизведения

Есть класс багов, с которым каждая команда сталкивается в продакшене: видео, которое корректно воспроизводится в Safari Simulator на Mac и на тестовом iPhone, отказывается автозапускаться в режиме muted-inline на реальном iPhone у пользователя. Причина – один из трёх HTML-атрибутов, которые остальной веб воспринимает как рекомендацию, а мобильный Safari – как жёсткое условие.

playsinline – первый. Без него видео в Safari на iPhone по умолчанию переходит в полноэкранный режим сразу после нажатия на кнопку воспроизведения: страница исчезает, управление берёт на себя операционная система, и все кастомные элементы управления или оверлеи, которые дизайнер добавил вокруг видео, исчезают. Добавление <video playsinline> (или просто булевого атрибута без значения в современном HTML) возвращает привычное для веба поведение – воспроизведение в пределах страницы (WebKit Blog, New <video> Policies for iOS, 2016). На iPadOS и macOS Safari этот атрибут не нужен – там переход в полноэкранный режим всегда был опциональным; он специфичен только для iPhone.

muted – второй. iOS Safari отказывается автозапускать видео со звуком, если звук не отключён на уровне элемента, независимо от того, какой user-gesture API вы используете. Поэтому <video autoplay muted playsinline> – каноничный способ для hero-видео на маркетинговой странице. Если пользователь сам нажимает «Play», он может включить звук; состояние «отключён при загрузке» – это обязательное условие, которое Safari требует, чтобы play() сработал без ошибок.

preload="auto" – третий, и это барьер производительности, а не корректности. iPhone Safari жёстко ограничивает количество preload-запросов в мобильной сети, поэтому даже если на элементе стоит preload="auto", браузер может загрузить лишь первый сегмент, пока пользователь не нажмёт «Play». Для пользователя это логично – экономится трафик, – но удивляет команды, которые тестируют видео по Wi-Fi, видят быстрый старт и выпускают продукт, не проверив его на ограниченном соединении.

Четвёртая особенность: дочерний элемент <source> – правильный способ указать HLS-URL, когда требуется резервный вариант в формате MP4 для браузеров, отличных от Safari. Конструкция <source src="movie.m3u8" type="application/vnd.apple.mpegurl"> плюс <source src="movie.mp4" type="video/mp4"> позволяет браузеру выбрать поддерживаемый им формат. Если указать HLS-URL напрямую в атрибуте <video src>, то в Safari это работает, но браузеры, отличные от Safari, не допускают отсутствие резервного MP4-файла.

Low-Latency HLS в iOS Safari

Apple представила Low-Latency HLS – в индустрии его называют LL-HLS – в 2019 году, а в редакции HLS Authoring Specification от сентября 2023 года тихо убрала требование HTTP/2 server push (Apple, HLS Authoring Specification for Apple Devices, редакция 2025-09). В мобильном Safari LL-HLS-приёмник уже встроен в тот же элемент <video>, которым вы пользуетесь; дополнительная настройка не требуется. Если в манифесте присутствуют теги EXT-X-SERVER-CONTROL, EXT-X-PART, EXT-X-PRELOAD-HINT и EXT-X-RENDITION-REPORT, а медиа поддерживает частичные сегменты, плеер iPhone будет загружать части и достигать задержки «менее трёх секунд glass-to-glass» в хорошей сети. Если же манифест – обычный HLS, плеер работает с задержкой от пятнадцати до тридцати секунд. Это единственный способ получить задержку менее трёх секунд для прямого эфира в Safari на iPhone без нативного приложения – Safari не предоставляет необходимые инструменты для создания собственного приёмника с низкой задержкой на JavaScript, поскольку Managed Media Source (следующая технология) пока не поддерживает этот профиль.

Поверхность 2 – Managed Media Source для элемента `<video>`

Вторая поверхность – Managed Media Source API, сокращённо MMS, которую Apple представила в Safari 17.1 в ноябре 2023 года на iPhone после многолетнего отказа от Media Source Extensions, использовавшихся остальной частью веба с 2013 года (Apple, Safari 17.1 Release Notes, ноябрь 2023; Bitmovin, Apple's New Managed Media Source, 2023). API MMS предоставляет JavaScript-библиотекам возможность передавать байты сегментов непосредственно в элемент <video>, минуя указание URL – тот самый функционал, которым hls.js, Shaka Player, dash.js и Video.js пользуются на всех современных браузерах уже десять лет, наконец появился и на iPhone.

На поверхности MMS важно понять две вещи. Во-первых – зачем она: впервые на iPhone стало возможным воспроизводить не-HLS-источники – манифесты DASH, фрагментированный прогрессивный MP4 и любой формат, который библиотека способна демультиплексировать в CMAF-чанк. Во-вторых – что это такое: это вариант Media Source Extensions (MSE) с двумя структурными отличиями и расширенным управлением питанием. MMS позволяет операционной системе сообщать JavaScript, когда следует снизить активность – например, при использовании мобильной сети, блокировке экрана или переключении пользователя на другую вкладку – через новое свойство MediaSource.streaming и события startstreaming и endstreaming. Кроме того, MMS более строго управляет автоматическим освобождением буфера источника, чем MSE, чтобы Safari на iPhone не накапливал 60-секундный буфер в условиях ограниченной памяти устройства.

Нажмите, чтобы увеличить

Поддержка библиотек появилась быстро. hls.js – самый популярный HLS-плеер в мире JavaScript с примерно пятью миллионами загрузок в неделю – получил поддержку MMS в конце 2023 года и теперь автоматически определяет MMS-путь на iOS Safari без дополнительной настройки: если window.ManagedMediaSource определён, hls.js отдаст ему предпочтение перед нативным <video src="m3u8"> на том же устройстве (hls.js GitHub, Issue #6161 – hls.js on iOS > 17.1, 2023–2024). Shaka Player добавил аналогичную функцию в 2024 году.

Чего MMS не даёт в 2026 году:

• Не поддерживает Widevine или PlayReady в iOS Safari. Единственный доступный DRM в Safari – это FairPlay, который используется через слой Encrypted Media Extensions (EME), поддерживаемый Safari на macOS и теперь также на iOS. Если ваша библиотека передаёт зашифрованный CMAF-источник через MMS, запрос ключа обрабатывается сервером лицензий FairPlay с идентификатором key system com.apple.fps, а не Widevine.
• Не позволяет использовать LL-HLS в JavaScript. Apple не предоставила low-latency-приёмник для библиотек уровня MSE; LL-HLS на iPhone Safari по-прежнему работает либо через нативный <video src="m3u8">, либо через AVPlayer в нативном приложении.
• Не обеспечивает масштабируемый WebRTC-стриминг. Браузеры без полной поддержки WebRTC здесь не рассматриваются; iOS Safari WebRTC поддерживает, но предмет статьи – путь через элемент <video>, который работает только с HLS и fMP4.

Практический вывод: если на остальной части веба используется MPEG-DASH, а вы хотите одной кодовой веткой плеера охватить и iPhone Safari, то MMS плюс hls.js или Shaka – это путь 2026 года. Если же каталог изначально только на HLS, более старый нативный <video src="m3u8"> остаётся проще, экономичнее по энергопотреблению, и большинство команд продолжают его использовать.

Поверхность 3 – AVPlayer в нативном iOS-приложении

Третья поверхность – AVPlayer, системный класс воспроизведения видео в фреймворке AVFoundation от Apple, который используют собственные приложения компании (например, приложения TV, Apple Music, а также Safari для элемента <video> «под капотом») и практически все серьёзные сторонние приложения для iOS. AVPlayer – единственная поверхность, обеспечивающая полный контроль над конвейером воспроизведения: полная поддержка FairPlay через AVContentKeySession, полноценный режим picture-in-picture, AirPlay 2 на Apple TV, Spatial Audio, интеграция с Top Shelf на Apple TV, отображение Now Playing на экране блокировки и на экране CarPlay, фоновое воспроизведение с корректной обработкой аудиосессии iOS, а также полностью программируемая стратегия адаптивного битрейта через AVPlayerItem.preferredPeakBitRate и AVPlayerItem.preferredMaximumResolution.

Форма API остаётся стабильной уже десять лет. Минимальная настройка AVPlayer на Swift занимает всего три строки:

let url = URL(string: "https://example.com/manifest.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) { player.play() }

AVPlayerViewController – системный контроллер представления со стандартной обвязкой плеера (кнопка воспроизведения, тайм-слайдер, меню субтитров, выбор маршрута AirPlay). Можно создать собственные элементы управления поверх AVPlayerLayer и кастомного UIView – так поступают большинство продакшен-приложений, когда подключается дизайн, – но системный контроллер остаётся правильной отправной точкой.

Для HLS URL может быть как live-манифестом, так и VOD-манифестом – AVPlayer адаптируется под любой из них. Приёмник LL-HLS (LL-HLS) Apple интегрировала в AVPlayer в 2019 году и последовательно улучшала в iOS 14, 15, 16, 17 и 18; единственная «настройка» – использование соответствующих тегов в самом манифесте. Для контента, защищённого FairPlay, модель работы такова: подключается AVAssetResourceLoaderDelegate (устаревший способ) или, начиная с iOS 11, AVContentKeySession (современный подход), который обрабатывает запрос на ключ, отправляет его на ваш сервер лицензирования FairPlay и возвращает Content Key Context (CKC), позволяющий декодеру воспроизводить сегменты. Сертификат приложения, который Apple выдаёт для каждого развертывания FairPlay, – это единственное, что требуется от системы; всё остальное – ответственность вашей серверной инфраструктуры.

Нажмите, чтобы увеличить

Несколько моментов из продакшена:

WWDC 2025 добавила AVMetrics на путь прогрессивной загрузки и на офлайн-загрузки HLS (Apple, What's New in HTTP Live Streaming, WWDC 2025, июнь 2025). Те же классы AVMetricEvent, что были доступны для HLS, теперь доступны и на пути URLSession-загрузки через новый колбэк urlSession:assetDownloadTask:didReceiveMetricEvent: в AVAssetDownloadDelegate. Если ваше приложение ориентировано на офлайн-видео для образовательных или туристических платформ, ваша телеметрия QoE теперь охватывает оба пути единой схемой событий.

Picture-in-Picture – одна строка. Установка AVPlayerViewController.allowsPictureInPicturePlayback = true – это полный opt-in для PiP на iOS 14 и новее, с одной оговоркой: в файле Info.plist приложения должен присутствовать массив UIBackgroundModes, содержащий audio и voip, а на iPhone (в отличие от iPad) пользователь должен включить PiP в настройках системы: Settings → General → Picture in Picture. Начиная с iOS 17 эта опция включена по умолчанию; старые пользователи могли её отключить.

FairPlay – не опция для премиум-каталогов HLS. Если контракты со студиями требуют Widevine L1 на Android и FairPlay на Apple, iOS-приложение – единственный способ обеспечить поддержку FairPlay. Safari также воспроизводит защищённый FairPlay HLS через EME com.apple.fps, но процедура получения сертификата идентична, и команды премиум-каталогов на платформах Apple предпочитают нативный путь – он же позволяет использовать офлайн-загрузки с сохранением FairPlay-ключей.

Воспроизведение аудио в фоне продолжается после блокировки экрана. Нативное приложение с включённым UIBackgroundMode=audio и правильно настроенным AVAudioSession продолжает воспроизводить звук при блокировке экрана. Safari – нет: пауза при блокировке – это стандартное поведение WebKit для аудио во вкладке. Поэтому подкаст-подобные продукты выбирают нативное приложение, даже если их видео использует HLS, который в противном случае работал бы в Safari.

Матрица форматов и DRM в 2026 году

Один и тот же контент должен воспроизводиться на всех трёх поверхностях, если продукт кросс-платформенный. Ниже указано, что каждая поверхность принимает на вход и что – нет.

Нажмите, чтобы увеличить

Из матрицы следуют два следствия.

Первое, мульти-DRM в режиме шифрования cbcs – единственный способ делиться зашифрованным файлом между Apple и не-Apple платформами. ISO/IEC 23001-7 Common Encryption (CENC) определяет два режима – cenc (CTR-режим, AES-128, более старый) и cbcs (CBC-режим с подвыборками, более новый). FairPlay поддерживает только cbcs; Widevine и PlayReady с 2018 года принимают cbcs. Стандарт 2026 года – поэтому cbcs-зашифрованный CMAF-источник можно отдавать трём DRM-системам из одного файла, используя три разных лицензионных сервера (PallyCon, EZDRM, Axinom, BuyDRM, AWS – каждый из них предлагает это как managed-сервис). Решение по упаковке описано в статье про CMAF и в подробном разборе FairPlay; решение по плееру – здесь.

Второе, если единственное требование к iOS Safari – «играет HLS», то самый простой плеер – вообще никакой плеер. Чистый <video src="manifest.m3u8" controls playsinline> в HTML с FairPlay через ваш EME-колбэк обеспечивает нативный ABR, нативный LL-HLS, нативный AirPlay, нативный PiP и минимальный расход батареи среди всех трёх платформ. Использовать hls.js или Shaka с Managed Media Source имеет смысл только тогда, когда нужен также DASH или когда требуется более детальная телеметрия, чем та, что дают стандартные HTML5-события медиа.

Распространённая ошибка – воспринимать iOS как «цель полифилла»

Самая дорогостоящая архитектурная ошибка, которую мы видим на продуктовых ревью, – это считать iOS Safari платформой, которую можно «полифиллить» плеером с остального веба. Инстинкт понятен: большинство команд сначала разрабатывают плеер под Chrome и Firefox, где доступны MSE и Widevine, а потом задаются вопросом: «А что делать с iOS?» Неправильный подход – создавать героический шим, пытаясь заставить iOS вести себя как остальной веб. Правильный путь – признать, что три упомянутые выше поверхности – это всё, что доступно для воспроизведения на iOS, и строить архитектуру вокруг их возможностей, рассматривая остальной веб как «расширение», а не наоборот.

Конкретно: собрать мастер-плейлист в формате HLS с cbcs-шифрованием, упаковать CMAF-сегменты, совместимые как с HLS, так и с DASH, из одних и тех же зашифрованных файлов, выдавать лицензии FairPlay на платформах Apple и лицензии Widevine и PlayReady – на остальных. Направлять Safari напрямую на HLS-мастер-плейлист, Android и десктопный Chrome – на DASH-манифест через Shaka или dash.js, а для случаев «FairPlay плюс офлайн», требуемых студийными контрактами, использовать нативное iOS-приложение. Архитектура «HLS-first» – самый дешёвый способ пройти политические требования Apple: она позволяет запустить рабочий iOS-плеер уже в первый день, а не на третьем этапе разработки.

Где это пересекается с Фора Софт

Мы разрабатываем видеоконвейеры для OTT, телемедицины, e-learning, видеонаблюдения и AR/VR с 2005 года, и поверхность воспроизведения на iOS – это часть стека, которую мы чаще всего рефакторили для клиентов, стартовавших с Android-ориентированной стратегии. Паттерн повторяется: команда выбирает MPEG-DASH для веба, строит лицензионный сервер только под Widevine, а затем вынуждена добавлять параллельный путь HLS + FairPlay для iOS-половины аудитории. Мы закладываем каталог в cbcs-зашифрованный CMAF-источник один раз, подключаем FairPlay к iOS-приложению, а Widevine и PlayReady – ко всему остальному, и один и тот же контент воспроизводится везде из одного выхода паковщика. Архитектурная экономия накапливается с каждым следующим студийным контрактом.

Ключевые выводы

• iOS даёт три поверхности воспроизведения – нативный HLS в Safari, Managed Media Source для не-HLS в Safari, AVPlayer в нативном приложении – и четвёртого пути нет.
• Пока вы не отправили комбинацию playsinline плюс muted плюс autoplay, видео в iPhone Safari будет либо отказываться автозапускаться, либо уходить в полноэкранный режим при первом тапе.
• FairPlay – единственный DRM на любой iOS-поверхности; Widevine и PlayReady на iPhone Safari или AVPlayer не работают.
• MPEG-DASH на iPhone Safari требует Managed Media Source плюс библиотеку вроде hls.js или Shaka, доступную на iOS 17.1 и новее.
• LL-HLS на iPhone Safari работает только через нативный <video src="m3u8"> или через AVPlayer; путь Managed Media Source не подходит для low-latency.
• Мульти-DRM в режиме CENC cbcs позволяет одному зашифрованному CMAF-источнику обслуживать FairPlay на Apple и Widevine плюс PlayReady на всём остальном.

Что читать дальше

• Encrypted Media Extensions (EME): как DRM работает в браузере
• hls.js – подробный разбор
• CMAF: формат упаковки, объединивший HLS и DASH