A 4K streaming player for Samsung and LG televisions

A browser engine from 2015, in a living room today

Samsung and LG televisions run web applications, which sounds like familiar ground until you look at what they run them on. A set sold in 2018 is still in service, and its engine is roughly Chromium 47. It has a fraction of the memory a phone has and a CPU to match, and it is being asked to decode 4K video at the same time as it renders your interface.

The application draws onto a fixed 1920 by 1080 canvas that the television scales to its own panel, so a 4K set changes sharpness and nothing else. That one decision removed an entire class of layout bug before it could exist, and made every measurement we took comparable across very different hardware.

• No flexbox gap: spacing is a margin on the child, every time.
• No CSS grid: every layout is flexbox or absolute positioning.
• No blur and no heavy shadows: they cost frames the video decoder needs.
• Only transform and opacity are ever animated, because everything else triggers layout.

Constraints this hard are clarifying. There is exactly one way to build most of the interface, and it is the fast way.

Navigation is the product

A phone application is judged on how it looks. A television application is judged on whether the remote control does what the viewer expected. There is no pointer, no scrolling and no gesture: four directions, confirm, back, and play. Every screen is a grid the viewer walks across, and one wrong focus move irritates more than a slow page ever will.

So focus is an explicit, index-based model rather than something inferred from the DOM. Each surface knows which cell is focused, what every direction means from there, and how to bring the result into view. Geometric search exists only as a fallback for cases the model does not describe. Key repeat is throttled and collapsed to a single move per animation frame, so holding a direction scrolls at a readable speed instead of overshooting by twenty rows.

Lists that stay smooth on a television processor

Channel lists run to thousands of entries. Rendering them all is out of the question, and ordinary virtualisation still re-renders on every focus move, which on this hardware is enough to drop frames.

Instead the visible window is a fixed set of row elements that never unmount. Moving the focus writes new text and new state directly into those rows, bypassing the framework's render path completely. On a real television the profiler we built into the application reported zero component renders per second while the viewer scrolled: the work had left the render cycle entirely.

Profiling on the device, because the laptop lies

Everything felt instant in a desktop browser and sluggish on an actual set. That gap is the normal state of affairs on this platform and the reason so many television applications ship slow. Retail televisions have no usable developer tools, so we built a performance overlay into the application itself and read it from the sofa.

It redirected the work immediately. Frame times during navigation sat around 165 to 265 milliseconds with the video preview disabled, and between 0.5 and 1.3 seconds with it running. The bottleneck was never the interface. It was the decoder competing for the same silicon, and no amount of further component optimisation would have bought a thing.

Measuring first is not a process preference on hardware like this. It is the difference between a week of real improvement and a month spent tuning the wrong layer.

The backend a fleet of devices needs

Behind the application sits a Spring Boot service on Java: a device registry, licensing and activation, per-device configuration, and a settings pipeline that lets an operator change behaviour on televisions already in living rooms without shipping a new build.

A device identifies itself once at start-up and receives everything it needs in a single response: feature flags, limits, pricing, the lot. The application caches that in IndexedDB and keeps working when the network does not. Settings are scoped by platform, so a flag can apply to Samsung sets and not to others, and the panel that edits them is the same one the support team uses daily. That is backend work in service of a product decision: being able to change your mind after the firmware is out of your hands.

Getting through store review

Submitting to Samsung's store is a project of its own. It wants icons and screenshots at exact dimensions, a description that survives review, an age rating that matches what the application actually does, and legal terms that state plainly what the software is for and what it is not.

We generate every store asset from one set of vector masters through a build script, so a brand change regenerates the entire pack byte for byte instead of being redrawn by hand. That matters more than it sounds. The second submission is where most teams lose a fortnight.