A Roku certification checklist from someone who has passed it
Roku publishes its certification criteria in full, so the list isn't a secret. What the document doesn't tell you is which requirements actually fail apps, which ones are cheap at the start and expensive to retrofit at the end, and which numbers your team will be arguing about at 11pm the night before submission. That's what this covers. I took a national organization's channel from an empty repository through Roku certification, and I've spent five years since inside players that live under the same rules at Xfinity Stream, Peacock, and discovery+.
Read the criteria as three different documents
The published list is organized by function: advertising, accounts and purchases, performance, app operation, deep linking, UI and graphics. That order works for an auditor. For a team planning work it's misleading, because it flattens three different kinds of requirement into one numbered list.
- Architectural requirements force a rewrite if you didn't design for them. They're the schedule risk.
- Threshold requirements are numbers you hit or miss on specific hardware. They catch teams that only ever tested on a fast device.
- Policy requirements are rules about behavior and content. They cost almost nothing if you know them and a resubmission if you don't.
Below are the current criteria, sorted that way. Everything here comes from Roku's published certification criteria, last updated April 2026. Check the live document before you submit: thresholds move, and two of the requirements below take effect in October 2026.
1. The architectural ones: decide these before you write code
Everything happens on the device
Sign‑up and sign‑in must happen on the device. Roku prohibits external webpages, links to off‑device promotional material, and any other off‑device authentication or activation, and upgrades and downgrades have to finish on the device too. Teams coming from web or mobile reach for a hosted login page by reflex, because that's how every other platform works. On Roku it means a rewrite. The same instinct fails elsewhere in the list: apps may not nest content or other apps, embed browser screens, deep link into other apps, or take payment any way other than Roku Pay.
You can't add deep linking later
Apps must support deep linking for every media type and implement Direct to Play, so voice commands can launch straight into content. Deep linking touches routing, content identity, and playback startup all at once. Retrofitting it into an app whose navigation assumed a single entry point is one of the most expensive late changes on the platform. It belongs in the first architecture conversation. By the pre‑submission sprint it's too late to be cheap.
The back button is a contract
Back returns the user to the previous screen or state. On the home screen it exits the app to the Roku home screen, with at most one confirmation dialog. That sounds trivial. It's also the most common sign that an app was ported from another platform, because doing it right takes a real screen stack with restorable state, and a pile of ad hoc transitions won't pass.
Playback state has to survive
Bookmarking is required for all VOD content longer than 15 minutes, and bookmarks have to be kept for at least 30 days. App updates may not force reactivation, relinking, or a new login, and they must keep saved data. Resume playback is a data model decision. On the Church's channel I implemented resume through the Roku registry. Where you keep that state, and how it survives an update, costs nothing to decide on day one and is structural by day ninety.
2. The threshold ones: the numbers, and the device that matters
This is where most teams get caught, and the cause is one sentence in the criteria rather than the numbers themselves. Roku measures the performance requirements on the Roku Streaming Stick+ (Amarillo‑2019 3810X) or the Roku Premiere+ (Gilbert 4K 3921X), and reserves the right to block launch on every other Roku device if you miss on those. Your app is judged on hardware from 2019.
If your team tests on a current Ultra, on a Roku TV in the conference room, or worst of all in the simulator, your numbers are fiction. Buy the two named devices. They cost less than one hour of the argument you'll have otherwise.
| Requirement | The number | What it really tests |
|---|---|---|
| Launch to fully rendered home screen | 15 seconds | Startup work, image sizes, and how much you do before first paint. Measuring it requires a signal beacon in the app |
| Screen to screen transitions | 3 seconds | What it costs to build a scene, and whether you build views before they're needed |
| Remote button response and tile navigation | 250 milliseconds | The hardest one. Focus handling and render cost on the main thread |
| Loading indicator appears | anything over 3 seconds | Honest progress states on every screen, including the ones nobody thinks of as slow |
| Response to a user request | 10 seconds | Your slowest network path, on a bad connection |
| Playback starts after initiation | 8 seconds | Manifest fetch, DRM handshake, and buffer strategy. Custom players must fire video start beacons; the Roku player does it for you |
| Total app package size | 4 MB or less | Asset discipline. Nobody believes this number until they measure |
Two observations from living with these. The 250 millisecond response budget separates SceneGraph engineers from people who write SceneGraph. On a 2019 stick it comes down to focus chain design and how much work happens on each key press, and raw device speed barely enters into it. And the 4 MB limit applies to the package you build, since your video streams separately. It drives every decision about what ships in the package and what gets fetched, and it's much easier to hold from the first commit than to claw back at the end.
Several requirements only switch on at scale. They're keyed to streaming hours averaged over the last three months, and they also apply to new apps projected to cross those thresholds soon after launch: Automatic Account Link above roughly 1 million hours a month, full voice control and Continue Watching above roughly 5 million, and Instant Signup for SVOD above roughly 10 million. If you're launching small, they aren't your problem yet. If you're launching a brand with an audience, they're day one scope, and Continue Watching and Instant Resume take effect on October 1, 2026.
3. The policy ones: cheap if you know them, a resubmission if you don't
- Accessibility is required. Apps must comply with applicable accessibility laws and honor the global closed captioning settings (On, Off, On instant replay, and On mute), with captions synchronized to audio on VOD. Closed captions and audio descriptions are required wherever the law requires them. Accessibility is also the work teams most often drop quietly when a schedule slips, and that's how it becomes a certification problem.
- Trick play needs thumbnails for VOD longer than 15 minutes. That means a thumbnail pipeline, which makes it a content operations task as well as an app task.
- Instant replay rewinds 10 to 25 seconds. It's a one‑line requirement that people routinely implement with an arbitrary number.
- The Options button is reserved during video playback for Roku's own system displays. You can use it only while your own UI is on top of the video.
- Don't override or interfere with the system screensaver.
- Use Roku's voice keyboards for email, PIN, and password entry.
- Version numbers in the manifest must be non‑zero and must increase with every submitted build. This is the most embarrassing possible reason to get bounced.
- Artwork and splash screens must represent the app clearly, use broadcast‑safe colors, be non‑transparent, and support both 1920x1080 and 1280x720, and the splash URI must be in the manifest. Store artwork, titles, and descriptions must suit all ages regardless of your content rating.
- Advertising and payments have their own documents. Video ads must follow Roku's advertising requirements, and transactional apps must integrate Roku Pay according to its integration requirements. Ads are where certification meets revenue. At Comcast I integrated the Roku Ad Framework with SCTE‑35 signal parsing and FreeWheel, and ad behavior that breaks the rules costs you the launch date and the revenue the ads were supposed to bring in.
What to actually do with this list
First, put the architectural requirements in your first design review. Don't leave them for the submission checklist. On‑device authentication, deep linking, the back stack, and persistent playback state are the four that turn into rewrites. Everything else on the list can be fixed in a sprint.
Second, buy the two named test devices and measure the whole way through. Put the launch beacon in early, plus the video start beacon if you have a custom player, and treat the numbers in the debug console as a regression signal. A performance threshold you find in week two is a task. The same one found the week of submission is a schedule problem.
Third, read the current criteria yourself before you submit. This article is a map. The list changes, the thresholds move, and you're judged against the version on Roku's site that day.
My own view after going through it: the criteria describe what a competent Roku app already does. Teams that treat certification as a launch task keep failing on rewrites. Teams that build to it from the first sprint usually pass on the first try, and they ship sooner.
Who is telling you this
I'm James Folk. I took the Roku channel for The Church of Jesus Christ of Latter‑day Saints from an empty repository through Roku certification (it's live today as Gospel Stream). I led the team that owned the Roku Video Player inside Comcast's Xfinity Stream, worked on the Peacock player at NBCUniversal, and built screens and extended the event system in the discovery+ Roku app. If you're building a channel, what a Roku channel actually costs covers the money side of the same work, and the full record is at Roku channel development. You can reach me at hello@jamesfolk.me.