DEV Community: hisuperdev

I built one iOS app that controls four different Hisense smart-TV platforms — here's how each protocol works

hisuperdev — Wed, 01 Jul 2026 11:31:23 +0000

The problem
My Hisense remote died last year and I went down a small rabbit hole trying to find a single iOS app that worked across all the Hisense smart-TV variants. Turns out Hisense ships four entirely different smart-TV operating systems depending on the model, each with its own pairing flow and command set:

VIDAA U6/U7/U8 — Hisense's own OS, the most common on the global market
Roku TV Edition — sold mostly in North America
Google TV / Android TV — A-series and some U-series
Fire TV Edition — Amazon-branded models sold in US/UK
Every iOS app I tried covered one or two of these at most. The "universal" ones used hardware-IR blasters which my iPhone obviously doesn't have. So I spent ~3 months implementing local-network clients for each platform and shipped them in a single app called Hiremote.

This post is a sketch of what each platform's protocol looks like and the trickiest parts of getting them under one roof. Useful if you're building anything that talks to consumer TVs over the local network.

**Platform 1: VIDAA — MQTT over local Wi-Fi
**VIDAA is the most Hisense-specific platform and also the one with the least public documentation. The TVs run an MQTT broker locally on port 36669 (TLS) and accept commands over a pinned topic structure.

Pairing flow:

Discover the TV via SSDP (M-SEARCH for urn:schemas-upnp-org:device:MediaRenderer:1) or via Bonjour (_hisense._tcp.local.)
Send a request_pairing MQTT message — TV displays a 4-digit PIN on screen
User enters PIN in app — app sends confirm_pairing with the code
TV returns a long-lived auth token, app stores it in Keychain
Commands sent as JSON on /remoteapp/tv/remote_service//actions/sendkey
Command payload looks like:

{ "msg_type": "remote_control", "keyName": "KEY_HOME", "device_type": "iPhone" }
The TLS handshake is the part most people get wrong — VIDAA uses a self-signed cert with a non-standard root, so you have to pin the cert or set urlSession(_:didReceive:completionHandler:) to trust the specific cert hash. Apple's Network framework handles this cleanly with sec_protocol_options_set_verify_block.

Platform 2: Hisense Roku TV — ECP over HTTP
Hisense Roku TVs implement Roku's External Control Protocol (ECP) — a plain HTTP API on port 8060. No pairing needed (this is both the upside and the downside).

Discovery is via SSDP for roku:ecp service. Once you have the IP, every command is a POST:

POST http://<TV_IP>:8060/keypress/Home POST http://<TV_IP>:8060/keypress/VolumeUp POST http://<TV_IP>:8060/launch/12 // launch Netflix
No auth, no encryption. ECP is the easiest of the four to integrate but you also get nothing for security — if a malicious app on the same LAN knows the IP, it can control the TV. That's a Roku architectural choice, not something we can fix from the client side.

One thing I built on top: a web-based version of the Roku remote at hiremote.app/hisense-roku-tv-remote that uses the same ECP calls but runs in any browser. No install required. Works because ECP is plain HTTP and we can proxy through a small Vercel edge function (CORS isn't permissive on the TV itself).

Platform 3: Hisense Google TV — Android TV Remote v2
Google TV-branded Hisense models implement Google's Android TV Remote v2 protocol — the same one the official Google TV app uses. Documentation is sparse, but the open-source androidtv-remote library documents the wire format well.

It's a TLS connection with mutual auth (both sides present a cert), running gRPC-style binary messages on port 6466 (pairing) and 6467 (control). Pairing uses a Diffie-Hellman key exchange with a 4-digit code displayed on screen.

The simplified flow:

TCP connect with TLS on port 6466
Send PairingRequest proto
TV shows code, user enters in app
Send PairingSecret with hash of (DH shared secret + code)
TV verifies, both sides swap certs for future connections
Switch to port 6467 for command messages
Once paired, commands are protobuf-encoded button events. Implementing this in Swift meant writing the protobuf definitions by hand from the open-source captures (Google never published the spec) and using Network framework's NWConnection with manual TLS configuration to handle the mutual auth.

This was the hardest of the four to get right. About 6 weeks of evening work.

Platform 4: Fire TV Edition — ADB over TCP
Fire TV Edition models are Android-based and accept ADB (Android Debug Bridge) commands over TCP port 5555. Same protocol Android developers use over USB, except over Wi-Fi.

Pairing:

User enables "ADB debugging over network" in TV's Developer Options (which they have to unlock first by tapping the build number seven times — same as on a phone)
App connects to :5555 with TLS
ADB key exchange: app sends its RSA public key, TV shows a confirmation dialog, user approves
Keys are stored, future connections auto-authenticate
Commands are issued as ADB shell commands:

input keyevent KEYCODE_HOME input keyevent KEYCODE_VOLUME_UP am start -n com.netflix.ninja/.MainActivity // launch Netflix
The protocol overhead (TLS + ADB framing) is real, so command latency on Fire TV Edition is the worst of the four — about 150ms vs ~30ms on ECP/VIDAA. Not bad, but noticeable.

This is also the only platform where the user has to dig into developer settings — friction we couldn't engineer away. Onboarding for Fire TV users is a longer flow.

The hardest part: figuring out which platform a given TV is
Users don't necessarily know which OS their Hisense TV runs. They see "Hisense" on the box. So the app has to detect the platform before showing pairing instructions.

Initially I just probed all four ports in parallel (tryConnect(IP, 8060) for ECP, tryConnect(IP, 36669) for VIDAA, etc.) and used the first one that responded. Worked but felt hacky and produced false negatives when one of the probes timed out.

Better approach: use mDNS service discovery. Each platform advertises a distinct service:

Platform mDNS service
VIDAA _hisense._tcp.local.
Roku TV _googlecast._tcp.local. (Roku also advertises this) + roku-info headers
Google TV _googlecast._tcp.local. + _androidtvremote._tcp.local.
Fire TV _amzn-wplay._tcp.
So a single NetServiceBrowser scan returns a list of TVs with platform labels attached. The remaining edge case is when a user has both a Roku TV and a Chromecast on the network — both advertise _googlecast._tcp.local. — so we also check the TXT record manufacturer field to disambiguate.

This bit took me longer than the four protocol implementations combined.

What I shipped
Hiremote — single iOS app, all four platforms, free download. Pro tier ($9.99/year) adds Apple Watch app + Lock Screen widget + custom button layouts. Built solo, 1.3K App Store ratings, 4.6 average.

Stack:

iOS app: SwiftUI + Network framework + Bonjour for discovery
Marketing site: Next.js 16 App Router
What I learned
A few non-obvious things for anyone building similar local-network app integrations:

mDNS first, port-probing as fallback. Service discovery is faster, gentler on the network, and produces fewer false positives. Pure port-probing also looks like port-scanning to some network security appliances.

TLS pinning matters for consumer TVs. Several platforms use self-signed or non-standard root certs. Network framework's sec_protocol_options_set_verify_block handles this cleanly; URLSession does not.

Pairing UX is most of the UX. Users don't read instructions. The pairing flow has to handle: "I didn't see the PIN," "The PIN went away," "It says pairing failed," and "Will this work again next time?" — each as a first-class state, not an error.

AppKeychain for tokens, not UserDefaults. Obvious in retrospect; I burned a day debugging why tokens disappeared on iOS restore from backup before fixing.

Apple's Network framework is genuinely good for this kind of work. I started with URLSession + raw sockets and migrated halfway through. NWConnection's state machine is cleaner than anything I'd have written by hand.

Links
App Store: Hiremote on App Store
Site + troubleshooting docs: hiremote.app
My other side projects: hisuperdev.github.io
Happy to answer Qs about any of the four protocols, multi-platform iOS app architecture, ASO for niche utility apps, or solo-dev distribution. Reply or DM me.

How I built a single iOS app that controls all four Hisense smart-TV platforms

hisuperdev — Thu, 28 May 2026 13:27:48 +0000

Hisense ships TVs with four different operating systems — VIDAA,
Roku TV, Google TV, and Fire TV. The official "Remote for Hisense
TV" you find in their app store only works with VIDAA. When I lost
my own remote, I had a Google TV-flavored Hisense, so I built a
single-app solution that pairs with whichever platform the user has.

Here's how each of the four local-network protocols works, and how
the app picks the right one without asking the user.

TL;DR

Platform	Local protocol	Pairing
VIDAA	MQTT over TLS	Direct local connection
Roku TV	ECP over HTTP	Open by default on port 8060
Google TV	gRPC, TLS)	4-digit PIN
Fire TV	ADB-over-Wi-Fi	One-time TV-side prompt

All four are LAN-only — no cloud involvement once paired.

1. VIDAA — MQTT over TLS

VIDAA TVs accept TLS connections on port 36669 and speak MQTT
underneath. The control message format publishes button presses as
small JSON payloads — {"key": "KEY_VOLUMEUP"} etc. — to predictable
topics scoped by the TV's MAC address. Other developers in the Home
Assistant community have written about this in detail; my Swift
implementation is on top of that prior work.

2. Roku TV — ECP is HTTP

Almost too easy. Roku publishes the External Control Protocol
publicly. Every Roku and Hisense Roku TV listens on port 8060:

curl -X POST http://192.168.1.100:8060/keypress/Home curl -X POST http://192.168.1.100:8060/keypress/VolumeUp curl http://192.168.1.100:8060/query/active-app curl http://192.168.1.100:8060/query/device-info curl -X POST http://192.168.1.100:8060/launch/12

No pairing. No PIN. If your phone and the TV are on the same LAN,
you can drive it from a curl one-liner. This is why I shipped an in-browser Roku remote — for Hisense Roku TV owners, you don't actually need an app at all. The page implements ECP from JavaScript and runs in any modern browser. Cannibalises my own install funnel for that segment, but it's the right call for the user.

3. Google TV — gRPC dance

Google TV uses gRPC over TLS with cert pinning. Pairing exchanges a
4-digit PIN through paired proto messages — the Android TV Remote v2
protocol. The .proto definitions are discussed in various developer
communities; from there it's standard gRPC client work.

4. Fire TV — ADB-style local connection

Fire TV runs Android and supports network-mode ADB on port 5555.
After the user enables developer-friendly settings on the TV, the
app authorizes once via a permission prompt on the TV screen.

Platform detection via mDNS

The app browses for service types:

_androidtvremote._tcp → Google TV
_roku-rsp._tcp → Roku TV
_amzn-wplay._tcp → Fire TV
Port-scan port 36669 fallback → VIDAA

The first responder wins. The user never picks "what kind of Hisense
TV is this" unless detection fails.

The implementation ships as Remote for Hisense TV on the App Store, free with a Pro tier ($9.99/year) that adds the Apple Watch app, Lock Screen widget, and removes ads. The marketing site with deeper troubleshooting articles is at hiremote.app.

Happy to answer iOS protocol questions in the comments.

I built an in-browser Roku TV remote with ~80 lines of TypeScript. Here's how Roku's ECP API actually works

hisuperdev — Sun, 24 May 2026 21:50:15 +0000

Roku ships an HTTP API on every device they sell. It has no authentication, no API key, no documentation page on a marketing site — but it powers every third-party Roku remote app on the App Store and Play Store. It's called ECP (External Control Protocol) and once you've seen it, you'll wonder why the rest of the smart-TV world isn't this simple.

I needed an in-browser remote for HiRemote's Hisense Roku TV landing page — the idea being a visitor who lands on the page can press buttons in the page itself without first installing the iOS app. Three quirks made it harder than the marketing-page version suggests; here's the actual implementation.

1. Discovery — SSDP is overrated, the user types the IP

Every Roku tutorial starts with "use SSDP multicast on 239.255.255.250:1900". This is true but useless from a browser: browsers can't send UDP. You can't run SSDP from JavaScript.

For a browser-based remote, the pragmatic solution is: ask the user for their TV's IP. On the iPhone app side we use Bonjour. On the web page side we just show a one-time input box, then localStorage it. Roku TVs always run ECP on port 8060, so once you have the IP, the base URL is fixed:

const baseUrl = `http://${tvIp}:8060`

The only gotcha here is that the user's browser is HTTPS but the TV is HTTP. Modern browsers block mixed-content requests, so you have to either accept this and let the request fail gracefully, or proxy through your own backend. We chose the first option — the input box explains the limitation and tells the user to also try the iOS app which doesn't have this restriction.

2. Buttons — every command is a POST to a path

The control surface is one of the cleanest API designs I've seen in a consumer device:

POST http://<tv-ip>:8060/keypress/<KeyName>

<KeyName> is one of about 30 documented strings: Home, Up, Down, Left, Right, Select, Back, Play, Pause, Rev, Fwd, VolumeUp, VolumeDown, VolumeMute, PowerOn, PowerOff, plus a few platform-specific ones for Roku TV (channel up/down, input switching).

No body, no headers, no auth. Just the POST:

async function sendKey(key: RokuKey) {
  return fetch(`${baseUrl}/keypress/${key}`, {
    method: "POST",
  })
}

For typing into search boxes (Netflix login, YouTube search), there's /keypress/Lit_<urlEncodedChar> — one POST per character. Cleaner than building a virtual keyboard, ugly that it isn't batched, but it works.

3. Direct-app-launch — the surprisingly useful one

The endpoint nobody talks about:

POST http://<tv-ip>:8060/launch/<channel-id>

Channel IDs are stable Roku-assigned numbers. 12 is Netflix, 13 is Prime Video, 837 is YouTube, 291097 is Disney+. Posting to /launch/12 boots Netflix on the TV — no D-pad navigation needed.

This is the killer feature for a remote that lives on a phone or in a browser: you skip the entire "navigate the home screen" UX that makes physical Roku remotes annoying. One tap → on Netflix.

Full list of channel IDs is in the device's response to GET /query/apps (returns XML, so use DOMParser not JSON.parse).

4. Putting it together

type RokuKey =
  | "Home" | "Back" | "Select"
  | "Up" | "Down" | "Left" | "Right"
  | "VolumeUp" | "VolumeDown" | "VolumeMute"
  | "PowerOn" | "PowerOff"
  | "Play" | "Pause" | "Rev" | "Fwd"

class RokuRemote {
  constructor(private tvIp: string) {}
  private base() { return `http://${this.tvIp}:8060` }

  press(key: RokuKey) {
    return fetch(`${this.base()}/keypress/${key}`, { method: "POST" })
  }

  type(text: string) {
    return Promise.all(
      [...text].map(ch =>
        fetch(`${this.base()}/keypress/Lit_${encodeURIComponent(ch)}`, { method: "POST" })
      )
    )
  }

  launchApp(channelId: number) {
    return fetch(`${this.base()}/launch/${channelId}`, { method: "POST" })
  }
}

That's the whole remote. Render a D-pad with onClick={() => remote.press("Up")} and you have a working web-based Roku remote in 80 lines.

TL;DR

Roku's HTTP control protocol is plain POST /keypress/<KeyName>. No auth. 80 lines of TypeScript = working remote. Discovery is the only genuinely hard part for a browser context, and "ask the user for the IP" is the right answer there.

The end result is live at hiremote.app/hisense-roku-tv-remote — bring your own Roku-TV IP and try it without installing anything.