This website uses cookies to help improve your user experience
For years, Roku development revolved around its own stack: BrightScript for application logic and SceneGraph for UI. Developers building for Roku had to work within that stack, with little choice of language or framework. But that’s going to change.
At its 10th annual Developer Summit on September 23-24, 2026, the company announced Roku TypeScript support in the new RSG 2.0 SDK, bringing a new language into the familiar BrightScript plus SceneGraph development equation1.
The public beta opens on October 29th. For now, developers will be able to sideload RSG 2.0 apps, but they won’t be able to publish them to the Roku Streaming Store. That gives teams time to explore the SDK before making decisions about production apps.
It also leaves some interesting questions: how much easier will it be to bring a TypeScript developer onto a Roku project? And what would justify migrating an app with years of BrightScript behind it?
We brought those questions to Ivan Popovich, Senior Roku Developer at Oxagile. His perspective is especially useful for teams that need to weigh the appeal of a new SDK against the realities of an app they already maintain.
Key takeaways:
After years of BrightScript, Roku opens the door to TypeScript. It has made its preference for the new SDK clear: RSG 2.0 runs on the Hermes JavaScript engine, which can execute plain JavaScript, but Roku strongly recommends writing apps in TypeScript and says it may eventually make that a requirement.
The SDK will be released under the MIT license, so developers will be able to inspect its code as they test the beta1.
As Ivan puts it:
“Roku just made a rare language-level move. BrightScript finally has company.
But Roku isn’t abandoning BrightScript, the barrier to entry for new developers is lowering. And that’s the biggest takeaway.”
BrightScript has always made Roku feel more isolated. Engineers coming from mainstream frontend development faced two learning curves at once: first the language, then Roku itself. That narrowed the pool when hiring a Roku BrightScript developer.
RSG 2.0 removes the first of those hurdles since a TypeScript engineer can start with a familiar language, but the Roku stack still takes time to learn. How an app behaves on the TV, responds to the remote, and performs on Roku hardware still depends on platform-specific knowledge.
Ivan shares his thoughts:
“I’d say that Roku expertise will still be niche, it’s just that the route into it may become much shorter.
A more familiar language can change who joins a Roku project, how quickly they become productive, and how such development fits into the rest of the engineering. That’s a much bigger conversation than syntax.”
Roku’s earlier feature updates changed what viewers saw on screen. Its September announcements touch three parts of the Roku ecosystem, including how apps are written, how developers can inspect the SDK, and where they can test their work.
Roku says RSG 2.0 uses existing SceneGraph components to build its UI1. Developers will apply TypeScript, while SceneGraph continues to shape what happens on screen.
Ivan explains:
“Developers gain access to modern tooling, type safety, and a familiar TypeScript ecosystem while continuing to build on the same Roku foundation.
Knowing TypeScript won’t make someone a Roku engineer overnight. You still need to understand SceneGraph, the threading model, focus and navigation, device limitations, memory management, video playback, and Roku certification.”
Testing a small change can take several rounds on a Roku device: install the build, navigate with the remote, check the debug console, make a fix, and install it again. The Roku Cloud Emulator brings much of that loop into a browser or an automated test run.
Teams can create virtual players and TVs, sideload apps, read the console, and manage devices through REST APIs2. Access is rolling out to developer accounts in phases.
The appeal is a repeatable way to catch functional problems as code changes, including in CI/CD pipelines. Roku positions the emulator for tests that do not depend on hardware-specific performance. Launch speed, memory use, and playback behavior across physical models need checks on real devices.
Ivan notes:
“With the Roku Cloud Emulator, Roku is making development look more like the development workflows engineering teams already use elsewhere.”
A new SDK can leave developers with an awkward debugging question: is the unexpected behavior in their app, or in the framework? Roku plans to release RSG 2.0 under the MIT license and accept merge requests for both its code and documentation on GitLab. Its other developer repositories are moving there too1.
Ivan on why that matters:
“For me, the interesting part of open-sourcing RSG 2.0 isn’t that everyone can suddenly start contributing code. Most Roku developers probably won’t. The bigger change is that when something goes wrong, we can look deeper into the SDK instead of treating its behavior as a black box.
That matters on Roku because some of the hardest problems only show up under specific platform or device conditions. More visibility into the SDK gives experienced developers another place to investigate those problems when logs and documentation do not explain a component’s behavior.”
The answer depends on your current architecture, release plans, and what RSG 2.0 proves in testing. Our expert engineers providing Roku development services can assess the codebase and help define a focused path before you budget a migration.
Behind a production Roku app sit custom screens, account flows, ad rules, playback fixes, and performance work for older devices.
Ivan comments:
“For greenfield development, TypeScript should make Roku more approachable. Existing products are a different story.
Most production Roku apps represent years of investment in BrightScript and SceneGraph, and those codebases will continue to provide value for years to come. Teams will have to decide what stays, what moves to RSG 2.0, and when migration is worth the cost. All of those decisions require someone who understands both generations of the Roku stack.”
There is no technical deadline pushing that decision either. Roku BrightScript APIs are still being updated, with the OS 16.0 developer beta describing changes to the language’s 2D graphics interfaces3. And when the RSG 2.0 beta opens on October 29, apps will initially be limited to sideloading. Roku expects Streaming Store publishing support in 20271.
Ivan points out:
“I would be very careful not to imply BrightScript is being killed. Roku’s current OS 16 release notes still document new BrightScript APIs, and the RSG 2.0 announcement talks about the direction for the new SDK, not an announced end date for existing BrightScript apps.”
The calculation changes when the current architecture starts getting in the way. A major redesign, rising maintenance effort, or persistent difficulty hiring BrightScript engineers could give a team a concrete reason to investigate RSG 2.0.
That investigation does not have to start with a rewrite. One representative screen or workflow may be rebuilt as a sideloaded prototype and tested on relevant Roku devices. The team can compare engineering effort and behavior, see which custom features need to be recreated, and get a better idea of what the move would cost.
Any estimate also has to account for more than source code. Sign-in, ads, playback, deep links, remote navigation, and performance on supported devices still have to work in the finished app, and changes to implementation code can trigger Roku recertification4. That could make existing Roku experience more valuable during the transition.
Platform choice, feature scope, and reusable code can all shift the cost. Our OTT calculator gives you a ballpark in minutes, which you can then refine around your Roku requirements.
A viewer may never know which language powers an app. They will notice a slow launch, focus jumping to the wrong tile, or a long wait for playback. Roku expects RSG 2.0 apps to face the same certification requirements as BrightScript applications1.
Ivan mentions:
“TypeScript changes the development environment, but the app still has to behave like a ‘good Roku citizen’.
Certification cares about how that app works once it’s running on a Roku device. Launch time, playback, navigation, deep linking, memory and performance constraints, mandatory platform features. Those problems don’t disappear because the source code is written in a more familiar language.”
The requirements are measurable. Under Roku’s current approval criteria, an app must show a fully rendered home screen within 15 seconds and move between screens within three seconds. Roku also calls for testing on devices with different processing power and memory4. Test launch, navigation, deep linking, and playback on real devices early, while there is room to change the implementation.
A public media organization had already moved its Roku app from Direct Publisher to SGDex. By the time Oxagile joined, the codebase was complex and closely tied to the framework. Rebuilding the whole app would have taken substantial time and money, so the team made targeted changes:
This project predates RSG 2.0. It shows why the value of an existing architecture belongs in any conversation about a new SDK.
Roku has made its preference plain. It recommends TypeScript for RSG 2.0 apps, may eventually require it, and has a longer-term goal of compiling TypeScript into native executables. That gives new development a direction. What it means for a particular product will become clearer as teams build with the beta and test the results on Roku devices.
Ivan’s opinion:
“Nobody should interpret the announcement as ‘rewrite your Roku app in TypeScript tomorrow’.
Either way, custom development across all big-screen platforms, Roku included, seems to be getting more affordable and unified, which I think is a great move.
Will a web engine or even a React Native renderer for SceneGraph appear someday as well? We’ll see.”
A feature that takes too long to ship, sluggish navigation, or rising maintenance costs all call for a different fix.
Tell us what is happening in your app. Our Roku engineers can help assess the code, define the next change, and decide whether an RSG 2.0 prototype is worth exploring.
1. RSG 2.0 SDK available for beta testing on October 29th — Roku Developer Blog
2. Cloud Emulator — Roku Developers
3. Roku OS 16.0 available to developers for beta testing — Roku Developer Blog
4. Certification criteria — Roku Developers
Yes. Roku is adding it through the RSG 2.0 SDK, with a public beta starting October 29, 2026. During the beta, developers can sideload apps for testing. Roku expects Streaming Store publishing support in 2027.
Roku has not specified a TypeScript version in its announcement. Once the beta documentation is available, teams can check which compiler versions and related tools the SDK supports before setting up a project.
No. Roku recommends TypeScript for apps built with RSG 2.0, while existing BrightScript apps have no announced retirement date. A new language option does not make a working codebase obsolete.
No migration deadline has been announced. If an app is doing its job, an SDK beta alone is a thin reason to schedule a rewrite. Rebuilding one representative screen or flow can tell a team much more about the effort involved and what the new stack could offer its product.
Roku expects RSG 2.0 apps to meet the same requirements as BrightScript apps. TypeScript will not buy an exception for a slow launch, unreliable playback, or remote navigation that loses focus. Roku plans to announce separately when RSG 2.0 apps can be submitted to the Store.
Roku has not yet explained whether BrightScript and TypeScript can coexist in one RSG 2.0 project, or how existing components could be reused. Before designing a hybrid app, check the beta documentation and test the specific integration the product needs.
Roku has announced no deprecation timeline. Its comment that “TypeScript may eventually become mandatory” concerns RSG 2.0 development. Meanwhile, the Roku OS 16.0 developer beta still includes new BrightScript APIs.
