Mobile remote controller apps (Apple TV Remote, Sonos, Logitech Harmony, smart-home remotes) are tiny apps with surprising depth. Real-time low-latency control, device discovery, network reliability, and the UX challenge of making a complex remote feel like a single button press.
Functional requirements
- Discover devices on the local network. Handle the messy cases interviewers probe: zero devices found, several identical TVs in the same house, and stale entries for devices that have gone offline. The list should update within a second or two of launch.
- Send commands with low latency (<100ms). A button tap has to feel like it moved the physical device, so the round trip from tap to acknowledgement needs to stay under the threshold where the user starts pressing again because nothing happened.
- Show current state (volume, current track, channel). The remote is not the source of truth; the device is. If someone changes the volume with the physical remote, the app has to reflect it, which is why this is a synchronization problem, not a display problem.
- Cast media from phone to TV. The phone hands off a URL and lets the TV stream it directly, rather than piping bytes through the phone. This is the design point interviewers most often push on.
- Voice commands. Either the phone captures and transcribes audio, or it forwards the request to a device that does its own speech recognition. Latency and where the audio is processed are the tradeoffs to discuss.
- Reliable when phone connects to a different network. Cellular, guest Wi-Fi, or a work VPN all break local discovery, so the design needs a fallback path (usually cloud relay) and a clear message when direct control is not possible.
Discovery protocols
- mDNS / Bonjour: standard for Apple devices and many smart-home
- SSDP: for DLNA / UPnP (older smart TVs)
- Custom Bluetooth discovery: for newer devices
- Cloud-based: register device with manufacturer cloud; phone fetches list
App scans on launch; refreshes when network changes.
Communication
Three patterns:
- Local network: phone → device direct over Wi-Fi (lowest latency)
- Bluetooth: direct to device over BLE
- Cloud relay: phone → cloud → device (works when phone and device on different networks)
Apple TV Remote and Sonos use local network primarily; cloud relay as fallback. A common follow-up in a system design interview is how the app decides between these paths: try local first, fall back to relay when discovery fails, and surface the current mode so the user understands why control feels slower.
Latency
Volume change should feel instant:
- Local network: 10–30ms typical
- Bluetooth: 30–100ms
- Cloud relay: 100–500ms
Above 200ms feels laggy. Above 500ms feels broken.
State synchronization
The remote needs current device state:
- Now playing: title, artist or show, artwork, and playback position. Position keeps advancing, so the app estimates it locally between updates rather than polling every second.
- Volume: the value most likely to change from outside the app (physical remote, another phone), so it needs the fastest push updates to avoid the slider jumping under the user’s finger.
- Power state: on, off, or standby. A device that is off can still be reachable on some transports, so power and reachability are separate flags.
- Connected source: which input or app is active (HDMI 2, a streaming app, a specific speaker group). This drives which controls the app even shows.
Devices push real-time state changes to subscribed apps. App also polls on foreground to recover from missed pushes.
Casting
Sending media from phone to TV:
- Chromecast / Google Cast: cast SDK; app sends media URL + metadata; TV plays
- AirPlay: similar for Apple ecosystem
- DLNA: legacy but still used
The phone is a remote, not a media source. TV streams directly from the URL.
Voice commands
Two patterns:
- App captures voice; transcribes via cloud; sends as command
- App relays to device with built-in voice (TV does its own ASR)
Latency matters; on-device ASR (when available) is faster.
Network changes
User’s phone moves between Wi-Fi networks. Implications:
- Devices on the prior network are no longer discoverable
- App should refresh device list on network change
- Cloud relay can bridge the gap
Battery
Remote apps are not always-on. Battery impact: minimal. Use foreground BLE / Wi-Fi only when actively controlling.
Security
- Pairing requires explicit user action (button on device, code entered in app). This stops a neighbor on the same Wi-Fi from silently controlling your TV, and it is the moment where keys get exchanged for later encrypted sessions.
- Communication encrypted. Even on the local network, commands and state are encrypted so anyone sniffing the Wi-Fi cannot replay a command or read what you are watching.
- Cloud relay does not have access to media or sensitive content. It forwards opaque, encrypted payloads between phone and device, so a breach of the relay does not expose viewing history or media streams.
Common gotchas
- Phone connects to guest Wi-Fi; cannot find devices
- Discovery via mDNS blocked by enterprise firewalls
- Lag during streaming due to local network congestion
- Multi-room audio sync (Sonos) requires precise time sync between speakers
Frequently Asked Questions
Why does my Sonos app sometimes not find speakers?
Network issue. Phone needs to be on the same Wi-Fi as speakers. mDNS may be blocked by router config.
How does AirPlay achieve such low latency?
Apple-controlled silicon for both ends. Optimized network protocol. Fewer hops than DLNA / Chromecast.
Should I use Bluetooth or Wi-Fi for remote control?
Wi-Fi for richer features; Bluetooth for simpler devices and lower battery. Many products support both.
Keep sharpening your system design:
