Why this matters
For a streaming service chasing a U.S. audience, Roku is the single biggest doorway into the living room, ahead of Amazon Fire TV and Samsung — and reaching it means committing to a platform that shares almost nothing with the web, iOS, or Android builds you already maintain. A media founder, product manager, or streaming CTO who budgets "the Roku app" as one more port will be surprised three times: by a proprietary language nobody on the team knows, by a certification gate with strict performance numbers, and by monetization rules that take a cut and forbid your own payment flow. This article explains Roku in plain language — the BrightScript-and-SceneGraph stack, the SDK channel model, the certification budget, the content-protection map, and the advertising and billing rules — so you can scope a Roku build, judge a vendor's proposal, and avoid the mistakes that fail certification. It is the streaming-stick companion to the OTT client matrix, which maps every screen you must cover, and a sibling to smart TV apps: Tizen and webOS and Apple TV / tvOS and Fire TV.
Why Roku is its own world
Lead with the reach, because reach is the reason you are here. Roku is the most-used connected-TV platform in the United States: the company announced more than 100 million streaming households worldwide in April 2026, and independent measurement put Roku at about 28% of U.S. connected-TV platform usage and roughly 44% of connected-TV streaming hours in the fourth quarter of 2025 — well ahead of Fire TV and Samsung. If your audience is American and watches on a television, a large share of them reach for a Roku remote. That is the scale requirement that puts Roku near the front of the device queue.
Now the cost side, because it is the part that surprises teams. Roku is a closed, purpose-built platform, not a general-purpose computer. You cannot ship a web app inside a browser the way you can on Samsung Tizen or LG webOS, and you cannot reuse your Android code the way you can on Amazon Fire TV. A Roku app is written from scratch in Roku's own tools, runs on Roku's own operating system, and is distributed only through Roku's own store under Roku's own rules. Every layer is Roku's. That is why the section's plan calls this article "why Roku is its own world" — the reach is unmatched, and so is the lock-in.
The practical consequence is a separate codebase with a separate skill set. The reach buys you a large, hard-to-reach audience; the platform charges you a dedicated team to serve it. The rest of this article walks the four parts of that platform — the language, the channel model, the certification gate, and the protection-and-money rules — so the trade is one you make with open eyes.
Figure 1. Roku is its own world. The web (HTML/JS) and mobile (Swift/Kotlin) stacks do not carry over; a Roku app is BrightScript plus SceneGraph on Roku OS.
BrightScript and SceneGraph: the two pillars
A Roku app rests on two Roku-specific pillars, and neither exists anywhere else. The first is BrightScript — the programming language Roku created for its devices. It is a lightweight scripting language whose syntax sits somewhere between BASIC and a stripped-down JavaScript: readable, but its own dialect, with its own quirks and its own standard library. The second is SceneGraph — Roku's user-interface framework, in which every screen is built from a tree of pre-defined nodes (buttons, labels, grids, lists, a video node) described in XML, and the behaviour of those nodes is driven by BrightScript code. A useful analogy: SceneGraph is to a Roku app what the HTML page structure is to a website, and BrightScript is the scripting that makes it move — except both are Roku-only.
The "Roku-only" part is the whole point, and it has a budget attached. A senior web engineer's React skills, an iOS engineer's Swift, an Android engineer's Kotlin — none of them transfer. Your team either learns BrightScript and SceneGraph or you hire people who already know them, and the pool is small because the skill is useful on exactly one platform. Tooling is thinner than the mainstream platforms too: there is no first-party full IDE on the level of Xcode or Android Studio; most teams use a community Visual Studio Code extension for editing, debugging, and reading the device log over the network. None of this makes Roku hard, exactly — it makes Roku separate, and separate is what costs money over the life of the product.
There is a narrow exception worth knowing about for the simplest catalogues. Roku historically offered Direct Publisher, a no-code route that turned a content feed plus a theme into a basic channel without any BrightScript. It mattered because it let a small publisher skip the language entirely — but it is gone, and that changes the build-vs-buy maths for the whole platform.
The channel model: SDK channels only
Roku calls a published app a "channel," and as of today there is exactly one way to make one that the store will accept: a full SDK channel built in BrightScript and SceneGraph. The no-code Direct Publisher path was wound down — Roku stopped allowing new Direct Publisher channels in 2023 and removed the remaining ones from the platform in January 2024 — so any guide that still tells you to "just upload a feed" is out of date. If you want a custom interface, digital rights management, user accounts, or advertising, you needed the SDK even before the sunset; now you need it for everything.
The distribution flow is Roku's own. You develop and sideload the app onto a real device for testing, package it, and submit it through the Roku Developer Dashboard to the Roku Channel Store. Discovery and install happen inside Roku's storefront, and updates re-enter the same pipeline. One detail catches teams late: Roku requires apps to support deep linking — the ability for Roku's search and its home-screen content rows to send a viewer straight into a specific title in your app, and to begin playback directly ("Direct to Play") rather than dropping them on your home screen. Deep linking is not a nice-to-have on Roku; it is a certification requirement, because Roku's own content discovery depends on it.
Getting onto the device: certification
Every Roku app must pass certification before it reaches the store, and Roku's certification criteria (last updated April 2026) are organized into six areas: advertising, accounts and purchases, performance, app operation, deep linking, and UI and graphics. Two of those areas — performance and accounts/purchases — are where first builds most often fail, because they carry hard, measured numbers rather than soft guidance.
The performance limits are specific, and Roku measures them on low-end hardware — historically a Roku Streaming Stick+ or Premiere+, not a top-of-the-line Roku Ultra. Your app must launch to a fully rendered home screen within 15 seconds, move between screens within 3 seconds, respond to a remote-button press within 250 milliseconds, and start playing content within 8 seconds of the viewer pressing play. And the whole app package must be 4 megabytes or smaller. That last number shocks teams used to mobile, where a 100-megabyte app is unremarkable; on Roku, a bloated bundle of images and fonts simply will not certify. These limits exist because the install base includes inexpensive, memory-constrained streaming sticks, and Roku will not let an app that crawls on a cheap stick degrade the platform's reputation.
The testing rule follows from the same logic: Roku requires you to test on multiple device models with varying processing power and memory before you submit, and it explicitly tells you to include the weaker, older models in that suite. The mistake to avoid is developing and demoing only on a fast, current Roku Ultra and discovering at certification that the app misses the 250-millisecond and 15-second budgets on the cheap stick a real customer actually owns. Roku also provides automated pre-submission tools — a Static Analysis tool that checks your code structure and a Channel Behavior Analysis tool — and an app must pass them to be published.
Figure 2. The certification gate. Six criteria areas, hard performance numbers, and the rule that they are measured on a low-end device — not your fast Ultra.
Content protection on Roku: a different map
Now the part a studio contract turns on, and where Roku diverges most from the web and the TVs. Premium content needs a lock that stops a paying viewer's device from copying it, called digital rights management (DRM). On the web and on Samsung/LG televisions, the app requests decryption keys through a browser standard called Encrypted Media Extensions (EME), the W3C recommendation. Roku does not use EME at all — there is no browser in the picture. Instead, your BrightScript code configures DRM directly on the SceneGraph video node, passing the key-system name and the license-server address as native properties. If you are coming from a web or smart-TV build, this is the single biggest structural difference: same DRM systems underneath, completely different wiring above.
Which DRM systems does Roku support, and with which streaming format? Roku's content-protection documentation publishes an exact map, and it is worth memorizing because it is not the one you used on mobile. The streaming formats are HTTP Live Streaming (HLS), Apple's format standardized as IETF RFC 8216, and MPEG-DASH, the ISO format in ISO/IEC 23009-1 (plus Microsoft's older Smooth Streaming). The mapping is:
| Streaming format | PlayReady | Widevine | AES-128 |
|---|---|---|---|
| HLS | — | ✅ supported | ✅ (clear-key) |
| Smooth | ✅ supported | — | — |
| DASH | ✅ supported | ✅ supported | — |
Read it carefully. Google's Widevine runs over HLS and DASH; Microsoft's PlayReady runs over Smooth and DASH; the simpler AES-128 clear-key encryption rides on HLS. The clean conclusion most teams reach is that DASH is the common ground — it is the one format that carries both studio-grade DRM systems — so a Roku plan that uses DASH with Widevine and/or PlayReady can serve protected content across the broadest device base from one packaging. Apple's FairPlay, the third big DRM system, does not appear at all: like on the TVs, FairPlay is confined to Apple's own hardware and is absent on Roku.
A few dated, vendor-specific details belong in any current Roku plan, exactly the kind of facts that age and must be re-checked. Roku removed support for Verimatrix DRM in Roku OS 9.3, so Widevine and PlayReady are the two systems to design around. Roku's PlayReady moved to the PlayReady 3 library starting in Roku OS 8.1, and Widevine version 16 is supported since Roku OS 9.4 on devices without dedicated secure processors. For the encryption scheme itself, Roku's Widevine support covers both the counter-mode (CTR) and cipher-block-chaining (CBC/CBCS) schemes of Common Encryption (ISO/IEC 23001-7), with key rotation available since firmware 9.0.x — so unlike the older smart-TV fleet, the modern "encrypt once with cbcs" convergence is generally workable on current Roku hardware, though you confirm scheme coverage against your actual device matrix. The scheme mechanics in full are in CENC, CTR, and CBCS: common encryption explained, the three systems in Widevine, PlayReady, FairPlay, and the one-workflow approach in multi-DRM: one workflow, every device.
One more layer sits on the cable, not in the software. High-bandwidth Digital Content Protection (HDCP) protects the video as it travels over HDMI from the Roku to the screen. Roku's 4K-capable devices support HDCP 2.2, which studios require for 4K and HDR; non-4K devices use the older HDCP 1.4, and a 4K device connected below 4K falls back to 1.4. The practical effect a viewer sees: if any device in the HDMI chain — TV, receiver, cable — is not HDCP 2.2 compliant, the 4K title drops to a lower resolution or shows an error. DRM protects the stream and the keys; HDCP protects the last hop to the panel; neither stops a camera pointed at the screen, so be precise about what each layer does.
Figure 3. The Roku protection map. DASH is the common ground for studio DRM; DRM is wired natively in BrightScript, not through the browser's EME; HDCP guards the HDMI hop.
Monetization: the Roku Advertising Framework and Roku Pay
Roku's money rules are as distinctive as its language, and they are enforced at certification, so they are not optional. They split along the two ways a streaming service earns: advertising and direct payment.
For advertising, Roku requires the Roku Advertising Framework (RAF) — a Roku-provided library, shipped as a hidden system app, that renders pre-roll, mid-roll, and post-roll video ads and fires the measurement beacons that tell advertisers an ad actually played. Any app that runs video advertising must integrate RAF to pass certification, and the rule has teeth: ad-tracking beacons must be fired client-side by RAF, not wrapped or fired by your own code, so that Roku can apply its advertising watermark and the measurement is trusted. This holds even when you use server-side ad insertion (SSAI) — the technique that stitches ads into the video stream on the server so they are harder to block — covered in server-side ad insertion (SSAI) vs client-side (CSAI). Roku ships SSAI adapters for six providers — uplynk, adobe, onceux, yospace, awsemt (AWS Elemental MediaTailor), and ggldai (Google Dynamic Ad Insertion) — and even with SSAI, the beacons still route through RAF client-side. The broader ad stack and the VAST standard that describes the ads live in ad serving, VAST/VMAP, and the ad stack.
For direct payment, Roku requires Roku Pay — Roku's own billing system — and forbids you from sending viewers to any other payment method. If your app sells subscriptions, rentals, or one-time purchases, sign-up, payment, and entitlement run through Roku Pay, and you "may not facilitate or direct customers to use any method of payment" other than Roku Pay. The price of that is a revenue share: Roku keeps 20% of the net revenue and remits 80% to you, in exchange for handling billing, payment processing, and refunds.
Walk the arithmetic out loud, because it changes a business model. Suppose your subscription is $9.99 a month. Roku's 20% cut is $9.99 × 0.20 = $2.00, leaving you 80%, or $7.99, per subscriber per month. Now scale it: at 100,000 paying subscribers, gross is $9.99 × 100,000 = $999,000 a month; Roku's 20% is about $199,800, and your 80% is about $799,200. Over a year, Roku's share of that single cohort is roughly $2.4 million. That is not a hidden fee — it is the platform's price for access to the largest U.S. streaming audience and for running the billing — but it has to be in your pricing model from day one, alongside the cost of building and certifying a separate app. How that fits the wider revenue picture is in subscription billing and entitlement.
Figure 4. Two money paths, both Roku's. Ads must use RAF with client-side beacon firing; payments must use Roku Pay, which keeps 20% and remits 80%.
Common mistake — the five that fail a Roku launch. First, budgeting Roku as a "port" of the web or mobile app; it is a separate BrightScript/SceneGraph codebase and a separate skill set. Second, ignoring the 4 MB app-size limit and the performance budget, then failing certification on a cheap stick after developing on a fast Ultra — test on the low-end model. Third, assuming the no-code Direct Publisher route still exists; it was removed in January 2024, so you need a full SDK channel. Fourth, firing your own ad beacons or skipping RAF; ad-supported apps must route beacons client-side through RAF to certify. Fifth, planning a third-party paywall; Roku Pay is mandatory for transactions and you cannot point viewers elsewhere.
Where Fora Soft fits in
Roku is where a U.S. streaming service meets its largest living-room audience, and the scale problem is not one screen — it is a closed platform that demands a dedicated BrightScript and SceneGraph codebase, a 4-megabyte performance budget on low-end hardware, native DRM wiring, and Roku's own advertising and billing rules, all at once. Fora Soft has built video streaming, OTT/Internet TV, e-learning, and telemedicine applications since 2005 — 625+ projects for 400+ clients across 20+ years — so the Roku realities here (the SDK channel model, certification against the performance numbers, Widevine and PlayReady over DASH configured in BrightScript, and RAF plus Roku Pay) are the day-to-day of our streaming work. We are vendor-neutral: we translate each platform's rules into a build rather than reselling a single SDK, and we scope the device matrix so Roku earns its place beside the web, mobile, and TV apps instead of doubling your maintenance by surprise.
What to read next
- The OTT client matrix: web, mobile, smart TV, streaming devices
- Smart TV apps: Tizen and webOS
- Apple TV / tvOS and Fire TV
Call to action
- Talk to a streaming engineer — book a 30-minute scoping call to talk through your roku development plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the Roku Build & Certification Spec Sheet — A one-page reference of the BrightScript/SceneGraph stack, the SDK channel model (Direct Publisher retired), the DRM-to-format map (Widevine/PlayReady over DASH, AES-128 on HLS, native BrightScript not EME, HDCP 2.2/1.4), the….
References
- HTTP Live Streaming (HLS) — IETF RFC 8216. IETF, 2017. The HLS format Roku carries Widevine and AES-128 over; the controlling source for HLS structure. Tier 1. https://www.rfc-editor.org/rfc/rfc8216
- Dynamic adaptive streaming over HTTP (MPEG-DASH) — ISO/IEC 23009-1. ISO/IEC. The DASH format that is the common ground for both Widevine and PlayReady on Roku. Tier 1. https://www.iso.org/standard/83314.html
- Common Encryption (CENC) — ISO/IEC 23001-7. ISO/IEC. Defines the CTR and CBC/CBCS schemes Roku's Widevine support references; the basis of the encryption-scheme decision. Tier 1. https://www.iso.org/standard/68042.html
- Encrypted Media Extensions (EME). W3C Recommendation, 18 September 2017. The browser DRM standard used on web and smart TVs — and the one Roku notably does NOT use, configuring DRM natively in BrightScript instead. Tier 1. https://www.w3.org/TR/encrypted-media/
- VAST (Video Ad Serving Template) 4.x. IAB Tech Lab. The ad-response standard behind the video ads RAF renders. Tier 1. https://iabtechlab.com/standards/vast/
- DRM & content protection — Roku Developer Docs. Roku. The DRM-to-format support matrix (PlayReady/Widevine/AES-128 across HLS/Smooth/DASH), the native BrightScript drmParams/keySystem configuration, the Verimatrix removal in Roku OS 9.3, PlayReady/Widevine versions, CTR and CBC/CBCS schemes, and HDCP 2.2/1.4. Tier 3 (first-party), fetched 2026-06-17. https://developer.roku.com/dev/docs/content-protection
- Certification criteria — Roku Developer Docs. Roku, last updated April 2026. The six criteria areas and the performance budget: 4 MB app size, 15 s launch, 3 s screen transitions, 250 ms remote response, 8 s content start, multi-device testing, deep linking, and the Roku Pay mandate. Tier 3 (first-party), fetched 2026-06-17. https://developer.roku.com/dev/docs/certification
- Integrating the Roku Advertising Framework — Roku Developer Docs. Roku. RAF as the mandatory ad library, client-side beacon firing and the Roku Advertising Watermark, and the user-agent requirement for ad requests. Tier 3 (first-party), fetched 2026-06-17. https://developer.roku.com/dev/docs/integrating-roku-advertising-framework
- Implementing Server-Side Ad Insertion Using Roku Adapters — Roku Developer Docs. Roku. The six SSAI adapter values (uplynk, adobe, onceux, yospace, awsemt, ggldai) and the rule that beacons still fire client-side through RAF. Tier 3 (first-party), fetched 2026-06-17. https://developer.roku.com/dev/docs/ssai-adapters
- Monetization & billing (Roku Pay) — Roku Developer Docs. Roku. The 80/20 revenue share on subscriptions and one-time purchases and Roku's management of billing and payment. Tier 3 (first-party). https://developer.roku.com/docs/features/monetization/billing.md
- Roku Surpasses 100 Million Streaming Households. Roku Newsroom, April 2026. The 100M+ global streaming-household milestone. Tier 5 (vendor PR / orientation). https://newsroom.roku.com/news/2026/04/roku-surpasses-100-million-streaming-households-a-historic-milestone/cbdb6hs7-1776191291
- Parks Associates: Roku (28%) and Samsung (23%) dominate U.S. connected-TV platforms, 2025. Parks Associates via PR Newswire. U.S. CTV platform-usage share; orientation figures, re-baseline per review. Tier 5 (industry). https://www.prnewswire.com/news-releases/parks-associates-roku-28-and-samsung-23-dominate-connected-tv-platforms-controlling-access-to-streaming-audiences-in-the-us-market-302749732.html
Where sources disagreed, the official spec or the first-party Roku doc was followed. The widespread listicle claim that you "publish a Roku channel by uploading a feed" was overridden by Roku's own deprecation of Direct Publisher (new channels stopped 2023, existing removed January 2024) — SDK channels are now the only path. The common assumption that smart-TV/web DRM "uses EME everywhere" was overridden by Roku's content-protection docs, which configure DRM in native BrightScript and never reference EME.
