TV / Embedded / Wearables · Client Platforms Deep Dive

Quick Facts

At a Glance

"Embedded" covers anything that isn't a phone, tablet, laptop, or desktop — TVs, watches, cars, kiosks, IoT, POS, signage, medical devices.
Inputs differ radically: D-pad remotes (TV), tiny touchscreens with no keyboard (watch), voice (car/Alexa), bar-code scanners (POS), no input at all (signage).
Hardware is constrained — slow CPUs, modest GPUs, limited RAM, often no GC headroom. Performance budgets are real.
Update channels are bespoke — TV stores, watch companion apps, OTA firmware, fleet management consoles.
Lifecycles are long — a smart TV ships for 7+ years; a car infotainment unit for 10+. Plan your dependencies accordingly.

Landscape

Platform	Where it runs	Stack
tvOS	Apple TV	SwiftUI / TVMLKit; native iOS-adjacent.
Android TV / Google TV	Sony, Hisense, Chromecast, Nvidia Shield	Kotlin + Jetpack Compose for TV.
Tizen	Samsung TVs	Web (HTML/JS) apps + Samsung SDK.
webOS	LG TVs	Enyo / web stack.
Roku	Roku devices, many TV brands	BrightScript + SceneGraph (proprietary).
Fire OS	Amazon Fire TV / tablets	Android variant.
watchOS	Apple Watch	SwiftUI; companion to iOS app.
Wear OS	Pixel Watch, Galaxy Watch	Kotlin + Compose for Wear.
CarPlay / Android Auto	Phone-projected to car	App templates; tightly restricted.
Android Automotive OS	Built-in head units (Polestar, Ford, GM)	Full Android — apps live in the car.
Embedded Linux / Yocto	POS, kiosks, signage, industrial	Custom Linux + Qt / web kiosk / Flutter.

Mechanics

10-Foot UI (TV)

Designed for a viewer ~3 m / 10 ft from the screen — large type, generous spacing, high contrast.
D-pad navigation — every interactive element must have explicit focus order; "spatial navigation" lets up/down/left/right move predictably.
No hover, no precise pointing — focus state is the only "where am I?" signal.
Performance: TVs are slow. Long lists must virtualize aggressively; assume single-core at ~1 GHz on the cheap end.
Memory pressure kills the app silently — be defensive with image sizes and caches.

Wearables — Tiny Screens, Tiny Batteries

Sessions are seconds, not minutes — design for "glance," not "browse."
Always-on display modes need stripped-down rendering to save battery.
Complications (watch faces) and tiles are first-class — your app's reach is often via these, not the launcher.
Sensors (heart rate, GPS, accelerometer) are the input. Permissions and background-execution rules are tight.
Phone-companion model still common, but standalone wear apps (with their own LTE) are growing.

Automotive — Safety First

CarPlay / Android Auto are projection — your phone runs the app, the car shows it. Apple/Google supply restricted UI templates; you cannot draw arbitrary screens.
Android Automotive OS runs in the car itself (Polestar, Volvo, Ford, GM). Full Android apps, but with categories and driving-state restrictions.
App categories: media, messaging, navigation, parking, charging, IoT, weather, point-of-interest. Anything else is rejected.
Distraction-Optimized rules: limited text per screen, no scrolling text, no video while driving, large touch targets.
Voice (Siri / Google Assistant / proprietary VPAs) is often the primary input.

Kiosks & POS

Often a locked-down Android tablet, iPad in Guided Access, or Windows IoT box.
Single-app mode / kiosk lockdown prevents users from leaving the app.
Hardware peripherals: card readers, receipt printers, scales, barcode scanners — vendor SDKs.
Payment terminals are a regulated world (PCI-PTS) — apps usually delegate to a certified pinpad.
MDM (Mobile Device Management — Jamf, Intune, AirWatch) provisions, locks, and updates the fleet.

Embedded Linux & Industrial

Yocto / Buildroot build minimal Linux images for the device.
UI stacks: Qt / QML dominate; Flutter embedder is a rising option; Chromium kiosk for web UIs.
OTA update systems: Mender, RAUC, SWUpdate — A/B partitions for safe rollback.
Fleet observability: Memfault, Balena, vendor consoles.
Real-time and safety-critical needs (medical, automotive ECUs) drift toward RTOSes (FreeRTOS, Zephyr, QNX, VxWorks) and strict standards (IEC 62304, ISO 26262).

Distribution & Updates

TV stores: App Store (tvOS), Play Store (Android TV), Samsung Apps, LG Content Store, Roku Channel Store. Each has its own review & submission process.
Watch apps usually ship as part of the phone app bundle.
Embedded fleets update over the air, often staged by ring (canary → 5% → 25% → 100%) with automatic rollback on bootloop detection.
Devices can be offline for days/weeks — design updates to be resumable and idempotent.

Picking

Native per platform (tvOS, Android TV, Tizen, webOS, Roku) or a video-optimized cross-platform engine (CTV-focused tools like Lightning/Bolt).

SwiftUI for watchOS, Compose for Wear OS. Build the phone app first; the watch app is a glance-extension.

Start with CarPlay / Android Auto templates. Move to AAOS only if you need a full custom UI (and have OEM partnerships).

Embedded Linux + Qt or Flutter; OTA via Mender or similar; MDM if it's mobile.

Pitfalls

Porting a phone app to TV unchanged — touch UI, tiny type, hover states all break with a remote.
Ignoring focus management on TV / D-pad — users get stuck with no visible focus.
Animating heavily on a low-end TV — 30 fps becomes 8 fps becomes a returned product.
Treating the watch as a small phone — wear sessions are 5 seconds; design for that, not a list of menus.
Skipping bootable rollback on embedded — one bad update bricks the fleet.
Trusting battery-free TV remotes — physical remotes get lost; pair with phone control fallbacks.

Continue