Разработка под Roku: каналы, DRM и сертификация

Кратко

Roku – крупнейшая стриминговая платформа в США: в апреле 2026 года Roku преодолела отметку в 100 миллионов стриминговых домохозяйств в мире и в конце 2025 года занимала около 44% часов просмотра на connected-TV в США, – поэтому для медиасервиса, нацеленного на американские гостиные, приложение под Roku редко бывает опциональным. Подвох в том, что Roku – это отдельный мир: приложение пишется на языке только для Roku под названием BrightScript с фреймворком интерфейса только для Roku под названием SceneGraph, так что код, который уже написали ваши web- и мобильные команды, сюда не переносится. Путь в Roku Channel Store теперь идёт только через полноценный SDK-канал (no-code-маршрут Direct Publisher закрыли в январе 2024 года), и каждое приложение должно пройти сертификацию с жёсткими лимитами производительности, включая потолок размера приложения в четыре мегабайта и правило запуска менее чем за пятнадцать секунд, замеряемые на слабом устройстве. Защита контента, реклама и биллинг – каждый по своим правилам Roku: нативный DRM на BrightScript вместо браузерного Encrypted Media Extensions, обязательный Roku Advertising Framework для любого рекламного приложения и Roku Pay (который удерживает 20% выручки с подписок и транзакций) как единственный разрешённый способ брать деньги со зрителя.

Почему это важно

Для стримингового сервиса, который борется за аудиторию США, Roku – самая большая дверь в гостиную, впереди Amazon Fire TV и Samsung, – и пройти в неё значит взять на себя платформу, у которой почти нет ничего общего с вашими сборками под web, iOS или Android. Основатель медиасервиса, продакт-менеджер или streaming-CTO, который заложит «приложение под Roku» как очередной порт, удивится трижды: проприетарному языку, который никто в команде не знает, шлюзу сертификации с жёсткими числами и правилам монетизации, которые забирают долю и запрещают собственный платёжный поток. Эта статья объясняет Roku простым языком – стек BrightScript и SceneGraph, модель SDK-канала, бюджет сертификации, карту защиты контента и правила рекламы и биллинга, – чтобы вы могли оценить Roku-сборку, разобрать предложение подрядчика и избежать ошибок, которые валят сертификацию. Это спутник для стриминговых стиков к клиентской матрице OTT, которая картирует все экраны, что нужно покрыть, и собрат для приложений под смарт-ТВ: Tizen и webOS и Apple TV / tvOS и Fire TV.

Почему Roku – это отдельный мир

Начнём с охвата, потому что охват – это причина, по которой вы здесь. Roku – самая используемая платформа connected-TV в США: компания объявила о более чем 100 миллионах стриминговых домохозяйств в мире в апреле 2026 года, а независимые замеры дали Roku около 28% использования платформ connected-TV в США и примерно 44% часов просмотра на connected-TV в четвёртом квартале 2025 года – заметно впереди Fire TV и Samsung. Если ваша аудитория американская и смотрит на телевизоре, значительная её часть тянется к пульту Roku. Это и есть требование масштаба, которое ставит Roku в начало очереди устройств.

Теперь о цене, потому что именно эта часть удивляет команды. Roku – это закрытая, специализированная платформа, а не компьютер общего назначения. Вы не можете запустить web-приложение внутри браузера, как на Samsung Tizen или LG webOS, и не можете переиспользовать Android-код, как на Amazon Fire TV. Приложение под Roku пишется с нуля в собственных инструментах Roku, работает на собственной ОС Roku и распространяется только через собственный магазин Roku по собственным правилам Roku. Каждый слой – «роковский». Поэтому план раздела и называет эту статью «почему Roku – это отдельный мир»: охват не имеет равных, и блокировка тоже.

Практическое следствие – отдельная кодовая база с отдельным набором навыков. Охват покупает вам большую, труднодоступную аудиторию; платформа взимает за неё выделенную команду. Дальше статья проходит четыре части этой платформы – язык, модель канала, шлюз сертификации и правила защиты и денег, – чтобы сделка была той, на которую вы идёте с открытыми глазами.

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

BrightScript и SceneGraph: две опоры

Приложение под Roku стоит на двух опорах, специфичных для Roku, и ни одной из них нет больше нигде. Первая – BrightScript, язык программирования, который Roku создала для своих устройств. Это лёгкий скриптовый язык, синтаксис которого находится где-то между BASIC и упрощённым JavaScript: читаемый, но это свой диалект, со своими особенностями и своей стандартной библиотекой. Вторая – SceneGraph, фреймворк интерфейса Roku, в котором каждый экран строится из дерева предопределённых узлов (кнопки, надписи, сетки, списки, video-нода), описанных в XML, а поведением этих узлов управляет код на BrightScript. Полезная аналогия: SceneGraph для приложения Roku – это как структура HTML-страницы для сайта, а BrightScript – скрипты, которые приводят всё в движение; только и то и другое существует исключительно в Roku.

Часть «исключительно в Roku» – это и есть вся суть, и за ней закреплён бюджет. Навыки React у сеньора-web-инженера, Swift у iOS-инженера, Kotlin у Android-инженера – ни один из них не переносится. Ваша команда либо учит BrightScript и SceneGraph, либо вы нанимаете тех, кто уже их знает, а пул маленький, потому что навык полезен ровно на одной платформе. Тулинг тоже беднее, чем у мейнстримных платформ: нет первой полноценной IDE уровня Xcode или Android Studio; большинство команд использует community-расширение для Visual Studio Code для редактирования, отладки и чтения лога устройства по сети. Ничто из этого не делает Roku сложной – оно делает Roku отдельной, а отдельность и стоит денег на протяжении жизни продукта.

Есть узкое исключение, о котором стоит знать для простейших каталогов. Исторически Roku предлагала Direct Publisher – no-code-маршрут, который превращал фид с контентом плюс тему в базовый канал без какого-либо BrightScript. Он был важен, потому что позволял маленькому издателю целиком обойти язык, – но его больше нет, и это меняет математику build-vs-buy для всей платформы.

Модель канала: только SDK-каналы

Roku называет опубликованное приложение «каналом» (channel), и на сегодня есть ровно один способ сделать его так, чтобы магазин принял: полноценный SDK-канал на BrightScript и SceneGraph. No-code-путь Direct Publisher свернули – Roku перестала разрешать новые каналы Direct Publisher в 2023 году и удалила оставшиеся с платформы в январе 2024 года, – так что любой гайд, который всё ещё советует «просто загрузить фид», устарел. Если вам нужны кастомный интерфейс, управление цифровыми правами, аккаунты пользователей или реклама, SDK был нужен и до закрытия; теперь он нужен для всего.

Поток дистрибуции – собственный у Roku. Вы разрабатываете и сайдлоадите приложение на реальное устройство для тестирования, упаковываете его и отправляете через Roku Developer Dashboard в Roku Channel Store. Обнаружение и установка происходят внутри витрины Roku, а обновления заходят в тот же конвейер. Одна деталь подлавливает команды поздно: Roku требует, чтобы приложения поддерживали deep linking – способность поиска Roku и контентных рядов на домашнем экране отправлять зрителя прямо в конкретный тайтл в вашем приложении и начинать воспроизведение сразу («Direct to Play»), а не высаживать его на вашу главную. Deep linking на Roku – не приятное дополнение, а требование сертификации, потому что собственное обнаружение контента у Roku зависит от него.

Как попасть на устройство: сертификация

Каждое приложение под Roku должно пройти сертификацию до попадания в магазин, и критерии сертификации Roku (последнее обновление – апрель 2026 года) сгруппированы в шесть областей: реклама, аккаунты и покупки, производительность, работа приложения, deep linking, а также UI и графика. Две из этих областей – производительность и аккаунты/покупки – это места, где первые сборки чаще всего падают, потому что несут жёсткие, замеряемые числа, а не мягкие рекомендации.

Лимиты производительности конкретны, и Roku замеряет их на слабом железе – исторически это Roku Streaming Stick+ или Premiere+, а не топовый Roku Ultra. Ваше приложение должно запускаться до полностью отрисованного домашнего экрана за 15 секунд, переключать экраны за 3 секунды, отвечать на нажатие кнопки пульта за 250 миллисекунд и начинать воспроизведение контента за 8 секунд после того, как зритель нажал play. И весь пакет приложения должен быть 4 мегабайта или меньше. Последнее число шокирует команды, привыкшие к мобайлу, где 100-мегабайтное приложение в порядке вещей; на Roku раздутый набор картинок и шрифтов просто не пройдёт сертификацию. Эти лимиты существуют, потому что в установленной базе есть дешёвые стики с ограниченной памятью, и Roku не позволит приложению, которое еле ползёт на дешёвом стике, портить репутацию платформы.

Правило тестирования вытекает из той же логики: Roku требует тестировать на нескольких моделях устройств с разной вычислительной мощностью и памятью до отправки и прямо велит включить в этот набор более слабые, старые модели. Ошибка, которой надо избежать, – разрабатывать и показывать демо только на быстром, актуальном Roku Ultra, а на сертификации обнаружить, что приложение не укладывается в 250 миллисекунд и 15 секунд на дешёвом стике, который реально есть у клиента. Roku также даёт автоматические инструменты до отправки – Static Analysis, проверяющий структуру кода, и Channel Behavior Analysis, – и приложение обязано их пройти, чтобы быть опубликованным.

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

Защита контента на Roku: другая карта

Теперь та часть, на которой держится контракт со студией, и где Roku расходится с web и телевизорами сильнее всего. Премиальному контенту нужен замок, который не даёт устройству платящего зрителя копировать его, – он называется управление цифровыми правами (DRM). В web и на телевизорах Samsung/LG приложение запрашивает ключи расшифровки через браузерный стандарт Encrypted Media Extensions (EME) – рекомендацию W3C. Roku не использует EME вообще – браузера в картине нет. Вместо этого ваш код на BrightScript настраивает DRM прямо на video-ноде SceneGraph, передавая имя key-system и адрес лицензионного сервера как нативные свойства. Если вы пришли из web- или smart-TV-сборки, это самое большое структурное отличие: те же DRM-системы внизу, совершенно другая обвязка сверху.

Какие DRM-системы поддерживает Roku и с каким форматом стриминга? Документация Roku по защите контента публикует точную карту, и её стоит запомнить, потому что это не та, что была у вас на мобайле. Форматы стриминга – это HTTP Live Streaming (HLS), формат Apple, стандартизированный как IETF RFC 8216, и MPEG-DASH, ISO-формат из ISO/IEC 23009-1 (плюс более старый Smooth Streaming от Microsoft). Карта такая:

Прочтите внимательно. Widevine от Google работает поверх HLS и DASH; PlayReady от Microsoft работает поверх Smooth и DASH; более простое clear-key-шифрование AES-128 едет на HLS. Чистый вывод, к которому приходит большинство команд: общая база – это DASH, единственный формат, который несёт обе студийные DRM-системы, – так что план Roku, использующий DASH с Widevine и/или PlayReady, может обслужить защищённый контент на самой широкой базе устройств из одной упаковки. FairPlay от Apple, третья крупная DRM-система, не появляется вообще: как и на телевизорах, FairPlay заперт на устройствах Apple и на Roku отсутствует.

Несколько датированных, вендор-специфичных деталей место в любом актуальном плане Roku – ровно те факты, что стареют и требуют перепроверки. Roku убрала поддержку Verimatrix DRM в Roku OS 9.3, так что проектировать стоит вокруг Widevine и PlayReady. PlayReady у Roku перешёл на библиотеку PlayReady 3 начиная с Roku OS 8.1, а Widevine версии 16 поддерживается с Roku OS 9.4 на устройствах без выделенных защищённых процессоров. По самой схеме шифрования поддержка Widevine у Roku покрывает обе схемы Common Encryption (ISO/IEC 23001-7) – counter-mode (CTR) и cipher-block-chaining (CBC/CBCS), – с ротацией ключей с прошивки 9.0.x, так что в отличие от старого парка смарт-ТВ современная конвергенция «шифруй один раз через cbcs» в целом работоспособна на актуальном железе Roku, хотя покрытие схемы стоит подтвердить на вашей реальной матрице устройств. Механика схем целиком – в CENC, CTR и CBCS: общее шифрование простыми словами, три системы – в Widevine, PlayReady, FairPlay, а подход «один workflow» – в multi-DRM: один workflow, все устройства.

Ещё один слой лежит на кабеле, а не в софте. High-bandwidth Digital Content Protection (HDCP) защищает видео, пока оно идёт по HDMI от Roku к экрану. 4K-устройства Roku поддерживают HDCP 2.2, который студии требуют для 4K и HDR; не-4K-устройства используют более старый HDCP 1.4, а 4K-устройство, подключённое ниже 4K, откатывается на 1.4. Практический эффект, который видит зритель: если любое устройство в HDMI-цепочке – телевизор, ресивер, кабель – не совместимо с HDCP 2.2, 4K-тайтл падает до меньшего разрешения или показывает ошибку. DRM защищает поток и ключи; HDCP защищает последний переход к панели; ни то ни другое не остановит камеру, направленную на экран, – поэтому будьте точны в том, что делает каждый слой.

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

Монетизация: Roku Advertising Framework и Roku Pay

Денежные правила Roku так же своеобразны, как её язык, и они проверяются на сертификации, так что необязательными не являются. Они расходятся по двум способам заработка стримингового сервиса: реклама и прямая оплата.

Для рекламы Roku требует Roku Advertising Framework (RAF) – библиотеку от Roku, поставляемую как скрытое системное приложение, которая рендерит pre-roll-, mid-roll- и post-roll-видеорекламу и шлёт измерительные биконы, сообщающие рекламодателям, что реклама действительно проигралась. Любое приложение, крутящее видеорекламу, должно интегрировать RAF, чтобы пройти сертификацию, и у правила есть зубы: рекламные биконы должны отправляться client-side силами RAF, а не оборачиваться и не отправляться вашим кодом, чтобы Roku мог применить свою рекламную watermark и измерение было доверенным. Это верно даже когда вы используете серверную вставку рекламы (SSAI) – технику, которая вшивает рекламу в видеопоток на сервере, чтобы её было труднее заблокировать, – разобранную в серверная вставка рекламы (SSAI) против клиентской (CSAI). Roku поставляет SSAI-адаптеры для шести провайдеров – uplynk, adobe, onceux, yospace, awsemt (AWS Elemental MediaTailor) и ggldai (Google Dynamic Ad Insertion), – и даже с SSAI биконы всё равно идут через RAF client-side. Более широкий рекламный стек и стандарт VAST, описывающий рекламу, – в ad serving, VAST/VMAP и рекламный стек.

Для прямой оплаты Roku требует Roku Pay – собственную биллинговую систему – и запрещает отправлять зрителей к любому другому способу оплаты. Если ваше приложение продаёт подписки, аренду или разовые покупки, регистрация, оплата и entitlement идут через Roku Pay, и вы «не можете способствовать или направлять клиентов к любому методу оплаты», кроме Roku Pay. Цена этого – доля выручки: Roku удерживает 20% чистой выручки и перечисляет вам 80% в обмен на ведение биллинга, обработку платежей и возвраты.

Пройдём арифметику вслух, потому что она меняет бизнес-модель. Допустим, ваша подписка – $9.99 в месяц. Доля Roku в 20% – это $9.99 × 0,20 = $2.00, оставляя вам 80%, или $7.99, с подписчика в месяц. Теперь масштабируем: при 100 000 платящих подписчиков валовая выручка – $9.99 × 100 000 = $999 000 в месяц; 20% Roku – около $199 800, а ваши 80% – около $799 200. За год доля Roku с одной этой когорты – примерно $2,4 млн. Это не скрытая комиссия – это цена платформы за доступ к крупнейшей стриминговой аудитории США и за ведение биллинга, – но она должна быть в вашей ценовой модели с первого дня, рядом со стоимостью сборки и сертификации отдельного приложения. Как это вписывается в более широкую картину выручки – в биллинг подписок и entitlement.

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

«Частая ошибка – пять, что валят запуск на Roku. Первое: закладывать Roku как «порт» web- или мобильного приложения; это отдельная кодовая база на BrightScript/SceneGraph и отдельный набор навыков. Второе: игнорировать лимит 4 МБ и бюджет производительности, а затем провалить сертификацию на дешёвом стике, разрабатывая на быстром Ultra, – тестируйте на слабой модели. Третье: считать, что no-code-маршрут Direct Publisher ещё существует; его убрали в январе 2024 года, так что нужен полноценный SDK-канал. Четвёртое: слать собственные рекламные биконы или пропускать RAF; рекламные приложения обязаны отправлять биконы client-side через RAF, чтобы сертифицироваться. Пятое: планировать сторонний paywall; Roku Pay обязателен для транзакций, и направлять зрителей в другое место нельзя.»

Где здесь Фора Софт

Roku – это место, где стриминговый сервис США встречает свою крупнейшую аудиторию в гостиной, и проблема масштаба – не один экран, а закрытая платформа, которая требует выделенной кодовой базы на BrightScript и SceneGraph, бюджета производительности в 4 мегабайта на слабом железе, нативной обвязки DRM и собственных рекламных и биллинговых правил Roku – всё разом. Фора Софт строит приложения для видеостриминга, OTT/Internet TV, e-learning и телемедицины с 2005 года – 250+ проектов для 400+ клиентов за 20+ лет, – так что реалии Roku здесь (модель SDK-канала, сертификация против чисел производительности, Widevine и PlayReady поверх DASH, настроенные на BrightScript, и RAF плюс Roku Pay) – это повседневность нашей стриминговой работы. Мы вендор-нейтральны: мы переводим правила каждой платформы в сборку, а не перепродаём один SDK, и так выстраиваем матрицу устройств, чтобы Roku заслужила своё место рядом с web-, мобильными и ТВ-приложениями, а не удваивала ваше обслуживание внезапно.

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

• Roku – стриминговая платформа №1 в США (100+ млн домохозяйств, ~44% часов CTV), поэтому редко опциональна.
• Это отдельный мир: язык только-для-Roku BrightScript и UI SceneGraph, без переиспользования кода web или mobile.
• Сейчас выходят только SDK-каналы; no-code-маршрут Direct Publisher убрали в январе 2024 года.
• Сертификация жёсткая: 4 МБ, запуск 15 с, отклик пульта 250 мс – всё на слабом железе.
• DRM – нативный BrightScript, не EME: Widevine/PlayReady поверх DASH, AES-128 на HLS, без FairPlay; HDCP 2.2 для 4K.
• Монетизация – «роковская»: RAF обязателен для рекламы, а Roku Pay (доля 80/20) – единственный разрешённый биллинг.

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

• Клиентская матрица OTT: web, mobile, смарт-ТВ, стриминговые устройства
• Приложения для смарт-ТВ: Tizen и webOS
• Apple TV / tvOS и Fire TV