A Roku certification checklist from someone who has passed it

Roku publishes its certification criteria in full, so the list is not a secret. What the document does not tell you is which requirements actually fail apps, which ones are cheap to satisfy at the start and expensive to retrofit at the end, and which numbers in it are the ones your team will argue about at 11pm the night before submission. That is what this is. I took a national organization's channel from an empty repository through Roku certification, and I have spent five years since inside players that live under these same rules at Xfinity Stream, Peacock, and discovery+.

Read the criteria as three different documents

The published list is organized by functionality: advertising, accounts and purchases, performance, app operation, deep linking, UI and graphics. That ordering is fine for an auditor and misleading for a team planning work, because it flattens three very different kinds of requirement into one numbered list.

Below, the current criteria sorted that way instead. Everything here is from Roku's published certification criteria, last updated April 2026; verify against the live document before you submit, because thresholds move and two of the requirements below have effective dates in October 2026.

1. The architectural ones: decide these before you write code

Everything happens on the device

Sign‑up and sign‑in must be on‑device. Roku prohibits external webpages, links to off‑device promotional material, and any other off‑device authentication or activation mechanism, and upgrades and downgrades must complete on the device too. Teams coming from web or mobile reach for a hosted login page by reflex, because that is how every other platform works. On Roku that is a rewrite, not a tweak. The same instinct fails elsewhere in the list: apps may not nest content or applications, embed browser screens, deep link into other apps, or offer any payment path other than Roku Pay.

Deep linking is not a feature you add later

Apps must support deep linking for all media types 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, which is why it belongs in the first architecture conversation and not the pre‑submission sprint.

The back button is a contract

Back returns the user to the previous screen or state, and on the home screen it exits the app to the Roku home screen, with at most a single confirmation dialog. This sounds trivial and it is the most common architectural tell of an app ported from another platform, because it means your navigation needs a real screen stack with restorable state rather than a pile of ad hoc transitions.

Playback state has to survive

Bookmarking is required for all VOD content longer than 15 minutes, stored for at least 30 days, and app updates may not force reactivation, relinking, or re‑login, and must persist saved data. Resume playback is a data model decision. On the Church's channel I implemented resume through the Roku registry, and where you keep that state, and how it survives an update, is the kind of choice that is free on day one and structural by day ninety.

2. The threshold ones: the numbers, and the device that matters

This is where most teams get caught, and it is because of one sentence in the criteria rather than the numbers themselves. Roku measures the performance requirements specifically 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 is testing 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 will otherwise have.

Roku performance thresholds, measured on the two named 2019 devices
RequirementThe numberWhat it really tests
Launch to fully rendered home screen15 secondsStartup work, image sizes, and how much you do before first paint. Requires a signal beacon in the app to measure
Screen to screen transitions3 secondsScene construction cost and whether you build views eagerly
Remote button response and tile navigation250 millisecondsThe hardest one. Focus handling and render cost on the main thread
Loading indicator appearsanything over 3 secondsHonest progress states everywhere, not just the obvious screens
Response to a user request10 secondsYour slowest network path, on a bad connection
Playback starts after initiation8 secondsManifest fetch, DRM handshake, and buffer strategy. Custom players must fire video start beacons; the Roku player does it for you
Total app package size4 MB or lessAsset discipline. The one number nobody believes until they measure

Two observations from living with these. The 250 millisecond response budget is the requirement that separates SceneGraph engineers from people writing SceneGraph, because on a 2019 stick it is decided by focus chain design and how much work happens per key press, not by raw device speed. And the 4 MB package limit is a constraint on your build, not your content: it drives every decision about what ships in the package versus what is fetched, and it is much easier to hold from the first commit than to claw back at the end.

Note also that several requirements only switch on at scale, keyed to streaming hours averaged over the last three months, and apply to new apps projected to cross those thresholds soon after launch: Automatic Account Link above roughly 1 million hours per month, full voice control support and Continue Watching above roughly 5 million, Instant Signup for SVOD above roughly 10 million. If you are launching small, they are not your problem yet. If you are launching a brand with an audience, they are day one scope, and Continue Watching and Instant Resume carry effective dates of October 1, 2026.

3. The policy ones: cheap if you know them, a resubmission if you do not

What to actually do with this list

Three things, in order.

Put the architectural requirements in your first design review, not your 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.

Buy the two named test devices and measure continuously. Put the launch beacon and, if you have a custom player, the video start beacon in early, and watch the numbers in the debug console as a regression signal all the way through the build. A performance threshold discovered in week two is a task. The same one discovered the week of submission is a schedule.

Read the current criteria yourself before you submit. This article is a map, not a substitute. The list changes, the thresholds move, and the version you submit against is the one on Roku's site that day.

The last thing worth saying is the thing the criteria cannot tell you: certification is not a gate you clear at the end, it is a description of what a competent Roku app already does. Teams that treat it as a launch task keep failing on rewrites. Teams that treat it as the platform's definition of working software tend to pass on the first try, and ship faster overall for it.

Who is telling you this

I'm James Folk. I took The Church of Jesus Christ of Latter‑day Saints' channel from empty repository through Roku certification, live today as Gospel Stream; led the team owning the Roku Video Player inside Comcast's Xfinity Stream; worked on the Peacock player at NBCUniversal; and built screens and enhanced the event system on the discovery+ Roku app. If you are 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. Reach me at hello@jamesfolk.me.