A shared player core for Tizen, webOS, and BrightSign | Ricardo Lara | Software Architecture

How to move an Android-first player toward a shared core for Tizen, webOS, and BrightSign without fragmenting its operational behavior.

During an early phase, our player only ran on Android.

At that point, the technical pressure was not about supporting multiple environments. It was about solving the product well on a single platform. But as new targets started to appear, Tizen, webOS, and BrightSign, it became clear that extending the same approach platform by platform would leave us with a system that was hard to sustain.

The most obvious option was also the most expensive one: build a player variant for each environment. One for Android, another for Tizen, another for webOS, another for BrightSign. On paper, that sounded reasonable. Each platform brought its own runtime, APIs, hardware constraints, and its own way of integrating with the system.

The problem is that this approach does not scale well when the real challenge is not just rendering content, but preserving the full operational behavior of the system.

That was the technical decision I made: stop thinking in terms of “player versions” and start building a shared core able to sustain a single operational semantics, while each platform was reduced to a capability adapter.

It was not a decision aimed at code reuse for its own sake. It was a decision that let the product scale toward new platforms without fragmenting its critical behavior.

When it stops being a frontend problem

A real player is not limited to showing a video or opening a web page.

It has to boot consistently, recover state, pair with the backend, operate when the network fails, obey remote commands, respect operating windows, coordinate with other devices, and sustain predictable behavior across runtimes that do not share the same capabilities.

That was the point where the problem stopped looking like a conventional web app.

Instead of thinking in views and components, we started thinking in boot sequence, fault tolerance, local state, safe degradation, system contracts, and runtime compatibility. The interface still existed, but it was no longer the center of the architecture.

If each new platform solved on its own how to boot, how to recover content from cache, how to react when the backend failed, or how to synchronize with other screens, then the product started to diverge even if it looked uniform from the outside.

The UI could look the same. The system no longer was.

The architectural decision

The decision was to separate common behavior from platform adaptation.

The shared core had to own what actually defines the player as a system:

• how it boots
• how it decides between online and offline operation
• how it interprets scheduling
• how it organizes playback, playlists, and layouts
• how it responds to remote commands
• how it preserves state consistency
• how it participates in synchronization scenarios

The platform, by contrast, should solve only what depends on the environment:

• device identity
• screen orientation
• display control
• application restart
• native player integration
• embedding web surfaces
• access to system-specific APIs

The difference sounds small, but it is not.

The core no longer needed to know Android, Tizen, webOS, or BrightSign as concrete implementations. It only needed clear contracts. Each platform stopped rewriting player behavior and started implementing the minimum capabilities that allowed that behavior to run inside its runtime.

Put simply: we did not want several similar players. We wanted one operational semantics and several adapters.

The runtime was also part of the problem

One of the clearest lessons in this process was understanding that “multi-platform” does not just mean different operating systems. It means different execution engines, different support levels, and different real production limits.

On LG devices, for example, different generations of webOS TV shipped with materially different Chromium engines. Samsung, meanwhile, documents real differences across Tizen generations in support for features like @supports, env(), and other modern CSS capabilities.

That has a practical consequence: transpiling syntax does not solve the whole problem.

A bundle can be language-compatible and still fail because the environment does not offer certain APIs, offers them only partially, or because its load and boot order does not tolerate modern assumptions. In some cases, even seemingly ordinary syntax such as object spread becomes a problem depending on the engine version and the exact point in the boot path.

In this kind of system, the runtime is not an implementation detail. It is part of the product design.

That is why compatibility stopped being a late fix and became a central responsibility: detect real capabilities, load compatibility work before boot, degrade safely, and stay disciplined about which assumptions the final artifact is allowed to make.

What the system gained by moving logic into the core

Once that boundary became clear, several critical pieces stopped scattering.

The first was boot.

Booting a player is not loading an interface. It is deciding whether the device is correctly associated, whether it can reach remote services, whether it has valid scheduling, whether it can continue with the last locally persisted version, or whether it must enter a degraded state. That sequence is part of product behavior. It should not vary by platform.

The second was playback logic.

I am not just talking about showing content, but about the whole semantics that comes before it: deciding what should be shown, in which order, under which priority, with which transition, and how to sustain playlists, layouts, and multiple zones without each environment interpreting different rules.

The third was the operational logic around playback.

Power schedules, remote commands, device synchronization, messaging, cache, and failure recovery. Those capabilities are less visible than rendering, but much more decisive for system stability.

The real value appears when there is no network

One area where this architecture showed the most value was offline mode.

When a device loses connectivity, the useful question is not whether the player “works” or “doesn’t work”. The question is which continuity policy the system applies.

In our case, that policy was clear: if the online flow could not complete, the player had to try to keep operating with the last valid schedule persisted locally, together with the minimum configuration and identity needed to sustain service. Only when there was no sufficient operational base did it make sense to expose a true offline state.

That behavior sounds obvious when stated that way. It is not obvious when it is split across multiple implementations.

Concentrating it in the core allowed offline to stop being a platform-specific interpretation and become a single system policy: preserve continuity from local state before degrading operation.

Synchronization also stopped depending on wrappers

Something similar happened with device synchronization.

When several screens form a single experience, it is not enough for all of them to play content at roughly the same time. You need a shared semantics for what it means that an asset is ready, when it enters the screen, how drift is corrected, and what to do when the reference is temporarily lost.

That is not solved by messaging alone. It is solved when all nodes share the same interpretation of the operational cycle.

The core enabled exactly that: synchronization stopped being informal coordination between implementations and became explicit system behavior.

What this solved, and what it did not

It would be naive to present this architecture as a total simplification.

Complexity does not disappear. It is still in the hardware, the network, the old engines, the system APIs, memory constraints, and the differences between environments. What changes is where that complexity is managed.

Instead of scattering it across variants that diverge over time, it is concentrated in a layer where decisions are explicit, contracts are visible, and critical behavior can be observed, hardened, and evolved under a single semantics.

That demands rigor. It demands keeping adapter details out of the core. It demands well-designed interfaces. It demands accepting that a bad abstraction in this layer has wide impact.

But that cost is lower than the cost of letting the system diverge without control.

Closing

In retrospect, building a shared player core was not a decision made to “reuse more”.

It was the technical decision required to scale a player that had started on Android toward Tizen, webOS, and BrightSign without splitting its critical behavior across different implementations.

This was not about writing less code.

It was about deciding where the logic that could not be allowed to diverge had to live.

When a system has to operate across multiple platforms, with different runtimes and real production constraints, sharing the core does not remove complexity. But it does move it to the right place: a layer where it can be observed, stabilized, and evolved without losing control of the product’s semantics.

Originally published at https://ricardolara.dev on February 27, 2026.