Smart TV Apps on Low-End Devices

Context

At Accedo I was an HTML5 TV developer on the My5 connected-TV app for Channel 5, delivered to a range of TV platforms. A TV app is a web app with unusual constraints: a remote control instead of a mouse, a ten-foot interface, and hardware that can be many years old with very little memory and a slow CPU.

Problem

Three problems kept coming back:

• Slow devices. What felt instant on a recent TV stuttered on an older one. Image-heavy rails, big navigation stacks and eager data loading all cost memory the device didn’t have.
• Back navigation. On a TV, the back button is the navigation model. The app’s history behaviour had grown inconsistent, and earlier attempts to limit it had stalled amid confusion about what “back” should do.
• A full rebrand, touching almost every screen, without destabilising the app.

What I did

• Optimised memory and performance for slower devices. Kept navigation stacks shallow, deferred and lazily loaded off-screen content, and questioned one-size-fits-all workarounds. One example: a fixed delay added to protect slow devices was making fast ones feel laggy too, so the right fix was per-platform tuning rather than penalising every device for the slowest.
• Designed explicit history-stack rules. Home always at the bottom; pages one level deep; a show replaces a show; episodes are leaves. I drew them as diagrams and ran sessions with the automation testers and the client to agree the behaviour before writing code.
• Refactored the video player from class components to function components and hooks. That surfaced subtle ordering changes in state updates (and some dead code), which tests then pinned down.
• Delivered the rebrand of the connected-TV app.
• Grew a knowledge-sharing culture: weekly in-office developer sessions, pair programming, structured pull requests and review feedback, a testing workshop, and mentoring newer developers.

Outcome

As on the CV: optimised memory and performance on slower devices, major performance improvements to key functionality, a full rebrand delivered, and better developer processes, including pair programming and structured code review. The back-journey work ended a long-running source of bugs and client confusion.

What I’d do again

• Agree behaviour with diagrams before code. Navigation arguments vanish when everyone’s looking at the same picture.
• Profile on the worst device you support. Your laptop lies.
• Don’t make fast devices pay for slow ones. Per-platform tuning beats a global worst case.

What I’d do differently

Set up automated performance budgets per platform (memory, time-to-interactive on key screens) early, so regressions showed up in CI rather than in testing on real hardware weeks later.

Related notes

Pair Programming · SLA vs SLO vs SLI · React Testing Strategy · Architecture Decision Records