Roku app development

The certification stopwatch

Most platforms tell you to be responsive. Roku tells you how many seconds you have.

• Launch: 15 seconds. The app must reach a fully rendered home screen within fifteen seconds (criterion 3.2).
• Navigation: 3 seconds. Scene-to-scene transitions must complete within three seconds (3.3).
• Playback: 8 seconds. Content must start playing within eight seconds of initiation (3.6).
• Package: 4 MB or less (3.7).

Read those together and a design constraint falls out immediately. Fifteen seconds to a fully rendered home screen, measured on the oldest hardware you support, means the home screen has to render from something cached or something small and fill in the rest afterwards.

The 4 MB package is the one that changes how designers work. That is the app, not the content — but it means your images are fetched, not shipped, and every asset in the bundle is a negotiation. Teams arriving from a 4 GB tvOS bundle find this the most jarring number on the platform.

Underneath the timings sits the number that explains them. BrightScript running on the SceneGraph render thread has roughly 16 milliseconds per frame to do its work if the app is to hold a smooth frame rate. Anything slow on that thread — a heavy init(), parsing a large catalogue response — is not a slow function, it is a dropped frame. Roku's own optimisation guidance is to keep init() minimal and to push filtering and shaping of data server-side.

That is why the certification timings are usually an architecture problem rather than a tweak: an app that renders in eighteen seconds fails, and the fix is your data-loading strategy. We measure against these numbers from the first sprint rather than discovering them at submission.

Treat the three timings as acceptance criteria on every story. They are cheaper to hold continuously than to retrofit, because the retrofit is usually your data-loading strategy.

The rules changed in April, and bite in October

Roku announced a Spring 2026 update to its certification criteria on 1 April 2026, and the parts with deadlines attached take effect on 1 October 2026.

Two features stop being optional once an app is popular enough:

• Instant Resume becomes required for apps in the U.S. Streaming Store averaging more than 5 million streaming hours per month over the preceding three months.
• Continue Watching becomes required for those same apps, and for apps outside the U.S. Streaming Store averaging more than 1 million streaming hours per month — including new apps projected to reach those thresholds shortly after launch.

That last clause is the one to read twice. A new app expected to pass the threshold soon after launch is in scope from the start, so a successful launch does not buy you a grace period; it moves you into the requirement.

The update also restates that apps must support deep linking for all media types under Roku's deep linking policy.

If you are scoping a Roku build now for a service with real audience, treat Instant Resume and Continue Watching as in scope rather than as a phase two. Retrofitting resume behaviour touches the player, the backend and the home screen at once.

Billing happens on the device, and that is the opposite of Apple

This is the commercial fork, and it catches teams who have just finished an iOS build and assume the same answer applies.

Roku certification requires transactional apps to integrate and enable Roku Pay, including signup, sign-in, payment and entitlements (2.1). It further prohibits sign-up workflows that use external webpages or links to off-device promotional or marketing material (2.2). Sign-ups, sign-ins, upgrades and downgrades all complete on the device.

Put that next to iOS, where the reader-app route and the External Link Account Entitlement exist precisely so a streaming service can send subscribers to its own website — at the cost of giving up in-app purchase entirely.

So the two platforms are not merely different, they point in opposite directions:

• Apple: you may keep your own billing, if you accept a narrow set of rules and forgo in-app purchase.
• Roku: you may not. Transactional flows run through Roku Pay, on the device.

Roku app development for vod platforms feels this most sharply, because a subscription business has a billing stack it did not plan to duplicate. That is a commercial decision for your finance team, and it belongs in the scoping conversation rather than in a certification report.

Deep linking is mandatory, not a nice-to-have

Certification requires deep linking for all media types (5.1), and Direct to Play so that voice playback commands work (5.2). It also prohibits deep linking into other apps or directing users out of your app to purchase content (5.3).

This matters more on Roku than elsewhere because the platform's own search and voice surfaces are how a lot of viewers arrive. An app without working deep links is invisible to the part of Roku that drives discovery, and it will not pass certification anyway.

One more that shapes the player: apps must display thumbnails during trick play for VOD content longer than fifteen minutes (4.7). If your packaging pipeline does not already produce trick-play thumbnails, that is an encoder workstream, not an app one — the same shape of surprise as fragmented MP4 on Android or I-frame playlists on Samsung.

Roku app development for broadcasters tends to hit the thumbnail requirement first, because long-form catalogue content crosses the fifteen-minute line by default.

What actually carries over

Being honest about this is the difference between a realistic estimate and a disappointing one.

Carries over. Your API contracts. Your entitlement model, in design if not in implementation. Your catalogue structure and metadata. Your design system, as specification. Your understanding of your own product. Your trick-play and packaging work, once it exists.

Does not. The code. All of it. There is no shared runtime with any other platform in your rollout, no cross-compilation worth having, and no framework that lets a React team be productive on day one.

That makes Roku the platform where the sequence matters most. Build it after the others and you are implementing decisions that are already settled, which is fast. Build it first and you are making product decisions in an unfamiliar language, which is not.

Roku app development for fast channel operators is the exception worth noting: a linear FAST channel has a much smaller surface than a full VOD catalogue, so the BrightScript work is proportionally smaller, and Roku's reach makes it attractive early.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number.

1. Whether this is your first Roku app. There is no reuse from other platforms, so the first one carries the whole learning curve.
2. Whether you need Roku Pay. A free or ad-supported app skips the entire billing integration. A subscription app does not.
3. The oldest device you support. The 15-second launch and 8-second playback criteria are measured on the hardware, so an older player sets the budget your architecture has to meet.
4. Whether trick-play thumbnails exist in your pipeline. If not, add the encoder work.

Tell us those four and you get a real number rather than a range that covers everyone.

Who builds it

Everything above is how we actually work rather than a checklist assembled for this page.

We build our own tooling. VibeView came out of exactly this problem — shipping to every platform means testing on every platform — and Roku is among its targets, which matters here because the certification criteria are timings and timings can only be measured on the device.

When a project needs middleware rather than only an app, MwareTV is a technology partner of ours, so both sides come from one conversation.

And the people who scope your project are the people who build it. There is no account layer between you and the engineer who knows why your home screen has fifteen seconds.

Where Roku sits in the rest of your rollout

Roku is usually best placed after at least one other television platform, because everything except the code transfers — and by then the product questions are answered, so the BrightScript work is implementation rather than discovery.

Fire TV is the natural comparison: both are streaming-stick platforms with their own stores, but Fire TV is Android underneath, so it shares a lineage with work you may already have. Roku shares none.

We build these, end to end

The BrightScript and SceneGraph app, the performance work the certification timings demand, Roku Pay integration where the business model needs it, deep linking and voice, trick-play support, and Channel Store submission.

If you already have an app on another platform, we will tell you honestly what transfers — which is the design and the contracts, not the code — before you commit to a number based on someone implying otherwise.

Send us your business model, the oldest Roku device you intend to support, and whether your packaging produces trick-play thumbnails today. You will get back a scope and a number rather than a brochure.