REDSMARTTV

What we build / Cross-platform

One codebase across four television runtimes

This page is the technical argument, not the sales pitch. If you are the person who has to decide whether a shared codebase is real engineering or a story told to win a tender, it is written for you — including the parts that do not share.

The problem

An HbbTV terminal browser bound by ETSI TS 102 796. Tizen's Chromium-derived runtime. webOS. Android TV. Different key codes, different media pipelines, different application lifecycles, different packaging, different review queues — and, usually, four teams who each learn one of them.

The default answer is separate builds. The default outcome is divergence: by the second year the four applications no longer agree on what a programme is, and every feature is scoped four times. The feature your editorial team asked for ships on two platforms, and nobody can say exactly why it did not ship on the other two.

The architecture

Targets

  • HbbTV browser runtime
    URL + Content-Type
    no store
  • Samsung Tizen Chromium runtime
    .wgt
    Seller Office
  • LG webOS Chromium runtime
    .ipk
    Content Store
  • Android TV WebView / native
    .apk
    Play Store

Adapters

  • input · media · lifecycle · storage · packaging
  • input · media · lifecycle · storage · packaging
  • input · media · lifecycle · storage · packaging
  • input · media · lifecycle · storage · packaging

The only platform-specific code — about 10%

Shared

One React application — about 90% of the codebase

  • Screens & routing
  • Component library & design tokens
  • Domain model & state
  • API clients — REST + GraphQL

Backend

  • Headless Drupal
  • Elasticsearch
  • EPG ingest
  • VAST ad server
  • Livestream origins
Read it from the bottom. One application holds the screens, the component library, the domain model and the API clients. Above it sits a thin adapter per runtime. Above that, four televisions that each want something different.

Shared

What is genuinely shared

The data layer

API clients, caching, and the contract with the CMS. One place where a programme, a series and a stream are defined, so all four platforms agree on what they are showing.

Domain and state

Continue-watching, favourites, the rules about what may be played where. Business logic written once.

The component library

Every screen is built from the same React components and the same design tokens, so a change to a tile is a change to every tile on every set.

Routing and composition

The same navigation model everywhere. A viewer who knows your app on one television knows it on the next.

Not shared

What is not shared, and why not

Five seams. Anyone who tells you there are none has not shipped on four runtimes.

Close-up of a broadcast video patch panel with several patch cords connected
One signal, four destinations, and a short piece of dedicated wiring for each.
Input
HbbTV has keysets and the six gating layers of clause 10.2.2.1 — a key press reaches your app only if six conditions all hold. Tizen wants registerKey. And webOS has the Magic Remote, which is a pointer, not a d-pad: that is an interaction-design problem, not a key-mapping one, and it is the seam that most often surprises people.
Media
video/broadcast and the A/V control object on HbbTV, AVPlay on Tizen, webOS media on webOS. Different DRM, different codec support, and different failure modes at the same bitrate.
Lifecycle
destroyApplication() against native suspend and resume, and four different answers to what the back button does on the first screen.
Packaging
A signed .wgt through Samsung Seller Office, an .ipk through the LG Content Store, an .apk through Play — against an HbbTV application that is a URL with the right Content-Type and no review at all. The asymmetry is not a detail: it decides your release calendar.
Performance
The oldest set you still support sets the budget for every set, and it is a different device on each platform. This is the constraint that decides how much React you can actually afford.

The bench

Four television sets side by side on a test bench, each showing an abstract field of light
Every release ships to four runtimes on the same afternoon, and we watch all four take it.

Costs

What it costs, and what it buys

A shared architecture costs more up front than one application for one platform, and less than two. The return is not in the first release. It is in every release after it, and it compounds: one release train, one QA pass, one feature request.

It also stops making sense somewhere, and we would rather say where. Below two platforms it is overhead you do not need. And if one platform's experience has to diverge fundamentally rather than cosmetically, forcing it into the shared model gets you the worst of both — a codebase with a branch in it that nobody wants to touch.

Next

Tell us what you are building.

Christian answers these himself, usually within a working day.

Start a conversation