Roku app certification in 2026: what can block your release

From 1 October 2026, a Roku app that does not integrate the platform’s memory monitoring interface will not be published. Static Analysis reports an error and stops the release before it reaches manual review. That single change tells you most of what you need to know about how Roku app certification works: the requirements are documented, the enforcement is automated, and the list grows as your audience does. Here’s what the certification criteria demand now, what changes this autumn, and how to build the process into your delivery cycle instead of discovering it a week before launch.

What changes on 1 October 2026

Four things take effect on the same date, aimed at different groups. Two are platform-wide and apply to every app in the store. Two are keyed to streaming hours and apply only above a threshold.

Memory monitoring becomes a publishing gate

All apps will need to integrate the roAppMemoryMonitor interface and its events. Roku’s documentation is direct about the consequence: without those APIs, Static Analysis reports an error and blocks publishing. Since Roku OS 15.2, subscribed apps receive notifications when memory usage crosses 80%, 85%, 90% and 95% of the per-app limit.

Wiring in the API is trivial. Responding sensibly to a notification at 90% is not. The requirement asks, in effect, whether your app has a strategy for releasing resources under pressure, and on older Roku devices with limited memory that question has always mattered. Now it has a date attached.

The manifest and your minimum firmware move together

This is the change most likely to surprise a team reading only the certification criteria page. Static Analysis will also require rsg_version=1.3 in the manifest, and with it a minimum supported firmware of Roku OS 15.1 or later.

The practical effect is larger than a manifest edit. Raising your minimum firmware drops every device still running an older Roku OS out of your addressable base, which for an audience on ageing hardware is a product decision rather than a build flag. Teams supporting Roku OS 12 today have the furthest to travel.

While you are in the manifest, check the deprecated APIs list as well. Using a deprecated API may cause an app to fail certification testing, and an app inherited from another agency is worth auditing against both before anyone books a launch date.

Continue Watching reaches apps outside the US Streaming Store

Requirement 4.13 already obliges apps in the US Roku Streaming Store above an average of 5 million streaming hours per month to implement Continue Watching. From October, apps outside the US Streaming Store cross the same obligation at 1 million hours per month. TVOD, live linear and made-for-kids apps are excluded.

A regional broadcaster serving one language market will carry a requirement that a comparable American app does not reach until it is five times larger. For European developers that is the most consequential line in the document.

Instant Resume in the US Streaming Store

Instant Resume becomes mandatory for apps in the US Roku Streaming Store above 5 million hours per month, on the same date.

One change that already applies: deep linking for live

Separately from the October deadline, the spring 2026 certification update removed the exemption that let live streams and replays skip the deep linking requirement, and renamed section 2 to “Accounts and Purchases”. Both are in force now.

If your app carries live content and you built deep linking around the old exemption, that is real work rather than a documentation tidy-up, and it is already overdue.

What the Roku developer program expects before you submit

Much of what delays a first Roku app launch has nothing to do with code. The submission process asks for a set of assets and account details that teams routinely leave until the end, and the publishing process will not start without them.

Developer account and dashboard setup

Everything runs through the Roku Developer Dashboard. You create a Roku developer account, register the app, upload the package, and run the certification tools from the same place. The developer account is a long-lived asset holding your monetization setup, payout enrolment and certification history, so it should sit with the company rather than with an individual engineer or an agency.

What you must supply with the submission

Roku requires Streaming Store information in every language the app supports: an app name, a description, and a 540×405 poster as a JPEG or PNG. The app name must clearly identify the company behind it, you must hold the rights to it, and it cannot include the Roku name or anything misleading.

Ad-supported Roku apps must provide the URL path to an app-ads.txt file, the IAB protocol that records which sellers are authorised to sell against your inventory. If Roku asks to be added as an authorised seller, you add it. Apps that run no programmatic advertising are advised to say so explicitly in the file.

You also supply customer support details, meaning a URL, an email address and a phone number, plus named administrative and technical leads. TVE, TVOD, PVOD and vMVPD apps must include working login credentials with the submission, so prepare test accounts that will still be valid weeks later rather than throwaway ones.

Beta channels and pre-submission testing

Roku provides an access code for distributing beta versions of an app, which lets stakeholders preview the most recent upload. Worth knowing: updates are not reviewed for certification until formally submitted, so a beta that behaves perfectly proves nothing about passing certification. Use beta channels for product feedback and the certification tools for compliance.

Two small requirements catch new apps regularly. The app must carry a non-zero version number, incremented for every build and updated in the manifest. The splash screen must support both FHD and HD resolutions, use broadcast-safe colours, avoid transparency, and have its URI listed in the package manifest file.

Automated gates rather than a long review queue

The useful distinction between Roku and the other large connected TV platforms is not speed on its own. It is where the checking happens.

Roku states that a submitted app typically takes at least five business days to be certified and published, and that apps requiring additional testing should expect feedback within about a week. Neither Samsung nor LG publishes an equivalent figure, though implementation documentation from EaselTV, a vendor that submits apps across platforms as a routine part of its work, budgets 4 to 8 weeks for a Samsung Tizen review and 8 to 12 weeks for LG, and developers on Samsung’s own forum have reported longer waits. Treat those as practitioner estimates rather than published policy.

What Roku does publish is the tooling. Every Roku app must pass Static Analysis to be published. AVOD and free apps, along with subscription apps, must also pass App Behavior Analysis, which launches the app and checks state-driven results to verify compliance with the certification criteria. Errors from either tool block publishing automatically, before a reviewer sees the app at all. We’ve written separately about what makes Roku app development faster than other CTV platforms.

That shapes how you plan. Where a platform leans on a manual review queue, your exposure is calendar risk and you manage it by submitting early. Where the certification checks are automated and deterministic, your exposure sits at a gate you can run yourself, so you manage it by running those checks continuously during development. Once an app has passed both tools, a self-published app can schedule its own publishing start date, then goes to Roku for final review before going live.

The requirements that arrive with your success

Several Roku obligations are keyed to streaming hours, calculated as a monthly average over the past three months. They also apply to new apps projected to reach the threshold shortly after launch, which means a well-marketed launch can trigger them before you have any history at all.

The pattern is worth stating plainly: on Roku, commercial success generates engineering obligations. A Roku app that certified cleanly at launch can fall out of compliance eighteen months later without a single line of its code changing, purely because more people watched it.

That is a planning problem rather than a technical one. The integrations themselves are well documented. What hurts is doing them under pressure, in the same quarter you are also handling the growth that triggered them. Teams that handle this well decide at architecture stage which thresholds they expect to cross within two years, and build the hooks for those features early even if they switch them on later.

Your monetization model decides which rules apply

Roku’s certification criteria are written against app model types, and a single Roku app can combine several. Free apps give access to content without video advertising and without a recurring subscription fee. Live TV apps carry linear content supported by advertising. AVOD apps show video advertisements against on-demand content. SVOD apps charge a recurring fee. TVOD apps take a one-time fee to rent or purchase content, which Roku’s own definition extends to pay-per-view events and premium early-access offers. TVE and vMVPD apps authenticate against an existing pay-television subscription. If you are still settling which of these models you run, our breakdown of VOD and OTT business models covers the commercial side of that choice.

The rule that catches people: where an app offers subscriptions alongside advertising or transactional content, it must comply with the requirements for each model. A hybrid service carries all of them, and each brings its own test cases into the certification process.

A hybrid catalogue also multiplies the integration surface. La Xarxa+, which we built for Xarxa Audiovisual Local, the Catalan regional network, carries more than thirty local television channels and radio stations across web, mobile and connected TV, on our CTV App Framework with analytics, payment gateways and backend systems integrated into it. Each of those pieces has certification criteria attached to it, and the work is in making them behave consistently rather than in any one of them individually.

The limits that decide your architecture

Some certification criteria are checklists. Others quietly determine how you build.

Performance measured on 2019 hardware

Roku apps must launch to a fully rendered home screen within 15 seconds, complete screen-to-screen transitions within 3 seconds, respond to Roku remote button presses within 250 milliseconds, and start video playback within 8 seconds of initiation. Any process visible to users that runs longer than 3 seconds needs a loading indicator, and apps must respond to user requests within 10 seconds.

Those numbers are not measured on your development hardware. Roku specifies that requirements 3.2 to 3.6 are measured on the Roku Streaming Stick+ (Amarillo-2019 3810X) or the Roku Premiere+ (Gilbert 4K 3921X), and reserves the right to block launch across all other Roku devices if the app fails on those. Your performance budget is set by hardware from 2019.

Measurement is your responsibility too. Apps need a signal beacon to measure launch times, verified through the debug console, and apps with custom video players must fire video start beacons themselves.

The 4 MB app package

The app package must be 4 MB or less. Combined with the rule that an app must be available on all Roku device models receiving the current Roku OS, and that all content from the service must be available on all those models, this settles a set of architectural questions before you write anything. Assets load remotely. Libraries stay lean. Anything you were planning to bundle, you are not bundling.

Roku device models and the test matrix

Roku requires testing across multiple Roku device models before submission, specifically a combination of Roku devices with varying processing power and memory, because the app must perform on every model still receiving OS updates. If your QA estate is three recent Roku devices, you are testing the easy half of your install base.

This is the same discipline that applies when launching cloud-based OTT services: the constraint that breaks you in production is rarely the one you rehearsed against.

The closed loop around accounts and payments

Section 2 is where broadcasters running a unified stack across platforms hit friction.

Roku apps must integrate on-device authentication, and sign-up and sign-in workflows are prohibited from using external web pages, off-device promotional material, or any other off-device authentication mechanism. Upgrades and downgrades must also complete on the device.

Apps offering transactional content or services must integrate Roku Pay, covering signup, sign-in, payment and entitlements. Requirement 2.5 goes further: apps may not facilitate or direct customers to any method of payment other than Roku Pay, and must disclose any non-Roku SDK, library or feature that enables or links to monetary transactions, with Roku holding the right to approve or deny it.

Deep linking closes the loop from the other side. Apps must support deep linking for all media types and implement Direct to Play for voice playback commands, while being prohibited from deep linking into other apps or directing users out of the app to buy content, goods or services. Nested content, embedded browsers and cross-app functionality are all out.

If you operate a single identity and billing stack across web, mobile and other connected TV platforms, Roku is the platform that expects you to work inside its own. That is a commercial question as much as a technical one, and it belongs in your business case rather than in a sprint retrospective. Teams running Roku alongside Android TV or Tizen usually find it during integration rather than during planning. The same principle applies to rights and playback: certification will not tell you your DRM strategy is wrong, only that your app failed.

Building certification into the delivery cycle

Three practical points follow from how the process actually works.

An updated app needs re-certification

Roku is explicit that updating the implementation code of an existing Roku app means the app must be re-certified and re-published, while changing the content it streams does not. A hotfix on Roku is not the same operation as a hotfix on the web, and your release cadence has to account for that. Batch code changes deliberately rather than shipping small updates continuously.

Certification compliance is also ongoing rather than a one-off. Roku reserves the right to remove published apps from the Roku Streaming Store at any time if they do not maintain compliance with the criteria, under the terms of the distribution agreement.

Run the certification tools continuously

Static Analysis, App Behavior Analysis and Roku’s test automation software are all available to developers throughout Roku app development, not only at submission. The automation tools let you write and execute test cases covering purchasing, performance, deep linking and other certification criteria.

Treating certification testing as part of the build, alongside your own unit and integration tests, converts a launch-blocking surprise into an ordinary failing check. This is the single highest-value habit we bring into Roku projects, and it costs nothing but discipline.

Watch the publishing calendar

Roku blacks out the Streaming Store each year around the holiday season and advises submitting early because of the higher volume of submissions. In the 2025 season that meant two windows, one across Black Friday and one from mid-December into early January. Roku announces the dates for each season separately, so check them before committing to a launch date.

The arithmetic matters more than the exact dates. With a minimum of five business days to certify and publish, and the possibility of a second certification round, a December launch needs locking down in October. For any broadcaster whose year peaks in December, that is a hard constraint rather than an inconvenience.

What official partner status changes, and what it doesn’t

We are an official Roku development partner, so it’s worth being straight about what that does and doesn’t mean. The certification criteria are the same document for everyone, and Static Analysis applies the same rules to our submissions as to anyone else’s. Partner status is not a shortcut through the gates described above, and you should be sceptical of anyone who implies otherwise.

What it gives us is context: a working relationship with the platform, and enough accumulated experience across Roku certification projects to know which requirements are quick to satisfy and which quietly reshape an architecture. That is the difference between reading the criteria and knowing what they cost.

Where this leaves you

Roku certification rewards teams that treat it as a design input and costs time for teams that treat it as paperwork. The review cycle is short and the criteria are published in full, which makes the process more predictable than most. The automated gates are deterministic, they run before any human looks at your app, and the obligations attached to streaming hours mean the standard you certified against at launch is not the standard you will be held to in two years.

Plan against the 2019 hardware, wire the certification tools into your pipeline, prepare the store assets and test accounts early, and decide which thresholds you expect to cross. The rest is execution.

If you’re planning a Roku app launch or your app is approaching one of the streaming hour thresholds, we can map the certification requirements against your current build and sequence the work before it becomes urgent. Talk to our experts in media and entertainment engineering.

FAQ

How long does Roku app certification take?

expand_more

Roku states that a submitted app typically takes at least five business days to be certified and published, and that apps needing additional testing receive feedback within about a week. That is review time, not project time. The work of meeting the certification criteria, particularly threshold-triggered features and performance requirements, sits with your team before submission.

What blocks a Roku app from being published?

expand_more

Static Analysis errors block publishing for every Roku app, and App Behavior Analysis errors block free, ad-supported and subscription apps. Both run automatically in the Roku Developer Dashboard. From 1 October 2026, a missing roAppMemoryMonitor integration is itself a Static Analysis error, so a Roku app that passed certification last year can fail without any change to its own code.

What do you need to submit an app to the Roku Streaming Store?

expand_more

A packaged Roku app with a non-zero version number, Streaming Store information in every supported language including an app name, description and a 540×405 poster, an app-ads.txt path for ad-supported apps, customer support contacts and named administrative and technical leads. TVE, TVOD, PVOD and vMVPD apps must also supply working login credentials.

Do Roku certification requirements change as an app grows?

expand_more

Yes. Several requirements are keyed to streaming hours averaged over three months. Apps with login above 1 million hours per month need Automatic Account Link, apps above 5 million need full voice controls, and SVOD apps above 10 million need Instant Signup. New apps projected to reach a threshold shortly after launch are covered too.

Is Roku certification harder than Samsung Tizen or LG webOS?

expand_more

They work differently rather than one being simply harder. Roku publishes a target of around five business days and enforces through automated tooling that blocks publishing before manual review. Samsung and LG do not publish equivalent timings, and practitioner estimates put their reviews in the weeks-to-months range. On Roku the risk is a deterministic gate; elsewhere it is queue time.