Chromecast and Google Cast development
Google Cast is not really a device platform, it is a hand-off protocol. A phone, tablet or browser tells a Cast receiver what to play, and from that moment the television is doing the streaming while the sender becomes a remote control. Google discontinued the Chromecast dongle line in 2024 in favour of the Google TV Streamer, but Cast itself lives on: it is built into the Streamer, into Android TV and Google TV sets, and into many other televisions and speakers, and the millions of Chromecasts already installed keep working. Getting the hand-off right is what makes casting feel native rather than bolted on.
- Receiver
- CAF Web Receiver (HTML/JS)
- Senders
- Android, iOS, Chrome / web
- Streaming
- HLS, DASH, Smooth
- DRM
- Widevine via EME
- Features
- Queueing, ad breaks, captions
- Note
- Chromecast with Google TV and Google TV Streamer run Android TV apps
Receivers and senders
The receiver is a web application built on the Cast Application Framework, running on the Cast device itself and responsible for playback, the on-screen presentation and the media session. Google's Styled Media Receiver is enough for straightforward playback; a custom Web Receiver is needed for your own branding, DRM handling, ad insertion or anything beyond a single media item.
Sender integration goes into your existing Android, iOS and web apps through the Cast SDK: discovering devices, showing the cast button in the right places, transferring the current playback position, and then keeping the mini-controller and notification in sync with what the television is doing.
Continuity is the whole point
The moment that decides whether casting feels right is the hand-off. Playback should resume on the television at the exact position it reached on the phone, with the same audio and subtitle track selected, the same entitlement applied, and without a visible reload. Getting back is equally important: when the viewer stops casting, playback should continue on the phone where the TV left it.
Because the receiver plays the stream itself, it needs its own credentials and DRM licence flow - it cannot borrow the sender's session. Passing authentication through to the receiver correctly is the most common source of casting bugs in protected catalogues.
Where Cast fits alongside a TV app
Casting is not a replacement for a Smart TV app; it is a complement. It costs far less than a full platform build, works on any television with Cast built in or a Cast device attached, and covers viewers who discover content on a phone. What it cannot do is offer browsing on the television or reach viewers who never open the mobile app.
One point of confusion is worth clearing up: Chromecast with Google TV and its successor, the Google TV Streamer, are different products from the classic Chromecast. They run Android TV apps and support casting, so a service targeting them needs an Android TV app, with Cast support as an addition rather than an alternative.
Frequently asked questions
- Do we need a custom receiver?
- Only if you need custom branding, DRM, ad insertion or queue behaviour. Simple unprotected playback is well served by Google's Styled Media Receiver.
- Does casting work with DRM-protected content?
- Yes - the receiver plays protected DASH or HLS using Widevine through EME. The receiver acquires its own licence, so authentication has to be passed from the sender rather than assumed.
- Is Cast support enough instead of a Smart TV app?
- It depends on the audience. Casting reaches viewers who already use your mobile app, but it offers no on-TV browsing and no presence on the television home screen, so most services do both.