Why this matters
If you are planning an OTT platform, the client matrix is where your budget quietly doubles. Founders model the cost of "the app" and discover, after launch, that a smart-TV build is a different project from the iOS build, that Roku uses a programming language found almost nowhere else, and that every platform has its own certification queue. This article is for the media founder, product manager, or first-time streaming CTO who has to decide which screens to support, in what order, and what team it takes to keep them all working. It is the anchor of the client-applications block: the per-platform deep dives that follow (web playback, iOS and Android, smart TV, Roku) all hang off the map drawn here.
The one idea: every screen is a separate app
Start with the misconception that wrecks first OTT budgets. Teams picture one app that "runs everywhere," the way a website does. Streaming does not work that way. The living room alone is a collection of incompatible computers wearing the same shape.
A television running Samsung's Tizen operating system, the software that powers the TV, cannot run the app you wrote for an LG TV running webOS. Neither can run your Roku app, because Roku uses its own programming language. Your iPhone app will not install on an Android phone. So a service that wants to be on "all the screens" is committing to a portfolio of apps — typically six to ten distinct builds — that share a back end but almost nothing on the front end.
Think of it like opening a restaurant chain in countries that each mandate a different kitchen layout, a different language on the menu, and a different health inspection. The food (your catalog and your back end) is the same everywhere. The building, the staff training, and the paperwork are different in every country. That is the OTT client matrix, and it is the single biggest reason streaming apps cost more than founders expect.
Figure 1. The OTT client matrix. Six surface families — web, iOS, Android, smart TV, streaming devices, and consoles — each a separate app with its own language, video player, and DRM system, all served by one shared back end.
The six surface families, in plain language
The matrix is large but it organizes cleanly into six families. Each family is a place your viewer might be, and each forces specific engineering on you.
The web browser. The most open surface and usually the cheapest to build. Your service runs as a web page that plays video using two browser standards: Media Source Extensions (MSE), which lets JavaScript feed video to the player piece by piece, and Encrypted Media Extensions (EME), which lets the browser talk to a DRM system. We cover the browser stack in web playback, and the underlying MSE/EME mechanism lives in our Video Streaming section.
Mobile: iOS and Android. Two phone-and-tablet platforms, two separate native apps. On Apple's iOS you build in Swift and play video with AVPlayer, Apple's built-in player; on Google's Android you build in Kotlin and play with ExoPlayer (now shipped as Media3), Google's built-in player. They also impose the app-store billing rules that shape your monetization.
Smart TVs. Televisions with the streaming software built in. The two largest are Samsung's Tizen and LG's webOS, both of which run apps written largely in web technology (HTML, CSS, JavaScript) but with platform-specific players and quirks. This family carries the heaviest fragmentation tax, covered in smart TV apps.
Streaming devices (the sticks and boxes). Plug-in devices that add streaming to any TV: Roku, Amazon Fire TV, Apple TV, and Google's Android TV / Google TV. Roku is its own world, built in a language called BrightScript with a UI framework called SceneGraph; Fire TV is Android underneath; Apple TV runs tvOS, close to iOS. See Roku development and Apple TV and Fire TV.
Game consoles. PlayStation and Xbox can run streaming apps, but they are a specialist, high-effort target with a small share of streaming time. Most services reach them late or never.
Cars, set-top boxes, and the long tail. Operator set-top boxes, automotive screens, and embedded devices exist, but for almost every new platform they are a phase-three concern, not a launch surface.
The three things that differ on every screen: language, player, DRM
Within each family, three technical facts change, and together they explain why each app is a separate project.
First, the programming language and UI framework. Web uses JavaScript. iOS uses Swift. Android and Fire TV use Kotlin/Java. Samsung Tizen and LG webOS use web technology with their own app models. Roku uses BrightScript — a language you will not use anywhere else in your stack. There is little code reuse across these without a deliberate cross-platform strategy, which we return to below.
Second, the video player. The player is the component that downloads the video, adapts the quality to the network (called adaptive bitrate, or ABR — explained in adaptive bitrate streaming), manages the buffer, and recovers from errors. Some platforms hand you a capable native player (AVPlayer on Apple, ExoPlayer/Media3 on Android); others need an open-source player such as Shaka Player or hls.js layered on top of the browser's MSE/EME. The deep mechanics live in video player engineering.
Third, the DRM system. DRM — the technology that stops premium content from being copied — is not one system but three, and which one you must use is decided by the device, not by you. Google's Widevine runs on Android, Chrome, Android TV, and Fire TV. Microsoft's PlayReady runs on Windows, Xbox, and most smart TVs (Tizen, webOS) and Roku. Apple's FairPlay runs on Safari, iOS, and tvOS. To cover every screen you need all three — which is exactly why multi-DRM exists. The good news, covered in that article, is that you encrypt your video once and issue licenses for all three; the bad news is your client apps must each integrate the DRM their platform demands.
Here is the matrix that every OTT architect ends up drawing. The "DRM" column is the coverage column: it shows, per surface, which content-protection system the device forces.
| Surface | Language / framework | Typical player | Required DRM | Relative build effort |
|---|---|---|---|---|
| Web browser | JavaScript (HTML/CSS) | Shaka Player, hls.js, dash.js | Widevine + PlayReady (FairPlay on Safari) | Low |
| iOS / iPadOS | Swift / SwiftUI | AVPlayer | FairPlay | Medium |
| Android phone/tablet | Kotlin / Java | ExoPlayer (Media3) | Widevine | Medium |
| Samsung smart TV | Web app (Tizen) | AVPlay / Shaka | PlayReady (Widevine) | High |
| LG smart TV | Web app (webOS) | native / Shaka | PlayReady (Widevine) | High |
| Roku | BrightScript / SceneGraph | Roku native player | PlayReady | High |
| Amazon Fire TV | Kotlin / Java (Android) | ExoPlayer (Media3) | Widevine | Medium |
| Apple TV (tvOS) | Swift / SwiftUI | AVPlayer | FairPlay | Medium |
| Android TV / Google TV | Kotlin / Java | ExoPlayer (Media3) | Widevine | Medium |
| Game consoles | platform SDKs | platform player | PlayReady (varies) | Very high |
Table 1. The OTT client matrix. Each surface forces a language, a player, and a DRM. No single codebase covers the column; the DRM split (Widevine / PlayReady / FairPlay) is decided by the device. Player and DRM details are vendor-current as of 2026 — re-verify per platform.
The point of the table is the same as the cost lesson: the columns do not collapse. There is no language, no player, and no DRM that covers every row. That is the irreducible complexity of the matrix.
Where the audience actually is: the reach side of the decision
Scalability-first means you choose surfaces by where the audience watches, then by what each costs. So start with reach. The numbers below are US 2026 figures; they vary by country, so re-baseline for your market.
The living room dominates. More than 90% of US households use a connected TV (a TV connected to the internet, whether smart TV or streaming device) at least monthly, and roughly 82% of US TV households own a smart TV (Hub Entertainment Research, 2025). Streaming is now about 44% of all TV viewing time, and around 70% of US adults reach for streaming first (Nielsen and industry data, 2025–2026). If your content is watched like television — long sessions, lean-back — the TV screen is not optional.
Within the living room, the platform market is concentrated. As of April 2026, Roku OS held about 28% and Samsung's Tizen about 23% of US connected-TV platform usage, with Amazon Fire TV, LG webOS, and Vizio SmartCast in the mid-tier and Apple tvOS, game consoles, and Android TV holding smaller shares (Parks Associates, Streaming Video Tracker, April 2026). Two platforms — Roku and Samsung — are roughly half the living-room audience between them. That concentration is a planning gift: covering Roku, Samsung, plus Fire TV and LG gets you most of the connected-TV reach in four builds.
Mobile and web remain essential for sign-up, discovery, and on-the-go viewing even when most watch-time happens on the TV. Phones are where people subscribe, search, and cast; the web is where they land from a marketing link and where you avoid the app-store billing cut. So the realistic launch set for a US consumer service is rarely "TV only" or "mobile only" — it is a small spanning set across both.
Figure 2. Reach versus effort. Each surface plotted by audience reach (vertical) against build-and-maintenance effort (horizontal). High-reach, lower-effort surfaces (web, iOS, Android) are the usual launch tier; high-reach, high-effort TV platforms (Roku, Samsung, Fire TV, LG) follow; consoles trail.
Figure 3. US connected-TV platform share, 2026. Roku (28%) and Samsung Tizen (23%) lead, with Fire TV, LG webOS, and Vizio in the mid-tier and tvOS, Android TV, and consoles smaller (Parks Associates, April 2026). Covering the top four captures most living-room reach.
The effort side: why TV platforms cost more
Reach tells you where to be; effort tells you what it costs to be there. Three forces make the TV surfaces more expensive than mobile or web.
Fragmentation within a platform. A "Samsung app" is not one target. Samsung ships new TV models every year on new toolchains, and old models linger in homes for a decade. As a concrete 2026 example, Samsung's 2026 TV models moved to a newer compiler toolchain (GCC 14.2.0, up from 9.2.0), so binaries built for older sets must be rebuilt and re-tested for the new generation (Samsung Developer documentation, 2026 — re-verify per model year). You are not maintaining one Samsung app; you are maintaining it across years of hardware.
Certification and store review. Every TV platform has a submission and certification queue — Roku, Samsung, LG, Amazon, Apple — and each has its own rules, test suites, and timelines. A bug fix that ships to the web in an hour can take days to clear TV certification. Multiply that by the number of platforms and certification becomes a standing tax on every release.
DRM and device quirks. The same encrypted stream can behave differently across Tizen versions because Widevine and PlayReady implementations differ by firmware (Bitmovin, DRM-on-Tizen analysis, 2025). The 2026 PlayReady-on-Samsung change is the canonical example of a dated, device-specific DRM migration you must track — we dedicate a whole article to it. Smart-TV QA is therefore a device-lab problem, not just a simulator problem: you need real hardware across model years.
Walk the cost arithmetic once, because it makes the trade-off concrete. Suppose one app surface costs, very roughly, 1 unit of effort to build and 0.3 units a year to maintain (certification, OS updates, device testing). A six-surface launch (web, iOS, Android, Roku, Samsung, Fire TV) is about 6 units to build and 6 × 0.3 = 1.8 units a year just to keep the lights on — before you add a single feature. Add LG, Apple TV, and Android TV and you are near 9 build units and 2.7 maintenance units a year. The maintenance line, not the build line, is what surprises teams: the matrix is a recurring cost, like CDN egress, not a one-time project. Model it in your OTT cost model from day one.
The strategy that tames the matrix: a shared player core
You cannot make the columns collapse, but you can stop rewriting the hard part on every platform. The single most important architectural decision in the client matrix is to build a shared player core — the logic that is identical everywhere — and keep only a thin, native shell per platform.
What belongs in the shared core: the ABR switching policy (which quality to pick), buffer management, the analytics beacons that feed your QoE dashboards, error-recovery rules, DRM license-request orchestration, and the API calls to your back end for catalog, entitlement, and recommendations. What stays native per platform: the actual video-decoding surface (AVPlayer, ExoPlayer, the Roku player), the on-screen UI, and the remote-control or touch input handling.
The pattern is "one brain, many bodies." Several commercial player SDKs (for example THEOplayer and Bitmovin) sell exactly this — one player core licensed across web, mobile, and smart TV — trading a licensing fee for far less per-platform code. The open-source route (Shaka Player on the web and TVs, plus the native players on mobile) costs no license but more integration engineering. Either way, the design goal is the same: write the streaming intelligence once.
This is also why the device matrix is not eleven equal projects. With a shared core, the marginal cost of an additional platform is mostly the UI shell and the platform's DRM and certification, not the streaming engine. The unified player strategy article walks the architecture in detail; the takeaway here is to decide core-vs-shell before you write the first app, because retrofitting it later means rewriting all of them.
Figure 4. One brain, many bodies. A shared player core (ABR, buffering, DRM orchestration, analytics) feeds thin native shells per platform, replacing eleven independent codebases and cutting the marginal cost of each new surface to its UI and DRM.
A common mistake: building for the demo, not the audience
The most frequent and most expensive sequencing error is shipping the surface that is easiest to demo — usually a slick mobile app — and treating the TV as a later phase, when the audience watches mostly on the TV. The result is a service that looks great in a pitch and underperforms in the living room, then needs an urgent, under-budgeted TV build to recover. The fix is to let reach lead: if your content is lean-back television, a Roku or Samsung app belongs in the launch set, not phase three.
A second common mistake is assuming "responsive web will cover TVs." TV browsers are limited, remote-control navigation is nothing like a mouse, and most TV platforms expect a native app you submit to their store. A web app is not a TV strategy. A third is forgetting offline: mobile viewers expect downloads, which carry their own offline-DRM rules and are easy to defer until a content owner makes them contractual.
A defensible launch order
Putting reach and effort together gives a sequence that fits most new consumer OTT services in 2026. Treat it as a default to adapt, not a law.
Launch tier, the spanning set: the web app (cheapest, no store cut, the marketing landing surface), iOS, and Android. These three establish sign-up, discovery, and on-the-go viewing at the lowest effort, and they share the most code through a cross-platform mobile approach plus a web build.
Living-room tier, by share: Roku and Samsung first (together about half the US connected-TV audience), then Amazon Fire TV (Android-based, so it reuses your Android work) and LG webOS. Apple TV (tvOS) reuses much of your iOS investment and slots in naturally if your audience skews Apple. Android TV / Google TV reuses Android.
Specialist tier, only if the data demands it: game consoles, operator set-top boxes, automotive. These are high-effort, low-share, and rarely justified at launch.
If your service is B2B, enterprise, or e-learning rather than mass-market entertainment, the order shifts toward web and mobile and may skip the living room entirely — which is exactly why the order follows your audience, not a template.
Where Fora Soft fits in
The client matrix is a scale-and-maintenance problem before it is a coding problem: the question is not "can we build a Roku app" but "can we keep ten apps behaving identically across years of devices without the maintenance line eating the roadmap." Fora Soft has built video streaming, OTT/Internet TV, e-learning, telemedicine, and video-conferencing apps since 2005 — 625+ projects for 400+ clients across 20+ years — across web, iOS, Android, smart TVs, and streaming devices, with shared player cores feeding native shells so a new platform costs its UI and DRM rather than a new streaming engine. We are vendor-neutral: we help you choose the launch surfaces by your audience and budget, and we size the device matrix for the concurrency and regions you actually serve, rather than selling a fixed stack.
What to read next
- Video player engineering: the core concepts
- Multi-DRM: one workflow, every device
- The player on every screen: a unified strategy
Call to action
- Talk to a streaming engineer — book a 30-minute scoping call to talk through your ott app development plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the OTT Device Coverage Planner — A spreadsheet that scores each OTT surface (web, iOS, Android, Roku, Samsung, LG, Fire TV, Apple TV, Android TV, consoles) by audience reach, build-and-maintenance effort, and required DRM, then ranks a recommended launch order for your….
References
- Parks Associates, "Roku (28%) and Samsung (23%) dominate connected TV platforms" (Streaming Video Tracker), April 22, 2026. US connected-TV platform usage share: Roku OS 28%, Samsung Tizen 23%, with Amazon Fire TV, LG webOS, and Vizio SmartCast mid-tier and Apple tvOS, consoles, and Android TV smaller. Tier 5 (analyst). https://www.parksassociates.com/blogs/pr-video-services-ott-pay-tv/roku-and-samsung-dominate-connected-tv-platforms — accessed 2026-06-17. Refresh at publish.
- W3C, Media Source Extensions (MSE) and Encrypted Media Extensions (EME) Recommendations. MSE lets JavaScript feed media to the player; EME lets the browser interface with a DRM system (Content Decryption Module). The two standards underpin all browser-based OTT playback. Tier 1 (W3C Recommendation). https://www.w3.org/TR/media-source-2/ and https://www.w3.org/TR/encrypted-media/ — accessed 2026-06-17.
- Google, Widevine DRM and Shaka Player documentation, 2026. Widevine is the DRM for Android, Chrome, Android TV, and Fire TV; Shaka Player is an MSE/EME JavaScript player supporting Widevine, PlayReady, and FairPlay across browsers and smart TVs. Tier 3 (first-party engineering). https://www.widevine.com/solutions/shaka-player and https://github.com/shaka-project/shaka-player — accessed 2026-06-17. Vendor capabilities change; re-verify.
- Apple, FairPlay Streaming and AVFoundation/AVPlayer documentation, 2026. FairPlay is the DRM for Safari, iOS, iPadOS, and tvOS; AVPlayer is the native playback engine on Apple platforms. FairPlay requires the
cbcsscheme of Common Encryption (ISO/IEC 23001-7). Tier 3 (first-party engineering). https://developer.apple.com/streaming/fps/ — accessed 2026-06-17. - Android Developers, ExoPlayer / Jetpack Media3 documentation, 2026. ExoPlayer (now shipped as Media3) is the application-level media player for Android, Android TV, and Fire TV, with built-in Widevine support. Tier 3 (first-party engineering). https://developer.android.com/media/media3/exoplayer — accessed 2026-06-17.
- Samsung Developer, Tizen Smart TV "General Specifications" and AVPlay API, 2026. Tizen TV apps are web apps using the AVPlay media API; the 2026 model generation moved to the GCC 14.2.0 toolchain (from 9.2.0), requiring rebuilds of native binaries. Widevine and PlayReady are the supported DRMs. Tier 3 (first-party platform docs). https://developer.samsung.com/smarttv/develop/specifications/general-specifications.html — accessed 2026-06-17. Re-verify per model year.
- Roku Developer, SceneGraph and BrightScript documentation, 2026. Roku apps ("channels") are written in BrightScript with the SceneGraph UI framework and use Roku's native player; PlayReady is the supported DRM. Tier 3 (first-party platform docs). https://developer.roku.com/docs/developer-program/getting-started/architecture/dev-environment.md — accessed 2026-06-17.
- Hub Entertainment Research, "Connected Home / Smart TV" data, 2025; Nielsen The Gauge, 2025–2026. ~82% of US TV households own a smart TV (up from 79% and 70% in 2021); >90% of US households use a connected-TV device monthly; streaming ≈ 44% of US TV viewing time. Tier 5 (analyst/measurement). https://hubresearchllc.com/ and https://www.nielsen.com/data-center/the-gauge/ — accessed 2026-06-17. Refresh annually.
- Bitmovin, "Analysis of DRM Ciphers for Samsung Tizen TVs," 2025. Widevine and PlayReady implementations differ across Tizen firmware, so the same encrypted stream can behave differently by model year; validate DRM per device generation. Tier 4 (vendor engineering). https://bitmovin.com/blog/analysis-drm-ciphers-samsung-tizen-tvs/ — accessed 2026-06-17.
- ISO/IEC 23001-7, Common Encryption (CENC). Defines the
cenc(AES-CTR) andcbcs(AES-CBC) schemes;cbcsis required by FairPlay and is the convergent scheme that lets one encrypted asset serve Widevine, PlayReady, and FairPlay (the "encrypt once, license many" model). Tier 1 (ISO/IEC standard). https://www.iso.org/standard/68042.html — accessed 2026-06-17.
Conflict resolution: where vendor blogs and listicles implied a single cross-platform app or one universal DRM, the article followed the primary standards (W3C MSE/EME; ISO/IEC 23001-7 Common Encryption) and the first-party platform docs (Apple FairPlay, Google Widevine, Android Media3, Samsung Tizen, Roku), which establish that the language/player/DRM split is fixed by the device. Market-share and penetration figures are dated analyst ranges, presented as such. Of the ten references, four are tier-1 primary standards (W3C MSE, W3C EME, ISO/IEC 23001-7) and the W3C pair, with the first-party platform docs (Apple, Google, Android, Samsung, Roku) as tier-3 controlling sources for per-platform behavior.
