Why This Matters

If your product is a streaming service, a video-on-demand library, a live event platform, or a connected-TV ad-supported channel and your users want to watch it on their living-room television, you cannot route around the smart TV layer the way you can route around an unsupported web browser. Television is where premium video is consumed in 2026 — over half the world's households now own a smart TV (electroIQ, Smart TV Statistics 2025), and the share of streaming watch-time that happens on a TV rather than a phone keeps climbing every quarter. Each TV ships with one operating system, that operating system decides which apps it will run, and the user does not install a different one because they want to watch your show. The four jobs of a streaming product on television — render a UI the user can drive from a remote, play video, handle DRM and licence acquisition, and report quality-of-experience telemetry — have to be done six different ways, because there is no cross-platform runtime that works on every modern TV the way the browser works on every modern desktop. The article gives you the structural picture of the six platforms — which ones share the HTML5 web-app model, which one is a proprietary language island, which one has the strongest media stack, and which one has just changed under your feet — so you can plan the migration order, the format matrix, and the team allocation before the first kanban card is written.

The Six Platforms and Their Programming Models

The first thing to internalise is that the six TV platforms split cleanly into three programming-model groups, not six independent codebases. Two of the platforms share the HTML5 web-app model and a JavaScript-driven element. Two of the platforms share a Java / Kotlin native-app model on top of ExoPlayer (until very recently — see below). One of the platforms uses a proprietary scripting language called BrightScript on top of a scene-graph framework. And one of them just switched programming models entirely. Grouped that way, the platform sprawl becomes manageable: you write three player implementations, not six.

A grouped diagram of the six smart TV platforms, with the HTML5 web app group on the left containing Samsung Tizen and LG webOS and Hisense Vidaa, the Android native group in the middle containing Google Android TV / Google TV and Amazon Fire TV legacy Fire OS, the BrightScript group on the right containing Roku OS, and Amazon Vega OS as a fourth standalone box with a React Native and HTML5 stack appearing in 2025 and 2026 Figure 1. The six smart TV platforms split into three programming-model groups, plus Vega OS as the 2025–2026 new entrant that breaks the old four-platform pattern. Building three player codepaths covers five of the six surfaces; Vega OS is the wildcard that adds a fourth.

The HTML5 web-app group — Samsung Tizen, LG webOS, and Hisense Vidaa — runs an HTML page inside a browser engine that ships with the TV, with extra device APIs the platform exposes to JavaScript for things like the remote-control input, the system video player, the DRM key-exchange flow, and platform-specific lifecycle events such as "the TV is going to standby". The browser engine is a fork of WebKit on Tizen, a fork of WebKit on webOS until webOS 6 and a fork of Chromium on later versions, and a Linux-based custom browser engine on Vidaa. The page is packaged as a .wgt file (a glorified ZIP) on Tizen, an .ipk file on webOS, and a similar packaged-HTML format on Vidaa, signed by the vendor's developer portal before it goes to the device.

The Android native group — Google's Android TV and Google TV, and the soon-to-be-legacy Amazon Fire OS — runs Java or Kotlin apps packaged as Android .apk files, with the player backed by Media3 / ExoPlayer (the modern open-source media player that Google maintains; in May 2026 the stable version is Media3 1.10) and DRM handled through the standard Android MediaDRM framework with Widevine as the dominant scheme. Android TV is the platform with the strongest media stack of the six because Android itself was designed as a media-capable mobile operating system; the TV variant inherits all of it.

The Roku group is a group of one. Roku OS runs apps written in BrightScript, a proprietary scripting language Roku created in the 2000s, with a UI framework called SceneGraph that uses XML for the layout and BrightScript for the behaviour. Video playback is one specific node in that scene graph called the Video node, which accepts an HLS or DASH manifest URL and a DRM-parameters block. Every Roku streaming app on the market — Netflix, YouTube, Hulu, Disney+, every smaller channel in the Roku Channel Store — uses the same Video node under the hood.

Amazon Vega OS, finally, is a new programming-model group all by itself. The Vega OS user interface and applications are written with React Native plus standard web technologies on top of a Linux base; Vega is not Android and Android .apk files do not run on it (Amazon Developer, Run your app on Vega Virtual Device or Fire TV Stick, 2026). The first device to ship with Vega was the Fire TV Stick 4K Select in October 2025, and by January 2026 Amazon had confirmed that all future Fire TV Sticks would launch with Vega, ending the line of Android-based Fire OS streaming sticks (AFTVnews, Amazon confirms all future Fire TV Sticks will run Vega OS, April 2026). The implication for a streaming app team is large enough that we give Vega its own section later.

The summary that helps the most when planning a roadmap is this. If you ship one HTML5 player codebase, you cover Tizen, webOS, and Vidaa with platform-specific shims for the device APIs. If you ship one ExoPlayer-based Android app, you cover Android TV / Google TV today and (importantly) you still cover the installed base of Android-based Fire OS devices, which keeps generating revenue for several more years. If you ship one BrightScript SceneGraph app, you cover Roku. The Vega OS app is its own React Native project. Four implementations, six platforms, and a measurable engineering plan.

Market Share and Why It Drives Build Order

You do not ship to all six platforms in parallel. You pick a build order based on where your viewers actually live, and that is a regional question.

The global market for smart-TV operating systems in 2026 is led by Android TV / Google TV with about 35–40 percent of in-use televisions worldwide, followed by Samsung's Tizen at roughly 19–23 percent, LG's webOS at 12–25 percent (the spread between estimates is large because some sources count active devices and others count shipments), and Roku at roughly 10–11 percent. Amazon Fire TV holds roughly 8 percent of the global installed base. Vidaa-on-Hisense — and Vidaa-on-Toshiba in markets where Hisense owns the Toshiba TV brand — holds the residual 3–8 percent and is growing fastest in the value segment of the market (electroIQ, Smart TV Statistics 2025).

The United States market shows a very different shape. In US broadband households as of Q1 2026, Roku leads with about 28 percent of in-use televisions, Samsung Tizen is second at 23 percent, and Amazon Fire TV, LG webOS, and Vizio SmartCast — note that Vizio SmartCast is a separate platform we discuss only as a footnote at the end of this article — hold the mid-tier (Parks Associates, Roku and Samsung Dominate Connected TV Platforms, April 2026). Apple tvOS, gaming consoles, and Android TV / Google TV hold smaller US shares because the US market underweights Android TV relative to its global presence.

The arithmetic that follows is the build-order one. Let us suppose your team has the budget to ship three TV apps in your first year of TV presence. The picks change with your audience geography.

  • A US-first product ships Roku first (because Roku is 28 percent of US TVs and BrightScript is its only path), Samsung Tizen second (because Tizen is 23 percent of US TVs and the same HTML5 player codepath you ship to Tizen reuses across LG webOS and Vidaa with platform shims), and Amazon Fire TV / Vega third (because Amazon owns the streaming-stick category in North America and the Vega migration is now urgent). LG webOS is a fast follower that reuses your Tizen JavaScript with shimmed device APIs.
  • A Europe-first product ships Samsung Tizen and LG webOS first (because Samsung and LG together dominate European living rooms and your HTML5 codepath covers both), Android TV / Google TV second (because operator-supplied set-top boxes in Europe run Android TV in large numbers), and Vidaa third (because Hisense and Toshiba are gaining share in the European budget segment).
  • A global product ships Android TV / Google TV first (because it is the single biggest global slice), Tizen and webOS together as the HTML5 pair second (because they cover Korea, Europe, and the Middle East at scale), and Roku third (because the US share is too big to ignore even if the global share is small).

A product that targets a single region rarely needs to fight all six in year one. The exception is a major OTT brand whose contracts require a presence on every meaningful surface from day one — Netflix, Disney+, Max, Apple TV+, Prime Video — and even there the engineering reality is that each app ships on its own schedule, not in lockstep.

Samsung Tizen: AVPlay, HTML5, and a PlayReady-First DRM World

Samsung's Tizen is the operating system on every Samsung Smart TV shipped since 2015, and is now on its ninth major version. Tizen 9.0 was launched on Samsung's 2025 TV lineup, with a 2024-lineup rollout starting in mid-2025 and a 2023-lineup rollout in early 2026 (Tom's Guide, Samsung is giving these older TVs a big Tizen OS upgrade, 2026). The Tizen 9.0 release added a redesigned settings menu and brought the TV's design language in line with Samsung's One UI on phones — visible to viewers but not particularly disruptive for app developers.

A Tizen app is an HTML5 application that runs inside Samsung's Web Engine, a fork of WebKit. The page renders to the screen, listens for remote-control key events through standard JavaScript key handlers, and plays video through one of two paths: the standard HTML5 element, which works for most casual playback, or AVPlay, Samsung's proprietary JavaScript API that exposes deeper control over the underlying media pipeline. AVPlay is the production path that every streaming service of any size uses on Tizen. The reason is that the HTML5 video element on Tizen does not expose the controls a streaming product needs — DRM with HTTP-header-bearing licence requests, fine-grained adaptive-bitrate hints, frame-stepping for trick play, audio-track and subtitle-track switching with full metadata, and the device-level events that tell your app the TV is going to standby in 200 milliseconds and you should stop fetching segments now. AVPlay was first shipped in Tizen 2.3 in 2015 and has been refined every year since (Samsung Developer, AVPlay API, 2026).

The streaming-format support of AVPlay covers HLS, MPEG-DASH, Smooth Streaming, and progressive download, with DASH audio-track switching supported since Tizen 5.0 and DASH text-track switching with TTML and WebVTT support layered on top (Samsung Developer, Playback Using AVPlay, 2026). The DRM matrix is the part that surprises engineers coming from the web. PlayReady is the dominant DRM on Tizen — it is the DRM Samsung built first-class support for, the DRM every Samsung-issued streaming partner certifies against, and the DRM whose licence-request mechanism the AVPlay setDrm() method was modelled around. Widevine Modular is also supported as a secondary DRM, more recently added and useful when the same .cbcs-encrypted CMAF source is being served to a multi-DRM catalogue, but PlayReady is the path Samsung's certification process expects.

The detail that catches teams out is the codec ladder Tizen actually accepts. AV1 was added to Tizen TVs starting with the 2020 model year, but Samsung's 2021 and later TVs have a longstanding known issue where AV1 over MPEG-DASH using CMAF segments does not play correctly in the browser path — a defect Samsung had not fixed as of mid-2025 and that affected every Samsung TV browser of that era (Samsung Community thread, Tizen browser AV1 codec problem with DASH, 2025). AVPlay does not have the same browser-path defect, but a team that ships its TV app as a hosted web page rather than a packaged AVPlay app is exposed to it. The 2026 production guidance is: ship the AVPlay path on Tizen and use H.264 (AVC) or H.265 (HEVC) as your primary codecs, with AV1 as an opt-in secondary path that you flag-test on each TV model year.

The remote-control input model is the other piece of Tizen that surprises teams. Tizen apps receive remote-control key events via a Samsung-specific JavaScript event with a fixed key-code map (the OK button, the four arrows, the back button, the home button, the four colour buttons that exist on every Samsung remote, the play/pause/stop transport keys, and the media-fast-forward and media-rewind keys), and the app must register the keys it wants to receive with the tizen.tvinputdevice.registerKey() call. Keys that are not registered get swallowed by the system and never reach the app. This is the source of the classic "the back button does not work on Samsung TVs" bug that every team ships at least once.

LG webOS: Native HTML5 and a Modern Chromium Engine

LG's webOS is the operating system on every LG Smart TV shipped since 2014. The current line is webOS 25, which was scheduled for gradual rollout between Q4 2025 and Q1 2026 across both new TV models and a long list of older models going back to the 2022 lineup (Tom's Guide, Millions of LG TVs are getting a free upgrade to webOS 25, 2025; FlatpanelsHD, webOS 25 rolling out to older LG Smart TVs, October 2025).

The programming model is HTML5 web apps packaged as .ipk files, similar in spirit to Tizen but with one important difference: the underlying browser engine on webOS 6 and later is a fork of Chromium, not WebKit. That single change brought webOS in line with the modern web in a way Tizen has not matched. Standards-track APIs that Chromium ships — Promise.allSettled, modern async/await in V8's recent baseline, the modern IntersectionObserver, Web Workers with the modern semantics, the post-2020 ECMAScript additions — work on webOS the way they work on a desktop Chrome. The same APIs on Tizen are limited by whichever WebKit fork Samsung shipped in that model year.

For video playback, webOS gives you two paths. The first path is the standard HTML5 element fed with an HLS manifest URL; webOS plays HLS natively (Dolby OptiView, How to Build a webOS TV Streaming App, 2024). The second path, which production teams use, is the Media Source Extensions (MSE) and Encrypted Media Extensions (EME) APIs that webOS exposes through its Chromium engine. MSE lets a JavaScript player such as hls.js, Shaka Player, or dash.js feed segment bytes into the video element. EME lets the same player negotiate keys with a Widevine or PlayReady license server through the Content Decryption Module — the CDM — that webOS ships in firmware. PlayReady and Widevine Modular both work on webOS 3.0 and later, with Widevine Classic deprecated since webOS 236 (Dolby OptiView, A Complete List of Limitations for Native WebOS Media Player, 2024).

The catch on webOS is the same shape as the catch on Tizen, in a different place. webOS natively supports HLS, but most webOS 5 TVs implement HLS version 7, which corresponds to Pantos draft 14 from 2014 — eight years older than the current HLS feature set. The list of unsupported HLS tags on those TVs is longer than the list of supported ones. EXT-X-DISCONTINUITY support, crucial for server-side ad insertion, is patchy. EXT-X-PROGRAM-DATE-TIME and EXT-X-PART for Low-Latency HLS are absent on the older devices. The 2026 production guidance is: ship a JavaScript player on the MSE / EME path (Shaka Player and hls.js both work well on webOS Chromium) rather than relying on native HLS, because the JavaScript player is the only path that gives you the modern feature set on older webOS firmware.

AV1 is supported only on 8K models with an 8K upgrader attached as of mid-2025 (LG USA Support, LG TV — Supported Video Codecs, 2025). For mainstream 4K LG TVs, H.264 and H.265 are the codecs to ship. DASH is officially unsupported by the native player but, in practice, has limited compatibility for VOD streams through the MSE path.

The remote-control model on webOS is closer to the desktop web than Tizen is. The Magic Remote on LG TVs supports the standard keyboard events JavaScript apps already handle, plus webOS-specific events for the OK button, the back button, the magnifying-glass cursor, and the colour buttons. The platform-specific shim is smaller on webOS than on Tizen, which is one reason teams who ship to both find webOS the easier port.

Roku BrightScript: The Proprietary Stack That Owns US Living Rooms

Roku is the unusual one in the lineup, and the unusual one is also the leader in the US market. A Roku app — Roku calls them channels — is written in BrightScript, a Roku-only scripting language that combines a syntax inspired by BASIC with object-oriented additions and a runtime that lives inside Roku OS. The UI framework is called SceneGraph, a declarative XML-and-BrightScript pair where layouts and components are described in XML files and behaviours in BrightScript files. SceneGraph is the only modern way to build a Roku app — the older imperative "screen-and-scene" framework from the early Roku days is deprecated.

The video player on Roku is one specific SceneGraph node called the Video node. You create a Video node, hand it a content object that contains the manifest URL and stream-format declaration, and call .control = "play". That is the canonical pattern in every Roku channel (Roku Developer, Video, 2026; Roku Developer, Playing Videos, 2026).

sub initPlayer()
    m.video = m.top.findNode("videoPlayer")
    contentNode = createObject("roSGNode", "ContentNode")
    contentNode.url = "https://example.com/manifest.m3u8"
    contentNode.streamFormat = "hls"
    m.video.content = contentNode
    m.video.control = "play"
end sub

The streaming-format support on the Roku Video node covers HLS and MPEG-DASH. You declare which one you are feeding by setting streamFormat = "hls" or streamFormat = "dash" on the content node. The Video node parses the manifest, fetches segments, runs Roku's own adaptive-bitrate logic, and plays. The fetch behaviour is configurable — you can override HTTP headers per request, pass a Bearer token for signed-URL authentication, and intercept the manifest before playback starts to rewrite it if you need to.

The DRM support on Roku covers PlayReady and Widevine. You attach the DRM parameters to the same content node through a drmParams block that includes the licence-server URL, the licence-server headers (for Bearer tokens), and (for Widevine) the service-certificate bytes as a base64 string (Roku Developer, Content metadata, 2026). Persistent licences for offline playback are supported on PlayReady on the modern Roku models, with a few caveats around licence renewal that teams have to test against the specific model lineup they are certifying.

Three pieces of Roku-specific knowledge are essential before you ship.

First, the Roku certification process is mandatory and slow. A new channel goes through a multi-week review by Roku's Channel Manager team before it appears in the Roku Channel Store. The reviewers test the channel on a representative spread of Roku models (the Roku Express line at the bottom, the Roku Ultra at the top, the Roku TV models in the middle) and they will reject the channel for performance issues, UI-language issues, and certification-test failures that have to be fixed and re-submitted. Plan a 4–8-week window between code-complete and store availability.

Second, the performance ceiling on the entry-level Roku Express is lower than every other TV platform. The cheapest Roku models run on extremely modest hardware — a single-core ARM CPU at a clock speed below 1 GHz, 256 MB of RAM, no GPU — and the app has to render its UI inside that envelope. Roku's certification process tests against those low-end devices, and a UI that runs smoothly on a Roku Ultra but drops frames on a Roku Express will be rejected. The discipline this imposes on a Roku app is real: spritesheet-based UI, careful memory budgeting in BrightScript, no large data structures held in memory beyond what the current screen requires.

Third, BrightScript is the only language Roku supports. There is no Kotlin path, no JavaScript path with a real player API, no React Native path. The investment in BrightScript talent is real, the community is small (relative to web or Android), and the developer pool charges accordingly. The flip side is that the Roku platform is the most consistent of the six — a BrightScript channel that runs on a 2024 Roku TV runs on a 2018 Roku TV with very few changes, because the SceneGraph framework has been the same for nearly a decade.

Android TV and Google TV: ExoPlayer, Media3, and the Strongest Native Stack

Google's TV platform has two names that engineers should understand are essentially the same platform underneath. Android TV is the Google-branded version that ships on operator-supplied set-top boxes and some TV-vendor lineups. Google TV is the user-facing brand that ships on newer TVs (the Sony Bravia line since 2021, the TCL line on most models, the Hisense Google-branded models, every Chromecast with Google TV device) and that adds Google's content-discovery layer on top. From an app developer's perspective they are the same platform — the same APIs, the same Play Store, the same Media3 / ExoPlayer media stack underneath.

The app is a standard Android application in Kotlin or Java, packaged as an .apk file (or, increasingly, an Android App Bundle), distributed through the Google Play Store. The video player is Media3 / ExoPlayer, the open-source media library Google maintains as the standard Android media stack. Media3 1.10 was the stable version as of March 2026 (Android Developers, Media3, 2026). ExoPlayer covers HLS, MPEG-DASH, SmoothStreaming, and progressive playback with one library, with adaptive bitrate built in, with subtitle and audio-track switching exposed as standard APIs, and with Widevine DRM integrated through the Android MediaDRM framework (Android Developers, HLS, 2026; Android Developers, DASH, 2026).

The DRM picture on Android TV is the cleanest of the six platforms. Widevine L1 — the hardware-backed security level that premium catalogues require for 1080p and 4K playback — is available on every modern Android TV device. PlayReady is generally not deployed on Android TV (it is the Microsoft DRM, and Google's platform has no reason to ship it); FairPlay is Apple-only and absent. If your DRM strategy is Widevine for everything non-Apple and FairPlay for Apple, Android TV slots into the Widevine half without friction.

A minimum-viable ExoPlayer setup on Android TV is a small amount of Kotlin:

val player = ExoPlayer.Builder(context).build()
val mediaItem = MediaItem.Builder()
    .setUri("https://example.com/manifest.mpd")
    .setDrmConfiguration(
        MediaItem.DrmConfiguration.Builder(C.WIDEVINE_UUID)
            .setLicenseUri("https://drm.example.com/widevine")
            .build()
    )
    .build()
player.setMediaItem(mediaItem)
player.prepare()
player.play()

That snippet plays a Widevine-protected MPEG-DASH stream on any modern Android TV. The rest — adaptive-bitrate logic, subtitle rendering, audio-track switching, captions formatting per CEA-608 / 708 or WebVTT, fast-channel-change behaviour for live, DVR scrubbing — is built into ExoPlayer with sensible defaults you override only when you have a specific production requirement.

The Android TV remote-control model is the standard Android KeyEvent path that every Android developer already knows. The TV-specific keys (KEYCODE_DPAD_UP, KEYCODE_DPAD_DOWN, KEYCODE_DPAD_CENTER, KEYCODE_BACK, KEYCODE_MEDIA_PLAY_PAUSE, the four colour-button equivalents) come through the same onKeyDown callback as on a phone. The TV-specific UI framework is Leanback — a set of Jetpack libraries that gives you the canonical "Browse-Rows-Of-Cards" UI that Android TV apps adopt — but you are not required to use it, and increasingly modern Android TV apps use Jetpack Compose for TV instead.

The single biggest reason Android TV / Google TV gives you the strongest media stack of the six is that the platform inherits the entirety of Android's media subsystem. Hardware codec acceleration with MediaCodec. The full FFmpeg-compatible extractor / muxer toolkit through MediaExtractor and MediaMuxer. Background audio sessions with MediaSession. Picture-in-picture on the TVs that support it. AV1 decoding on every modern Android TV chipset. The Android TV experience is as good as the underlying chipset, and most modern Android TVs ship strong chipsets.

Amazon Fire TV: The Vega Migration Is the 2026 Story

Amazon's Fire TV used to be straightforward: it was a fork of Android. A Fire TV app was an Android app, distributed through the Amazon Appstore instead of Google Play, with a handful of Amazon-specific entitlements layered on top. The same Kotlin / Java codebase that targeted Android TV could ship to Fire TV with modest changes — different store, different ads SDK, same ExoPlayer underneath.

That story ended in October 2025. The Fire TV Stick 4K Select, launched in October 2025, was the first streaming device to ship with Vega OS — Amazon's brand-new, Linux-based operating system built from the ground up with React Native and standard web technologies on top, with no Android Open Source Project lineage anywhere in the stack (Dolby OptiView, Amazon Launches Vega OS for Fire TV, 2025). The Fire TV Stick HD followed in early 2026. And in January 2026 Amazon updated its developer documentation to state that all future Fire TV Sticks will run Vega OS (AFTVnews, Amazon confirms all future Fire TV Sticks will run Vega OS, April 2026; 9to5Google, Amazon will ditch Android on 'all' future Fire TV Sticks, April 2026).

The implication for an app team is not subtle. An Android .apk does not run on Vega OS. Amazon's Android-app compatibility layer does not exist; the new platform is genuinely a different operating system with a different application model. Every streaming service that wants a presence on the new Fire TV Stick lineup — and over time, every Fire TV device, because the Vega rollout will keep displacing Android-based Fire OS — has to ship a new app written with React Native plus web technologies through the Vega developer toolchain (Amazon Developer, Run your app on Vega Virtual Device or Fire TV Stick, 2026). Amazon is publishing migration guides and a Vega Virtual Device emulator to help teams move, but the migration is not "press a button"; it is rewriting your TV app's UI layer in React Native and your media-playback layer against Vega's player API.

There is a transitional reality that softens the urgency a little. Vega OS is on new devices only. The existing installed base of Fire TV devices — every Fire TV Stick 4K, Fire TV Cube, Fire TV Omni, Fire TV Edition smart TV, and every other Amazon-branded TV device shipped before October 2025 — continues to run Fire OS, the Android-based system. Those devices will keep running your existing Android-based Fire TV app for the foreseeable future. Amazon has not announced an end-of-life date for Fire OS on the installed base. The migration question is therefore about new viewers — every new Fire TV Stick a viewer buys from late 2025 onwards is a Vega device, and a viewer who does not see your app in the Vega Appstore is a viewer your competitor wins.

The build-order recommendation for a team that already has a Fire OS app and wants to be deliberate about the migration is:

  1. Keep the Fire OS app shipping to the installed base. Bug fixes only; no new investment.
  2. Start a Vega OS app in parallel using Amazon's React Native + web toolchain. This is a new project; staff it as one. Plan for a 3–6-month build from scratch for a basic app with login, browse, playback, and basic telemetry; longer if your app has complex features such as live, downloads, or premium-content gating.
  3. Ship the Vega app into the Vega Appstore as soon as it passes Amazon's certification process.
  4. Decide on a sunset date for the Fire OS app based on the actual usage telemetry you see from the installed base in 2027 and 2028. Do not pre-commit to a date Amazon has not set.

The deeper picture is that Vega OS represents Amazon trying to break out of the Android dependency that gave Google a quiet veto over Fire TV's roadmap for a decade. From an app developer's point of view it is a forced rewrite. From an industry point of view it is the most disruptive smart-TV platform event since Apple shipped tvOS in 2015.

A timeline diagram showing Fire OS Android-based status from 2014 to 2025 on the top track and Vega OS Linux-based React Native status from 2025 to 2027 on the bottom track, with the October 2025 Fire TV Stick 4K Select launch as the transition point, the January 2026 Amazon developer-docs confirmation as a second milestone, and a soft sunset window for the installed base of Fire OS devices marked from 2027 onwards Figure 2. The Fire TV platform timeline. The October 2025 Fire TV Stick 4K Select was the first Vega OS device, the January 2026 Amazon Developer documentation update confirmed that all future Fire TV Sticks would run Vega, and the existing Android-based Fire OS installed base continues to be supported until Amazon publishes an end-of-life date.

Vidaa: The Hisense HTML5 Platform You Should Not Ignore

The smallest of the six platforms by global share is also the fastest-growing budget-TV operating system on the market. Vidaa OS is Hisense's Linux-based smart-TV operating system, shipped on most modern Hisense televisions and on the Toshiba TVs that Hisense manufactures under licence in markets such as Europe, India, and parts of South America. The active installed base is in the high tens of millions of TVs as of 2026 and grows with every Hisense unit sold (Vidaa, VIDAA OS, 2026).

The programming model is HTML5 web apps, similar in shape to Tizen and webOS. A Vidaa app is a packaged HTML page that runs inside Vidaa's HTML5 web engine — a Linux-based browser stack that is custom to Vidaa rather than a fork of WebKit or Chromium. The web engine exposes platform device APIs in the manner of Tizen's Web APIs: a media player plugin module that supports HTTP, HLS, MPEG-DASH, and Microsoft Smooth Streaming, a DRM manager for the licence-acquisition flow, a streaming manager for the playback session, and a remote-control input API that maps the keys on the Vidaa-spec remote (VIDAA, WebApp Development Technical Guide, 2025).

The DRM support on Vidaa is structured around PlayReady and Widevine for premium content and a Vidaa-specific DRM for partner-distributed content. The codec ladder covers H.264 (AVC) and H.265 (HEVC) on every modern model, with HEVC widely deployed because Hisense's chipset partner has shipped HEVC decoders in TV silicon for years. AV1 support is shipping on Hisense's higher-end 2024 and 2025 model lines but is not assumed in production code.

The reason a team should not skip Vidaa is partner economics. Vidaa-on-Toshiba in the European market and Vidaa-on-Hisense in the global value segment are the platforms that show up in households that did not buy a Samsung or LG TV. Those households exist in large numbers in markets where TV pricing matters, and a streaming service that targets those markets without a Vidaa app gives up the entire budget-TV audience. The codebase reuse from a Tizen or webOS HTML5 app to a Vidaa app is high (the same element, the same MSE / EME pattern, the same JavaScript player such as Shaka or hls.js, with a Vidaa-specific shim for the device APIs), which means the marginal cost of adding Vidaa as a fourth HTML5 target after Tizen and webOS is small.

The Format and DRM Matrix Across All Six Platforms

The matrix below is the single most useful artefact in this article. If you encode and package your catalogue once, what do all six TV platforms accept? The answer is a CMAF-packaged H.264 or H.265 source, encrypted with .cbcs Common Encryption, served to three different DRM systems through three different licence-server flows.

PlatformProgramming modelHLSMPEG-DASHWidevinePlayReadyFairPlayHEVCAV1
Samsung TizenHTML5 + AVPlayyesyesyes (secondary)yes (primary)noyespartial (browser-path AV1+DASH defect)
LG webOSHTML5 + MSE/EMEyes (HLS v7 limited)partial (MSE)yesyesnoyes8K models only
Roku OSBrightScript + SceneGraphyesyesyesyesnoyesnewer models
Android TV / Google TVKotlin/Java + Media3 ExoPlayeryesyesyes (L1)no (not deployed)noyesyes (modern chipsets)
Fire TV (Fire OS)Kotlin/Java + Media3 ExoPlayeryesyesyes (L1)nonoyesyes (modern models)
Fire TV (Vega OS)React Native + webyesyesyesyesnoyesyes
Vidaa OSHTML5 + plugin playeryesyesyesyesnoyesnewer models
A matrix diagram showing the format, codec and DRM support across the six smart TV platforms in 2026, with rows for Samsung Tizen using AVPlay, LG webOS using HTML5 MSE EME, Roku OS using BrightScript SceneGraph, Android TV and Google TV using Media3 ExoPlayer, Amazon Fire TV split into Fire OS Android and Vega OS React Native, and Hisense Vidaa OS using HTML5 plugin player, and columns for HLS, MPEG-DASH, Widevine, PlayReady, FairPlay, HEVC, and AV1, with green ticks for supported combinations and orange dashes for unsupported or limited ones Figure 3. The format, codec, and DRM matrix across the six smart-TV platforms in 2026. Widevine is the only DRM supported on every platform; PlayReady is supported everywhere except Android TV / Google TV (Google's first-party platform does not deploy it). HLS is supported everywhere. AV1 is shipping but uneven.

Three implications fall out of the matrix.

First, your encoding pipeline can be single-source. If you package every title once as a CMAF source — H.264 plus H.265 ladders, fragmented MP4 segments, encrypted with .cbcs Common Encryption per ISO/IEC 23001-7 — the same bytes serve every platform in the matrix. The differences sit in the manifest layer (HLS playlists for native iOS / tvOS Safari and AirPlay-style native playback; DASH manifests for everywhere else) and in the licence layer (Widevine for Android TV and most non-Apple devices; PlayReady for Tizen and a sizeable share of webOS, Roku, Vega, and Vidaa; FairPlay for Apple). The CMAF article in this series — CMAF: the packaging format that unified HLS and DASH — is the reference for how that packaging looks in production.

Second, your licence-server strategy is multi-DRM by default. No single DRM covers every platform. Widevine covers Android, ChromeOS, Chromium-on-webOS, Roku, Vidaa, Vega, and Tizen-as-secondary. PlayReady covers Tizen-as-primary, webOS, Roku, Vidaa, Vega, and Windows / Xbox. FairPlay covers Apple iOS / iPadOS / tvOS / macOS. Every premium-catalogue product ships all three through the same licence-server vendor (PallyCon, EZDRM, Axinom, BuyDRM, AWS, or in-house) and configures the player on each platform to fetch from the licence endpoint that matches the DRM the platform exposes. The Common Encryption deep dive covers the cross-DRM mechanics in detail.

Third, HEVC is the safe top-tier codec, not AV1. Every TV platform in the matrix ships hardware HEVC decoders. AV1 is shipping unevenly — strong on Android TV's modern chipsets, present on Roku's newer models, restricted to 8K-upgraded panels on webOS, broken in the browser-on-DASH path on Samsung TVs from 2021 through at least mid-2025. A team that ships HEVC as their top rung and AV1 as an opt-in next-rung-up has the safe bet for 2026. A team that ships AV1-only has shipped a product that does not play on a meaningful share of the installed base.

The Telemetry and QoE Story on TV

What every production player on every TV platform should emit looks the same across the six: startup time (the milliseconds from play() until the first frame is visible), rebuffer events with the cause (network, decoder stall, ABR switch wait), ABR switches with the reason, error codes with context, the CDN host that served each segment, a rolling throughput average, and a rolling buffer-level average. The schema is the same as for the web players covered in Player observability and the metrics that ship in production. The vendors are the same: Mux Data, Conviva, Bitmovin Analytics, Datazoom, NPAW. The differences sit in the integration shape.

On Tizen, the AVPlay API surfaces media events through JavaScript callbacks (onstreamcompleted, onbufferingstart, onbufferingcomplete, onerror) that you wire into your analytics SDK exactly the way you would wire the HTML5 video element on the web. On webOS, the standard HTML5 media events plus MSE buffer events do the same job. On Roku, the Video node exposes observer fields (state, position, bufferingStatus, errorCode) that BrightScript observers watch and report. On Android TV and Fire OS, ExoPlayer's AnalyticsListener interface gives you every event Mux Data and Conviva need with zero glue code (their SDKs include an Android TV integration that listens to AnalyticsListener directly). On Vidaa, the HTML5 media events plus the Vidaa-specific player-state callbacks expose the same surface. On Vega OS, the React Native player API exposes media events through React's component lifecycle; Amazon's analytics integration is documented in the Vega developer guide.

The non-obvious thing about TV telemetry is that the events look almost identical to web video telemetry, but the device-state context differs in important ways. A TV has standby-mode events the web does not have. A TV has HDMI-input-switch events the web does not have. A TV often has memory pressure that triggers garbage collection at moments your timeline does not predict, which shows up as rebuffer events your QoE dashboard initially misattributes to the network. Telemetry that includes device model and firmware version on every event lets the analytics layer separate "your app has a bug" from "this firmware revision has a bug" — both are common on TV.

Where Fora Soft Fits In

Fora Soft has been shipping video products since 2005, and television was on the surface list from the start. Our work spans video streaming and OTT platforms with Tizen, webOS, Android TV, and Roku apps in production for clients in e-learning, live shopping, telemedicine education, and surveillance verticals; WebRTC products that bridge to TV through HLS / DASH egress (where the WebRTC-to-HLS bridge covers the architecture); and AR / VR products whose companion TV apps share a single CMAF source with the headset. The TV layer is rarely the first surface a product team thinks about, and it is almost always one of the highest-revenue surfaces by viewer-hour once it ships. We build TV apps as part of broader streaming engagements and we maintain them on the long-tail firmware revisions the engineering organisation never wants to think about again.

A Common Mistake Worth Naming

The single most common smart-TV pitfall a team ships in their first year is to test only on a Samsung Tizen TV manufactured in the last 12 months and assume the rest of the TV market behaves the same way. The Tizen 2025 model lineup runs Tizen 9.0 with the redesigned settings menu, AVPlay with the latest features, AV1 decoding on the higher-end models, and a Web Engine that handles modern JavaScript well. None of those characteristics generalise. The Tizen 2022 lineup runs an older Tizen with an older Web Engine. The webOS 2022 lineup runs HLS version 7 with the long unsupported-tag list. The Roku Express that a viewer bought in 2022 has 256 MB of RAM and a single-core sub-1-GHz CPU. The 2024 Hisense Vidaa runs a custom browser that does not implement every Chromium API. A QA matrix that tests against the current year's top-end Samsung is not testing the smart-TV market; it is testing one small corner of it. The correct test matrix covers at least one device from each of the last four model years on each platform you target, with the cheapest device on Roku, the cheapest Hisense Vidaa, and the median webOS firmware as the three hardest tests.

A Note on tvOS and Vizio SmartCast

Two TV platforms we have deliberately not covered in depth are worth a sentence each. Apple tvOS is the operating system on the Apple TV box and the only platform in the TV market that runs a real native app written in Swift on top of AVFoundation and AVPlayer; we cover it in detail in the iOS and Safari native player article, because the same Apple media stack covers both. Vizio SmartCast is the operating system on Vizio's smart TVs (Vizio is a US-only brand that Walmart acquired in 2024), and its app model is a managed-store partner-only model — a streaming service does not ship a Vizio app the way it ships a Tizen app; Vizio approves a small number of partner apps directly. A US-focused streaming service should investigate the Vizio partner programme separately; the engineering shape is closer to a server-side integration than to a TV app build.

What to Read Next

CTA

  • Talk to a streaming engineer — scope your TV app roadmap with someone who has shipped to all six platforms.
  • See our case studies — TV apps for e-learning, live shopping, and OTT.
  • Download the Smart TV cheat sheet — one page of every codec, DRM, format, and engine version that matters in 2026. Download the Smart TV cheat sheet (PDF)

References

  1. Apple Inc., HTTP Live Streaming (HLS) Authoring Specification for Apple Devices, revision 2025-09, https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices. Tier 1, official Apple specification. Cited for the LL-HLS receiver model that tvOS native AVPlayer implements; used as the canonical Apple Authoring Specification reference for the cross-platform comparison.
  2. IETF, RFC 8216, HTTP Live Streaming, R. Pantos and W. May, August 2017, https://www.rfc-editor.org/rfc/rfc8216.html. Tier 1, official IETF RFC. Cited for the base HLS protocol that every TV platform's HLS support implements, including the EXT-X-DISCONTINUITY and EXT-X-PROGRAM-DATE-TIME tags whose absence on older webOS firmware is called out in the article. The article also notes that several webOS 5-era TVs implement Pantos draft 14 (2014), which preceded RFC 8216's normative text.
  3. ISO/IEC, ISO/IEC 23001-7:2023 Common encryption in ISO base media file format files, https://www.iso.org/standard/84637.html. Tier 1, official ISO/IEC standard. Cited for the .cenc and .cbcs encryption modes used across multi-DRM CMAF deployments. Spec text is paywalled; we cite the catalogue page's normative summary.
  4. ISO/IEC, ISO/IEC 23000-19 CMAF (Common Media Application Format). Tier 1, official ISO/IEC standard. Cited for the CMAF packaging format that the matrix's "single source, multi-platform" recommendation depends on.
  5. W3C, Encrypted Media Extensions Recommendation, 2017-09-18, https://www.w3.org/TR/encrypted-media/. Tier 1, W3C Recommendation. Cited for the EME mechanism that webOS Chromium and Vidaa's HTML5 engine expose for Widevine and PlayReady licence acquisition.
  6. W3C, Media Source Extensions Recommendation, 2016-11-17, https://www.w3.org/TR/media-source/. Tier 1, W3C Recommendation. Cited for the MSE mechanism that webOS, Tizen (via AVPlay's MSE bridge on newer Tizen), and Vidaa expose for JavaScript players to feed segment bytes into the element.
  7. Samsung Developer Documentation, AVPlay API, accessed 2026-05-25, https://developer.samsung.com/smarttv/develop/api-references/samsung-product-api-references/avplay-api.html. Tier 3, first-party platform documentation. Cited for AVPlay's HLS, DASH, Smooth Streaming, and progressive playback coverage, PlayReady and Widevine DRM support, and the setDrm() and ondrmevent() callback mechanics.
  8. Samsung Developer Documentation, Playback Using AVPlay, accessed 2026-05-25, https://developer.samsung.com/smarttv/develop/guides/multimedia/media-playback/using-avplay.html. Tier 3, first-party platform documentation. Cited for the DASH audio-track switching support added in Tizen 5.0 and the manifest-language handling.
  9. Samsung Community, Tizen browser AV1 codec problem with DASH, mid-2025 thread, https://eu.community.samsung.com/t5/tv/tizen-browser-av1-codec-problem-with-dash/td-p/13658559. Tier 4, vendor-hosted community report. Cited for the persistent AV1-over-DASH browser-path defect on Samsung TVs from 2021 onwards. We override the unqualified "Samsung supports AV1" claims of marketing copy with this specific deployment-blocking defect.
  10. LG webOS TV Developer Documentation, Audio and Video Format on webOS TV 24, accessed 2026-05-25, https://webostv.developer.lge.com/develop/specifications/video-audio-240. Tier 3, first-party platform documentation. Cited for the supported codec and container matrix on webOS 24 and 25.
  11. Dolby OptiView (THEO Technologies), Going Big Screen: A Complete List of Limitations for Native WebOS Media Player, 2024, https://optiview.dolby.com/resources/blog/playback/limitations-to-bringing-media-to-lgs-webos/. Tier 4, vendor blog from a production player vendor. Cited for the HLS version 7 / Pantos draft 14 limitation on most webOS 5 TVs and the long list of unsupported HLS tags; useful as a production deployment summary that complements the LG developer docs.
  12. Tom's Guide, Samsung is giving these older TVs a big Tizen OS upgrade — see if yours is on the list, 2026, https://www.tomsguide.com/tvs/samsung-is-giving-these-older-tvs-a-big-tizen-os-upgrade-see-if-yours-is-on-the-list. Tier 6, technology-press orientation source. Cited for the Tizen 9.0 rollout schedule across the 2023, 2024, and 2025 Samsung TV lineups.
  13. Tom's Guide, Millions of LG TVs are getting a free upgrade to webOS 25 — here's when yours is coming, 2025, https://www.tomsguide.com/tvs/millions-of-lg-tvs-are-getting-a-free-upgrade-to-webos-25-heres-when-yours-is-coming. Tier 6, technology-press orientation source. Cited for the webOS 25 upgrade window (Q4 2025 to Q1 2026) and the backwards-compatible upgrade list.
  14. FlatpanelsHD, webOS 25 rolling out to older LG Smart TVs, October 2025, https://www.flatpanelshd.com/news.php?subaction=showfull&id=1759390277. Tier 6, industry-press source. Cross-cited with Tom's Guide for the webOS 25 rollout schedule.
  15. Roku Developer Documentation, Video (SceneGraph node), accessed 2026-05-25, https://developer.roku.com/docs/references/scenegraph/media-playback-nodes/video.md. Tier 3, first-party platform documentation. Cited for the SceneGraph Video node API, the streamFormat = "hls" | "dash" field, and the content-node-based playback model.
  16. Roku Developer Documentation, Content metadata, accessed 2026-05-25, https://developer.roku.com/docs/developer-program/getting-started/architecture/content-metadata.md. Tier 3, first-party platform documentation. Cited for the drmParams block on the content node and the PlayReady and Widevine licence-server configuration fields.
  17. Roku Developer Documentation, Playing Videos, accessed 2026-05-25, https://developer.roku.com/dev/docs/playing-videos. Tier 3, first-party platform documentation. Cited for the canonical m.video.control = "play" playback pattern and the BrightScript SceneGraph initialisation flow.
  18. Android Developers Documentation, Media3, accessed 2026-05-25, https://developer.android.com/jetpack/androidx/releases/media3. Tier 3, first-party platform documentation. Cited for the Media3 1.10 stable release status as of March 2026.
  19. Android Developers Documentation, HLS (ExoPlayer), accessed 2026-05-25, https://developer.android.com/media/media3/exoplayer/hls. Tier 3, first-party platform documentation. Cited for ExoPlayer's HLS feature coverage on Android TV and Fire OS.
  20. Android Developers Documentation, DASH (ExoPlayer), accessed 2026-05-25, https://developer.android.com/media/media3/exoplayer/dash. Tier 3, first-party platform documentation. Cited for ExoPlayer's MPEG-DASH feature coverage including the multi-container MPD support that the Widevine-on-DASH snippet in the article uses.
  21. Amazon Developer Documentation, Run your app on Vega Virtual Device or Fire TV Stick, version 0.22, accessed 2026-05-25, https://developer.amazon.com/docs/vega/0.22/run-apps.html. Tier 3, first-party platform documentation. Cited for the Vega OS application toolchain and the React Native plus web-technologies application model.
  22. Dolby OptiView (THEO Technologies), Amazon Launches Vega OS for Fire TV, October 2025, https://optiview.dolby.com/resources/blog/playback/amazon-launches-vega-os-for-fire-tv/. Tier 4, vendor blog from a production player vendor. Cited for the Vega OS launch announcement and the Linux-based, React Native plus web architecture.
  23. AFTVnews, Amazon confirms all future Fire TV Sticks will run Vega OS — No more Android or sideloading on new models, April 2026, https://www.aftvnews.com/amazon-confirms-all-future-fire-tv-sticks-will-run-vega-os-no-more-android-or-sideloading-on-new-models/. Tier 4, dedicated industry-press source. Cited for the January 2026 Amazon developer-docs update confirming the all-future-sticks Vega commitment.
  24. 9to5Google, Amazon will ditch Android on 'all' future Fire TV Sticks as latest model runs Vega OS, April 2026, https://9to5google.com/2026/04/17/amazon-fire-tv-android-vega-switch/. Tier 6, industry-press source. Cross-cited with AFTVnews for the all-future-sticks Vega commitment.
  25. VIDAA, VIDAA OS overview, accessed 2026-05-25, https://www.vidaa.com/vidaa-os/. Tier 3, first-party platform documentation. Cited for the Linux-based Vidaa OS architecture and the global Hisense / Toshiba deployment.
  26. VIDAA, WebApp Development Technical Guide for VIDAA, 2025, https://www.scribd.com/document/825727528/WebApp-Development-Guide-for-VIDAA. Tier 3, first-party platform documentation (hosted third-party). Cited for the Vidaa media player plugin module's HLS, DASH, and Smooth Streaming support and the DRM manager / streaming manager architecture.
  27. electroIQ, Smart TV Statistics By Market Size, Region, Key Players, Operating System (2025), https://electroiq.com/stats/smart-tv-statistics/. Tier 6, market-research summary source. Cited for the global smart-TV OS market share splits (Android TV at 35–40 percent, Tizen at 19–23 percent, webOS at 12–25 percent, Roku at 10–11 percent, Fire TV at 8 percent, residual Vidaa) and the global smart-TV-household figure of 1.1 billion by 2026.
  28. Parks Associates (as reported by Apple World Today), Roku OS (28%) and Samsung's Tizen OS (23%) account for the largest share of TV operating system usage in the US, April 2026, https://appleworld.today/2026/04/roku-os-28-and-samsungs-tizen-os-23-account-for-the-largest-share-of-tv-operating-system-usage-in-the-us/. Tier 5, analyst-report secondary source. Cited for the Q1 2026 US market share split (Roku at 28 percent, Tizen at 23 percent, Fire TV / webOS / Vizio SmartCast mid-tier).
  29. Parks Associates, Roku (28%) and Samsung (23%) dominate connected TV platforms, controlling access to streaming audiences in the US market, 2026, https://www.parksassociates.com/blogs/pr-video-services-ott-pay-tv/roku-and-samsung-dominate-connected-tv-platforms. Tier 5, analyst-report primary source (direct from Parks). Cross-cited with the Apple World Today summary for the Q1 2026 US market share.