Platform notes for connected TV development

Working across connected TV platforms is an exercise in managing differences. The same streaming app might need four entirely separate codebases, or at minimum four different build targets with platform-specific playback integration, navigation handling, and performance tuning.

We maintain reference notes for the platforms listed below. Each page covers the runtime environment, input model, media capabilities, and common gotchas that come up during development and QA.

Cross-platform considerations

Every platform page here exists because the differences between devices matter enough to document. But some concerns cut across all of them:

Playback pipeline. Every platform handles media differently at the system level. Some expose raw MSE. Some use a proprietary player API. Some have hardware DRM decryptors, others do it in software. Understanding these differences early prevents costly surprises during integration.

Input and navigation. TV remotes have five buttons that matter: up, down, left, right, and select. But each platform handles focus management differently. Some provide a framework for spatial navigation. Others leave it entirely to the app.

Memory and performance. Consumer TV hardware is not powerful. A device that shipped three years ago might have 1.5 GB of RAM total, with half of that used by the OS. Your app gets what is left. Long viewing sessions, channel switching, and deep menu navigation all create memory pressure that does not show up in short test runs.

App lifecycle. What happens when the user presses the home button? Or when the screensaver activates? Or when an HDMI CEC command arrives? Each platform handles app suspend, resume, and termination differently, and getting it wrong causes playback failures or data loss.

Browse the platform pages above for specifics on each environment. For broader architectural guidance, see streaming app architecture.