Short answer: almost everything below the content model changes. TV apps are navigated with a directional remote, run on hardware that is often years old, are split across platforms with different languages and SDKs, and must pass each store's certification. Plan for focus navigation, performance budgets, per-platform playback and certification from the first build.
1. The remote control changes the interaction model
There's no pointer and no touch. Users move focus up, down, left and right, press OK, and press Back. Every screen therefore needs an explicit focus model: where focus starts, where it goes from each element, and what Back does.
- Focus must always be visible. A user who can't see what's selected is stuck.
- Navigation must be predictable. Pressing right should never jump to an unexpected corner of the screen.
- Back behaviour is often certification-relevant. Several platforms specify how Back must behave on the home screen and during playback.
- Text input is painful. Prefer search suggestions, voice where supported, and signing in via a phone (activation code or QR) over on-screen keyboards.
2. Ten-foot design is not big web design
Viewers sit around three metres away. Type must be larger, contrast higher, and layouts simpler. Safe areas matter because some TVs crop the edges of the picture. Dense dashboards and small text that work on a laptop fail on a TV. A shared design system can still work across platforms — with TV-specific components and spacing.
3. Hardware is slower and older than you think
People keep TVs for years, and streaming sticks are built to a price. Apps that feel instant on a new flagship can stutter on a mid-range model from several years ago. Budget for this explicitly:
- Serve correctly sized artwork per device instead of scaling large images on the client.
- Virtualise long rails and grids; don't render hundreds of tiles at once.
- Keep API responses lean — TV clients pay for every unnecessary field.
- Test on real low-end devices, not just emulators and new hardware.
4. "Smart TV" is several different platforms
| Platform | Typical technology | Notes |
|---|---|---|
| Roku | BrightScript, SceneGraph | Proprietary language and UI framework; dedicated certification criteria. |
| Android TV / Google TV | Kotlin/Java, Leanback or Compose for TV | Shares Android skills; TV-specific UI and home-screen integration. |
| Fire TV | Android-based (Fire OS) | Close to Android TV with Amazon-specific requirements and store. |
| Apple TV | Swift, tvOS frameworks | Focus engine and App Store review rules. |
| Samsung | Tizen web apps (HTML/JS) | Web technologies; behaviour varies by model year. |
| LG | webOS web apps (HTML/JS) | Web technologies; frameworks such as Enact or Lightning are common. |
Web-based platforms (Tizen, webOS, some set-top boxes) can often share a codebase. Roku, tvOS and Android TV generally need their own apps. What you can — and should — share across all of them is the backend, API, content model, business rules and design language.
5. Video playback is where most problems hide
Streaming formats, DRM systems and codec support differ by platform and sometimes by model year. A stream configuration that works perfectly in a browser may fail on a particular TV. Validate early: packaging (HLS/DASH), DRM, captions, multiple audio tracks, ad insertion and resume behaviour on each priority platform. This is exactly what a TV POC should prove. More on video & streaming.
6. Certification is part of the project, not the end of it
Each TV store publishes requirements covering things like launch time, Back button behaviour, deep linking, playback controls, accessibility and content policies. Treat these checklists as acceptance criteria from the start. Leaving them until submission is one of the most common reasons TV launches slip.
How to plan a TV app project
- Choose priority platforms using your audience data, not general market share.
- Design the shared API and content model for TV constraints from day one.
- Build a POC on one or two priority platforms that proves navigation, performance and playback on real low-end devices.
- Define a feature matrix per platform — not every feature belongs everywhere.
- Track certification requirements as acceptance criteria throughout development.