Web player
Responsive, adaptive playback in the browser, with the catalogue, sign-in and billing flows. The path a first-time visitor takes before they install anything.
A platform is judged on the screen someone is holding. The applications ship with the deployment, carry your branding, publish under your own developer accounts, and talk to your APIs — so the thing your audience installs is your product, not a vendor's app with your logo in it.
There are two ways to give a streaming service an app. One is a white-label shell: a single application the vendor operates, reskinned per customer, published under the vendor's account. It is fast, and everything about it — the release schedule, the store listing, the analytics, the ability to add a feature — belongs to somebody else.
The other is what ships here. Native applications built for the platform, delivered into your repositories, published under your developer accounts, pointed at your APIs. A change your business needs is a change your team or ours can make, and the review queue you are waiting in is your own.
The playback path is the same on every one of them, which matters more than it sounds. One adaptive ladder, one packaging format, one per-segment authorisation scheme, one telemetry beacon. A bug in the ladder shows up everywhere at once and is fixed everywhere at once, instead of behaving differently on each surface because three vendors implemented it three ways.
The applications are branded with your identity — name, mark, colour, typography, artwork — and submitted under your own developer accounts on each store. That is a deliberate structural choice rather than a styling one: the listing, the reviews, the ratings, the install base and the ability to publish an update on a day you choose all follow the account, and an operator who does not hold the account holds none of them.
It also decides what happens if you stop working with us. An application published under your account stays yours, in your store listing, with its install base intact. There is no version of leaving that begins with asking a vendor to transfer your audience.
The store assets — icon, feature graphic, screenshots, description — are produced with the applications, and the same rule applies to them as to everything else on this site: the screenshots are captures of the real application running against real data, not renders.
Three applications are in production and carry a live consumer service. Two are in development, and are listed as such.
Responsive, adaptive playback in the browser, with the catalogue, sign-in and billing flows. The path a first-time visitor takes before they install anything.
The native Android application — browse, search, detail, live and the player — built against the same APIs as the web. Offline downloads are not offered: an encrypted download needs a licence that expires with the subscription, and that licence path is not built.
A real television application, not a phone layout stretched. D-pad navigation, a leanback browse model, and a player tuned for the living room.
Under active development, not shipping. Anyone comparing platforms should plan against the date discovery produces rather than against this page.
Under development for Samsung smart televisions. The web player already covers Tizen's browser in the interim, which is not the same thing as a store-listed application.
Anything not listed as shipping is not shipping. A platform grid that implies otherwise is the fastest way to lose a technical evaluation.
| Surface | Status | What that means today |
|---|---|---|
| Web browser | Shipping | Desktop and mobile browsers, adaptive playback, full catalogue and account flows |
| Android phone | Shipping | Native application, published under your developer account |
| Android tablet | Shipping | Same application, tablet layouts |
| Android TV | Shipping | Native leanback application, D-pad navigation |
| iOS and iPadOS | In development | Not available to install; plan against a date from discovery |
| Samsung Tizen | In development | Not store-listed; the web player covers Samsung's browser meanwhile |
| LG webOS | Not built | No application exists today. A scoped piece of work, not a toggle |
| Roku | Not built | No application exists today. Its own SDK and its own store review |
| Amazon Fire TV | Not built | No application exists today, though it is the closest to the Android TV build |
| Apple TV — tvOS | Not built | No application exists today, and it follows iOS rather than preceding it |
At the licence tiers that include it, yes, and the applications are delivered into your own repositories. Source inclusion is tier-dependent rather than automatic — it is settled in the agreement, and the licence page says so plainly rather than leaving you to discover it. What is not tier-dependent is the store account: the published application is yours whatever the licence says.
They share a playback path, an API surface and a design language, and diverge where the device demands it — a D-pad is not a touchscreen, and pretending otherwise produces a television app nobody can navigate.
Both are in development and neither has a public date on this page, because a date that slips is worse than no date. Discovery produces one against your actual launch plan.
Usually, and it is scoped like any other piece of work. What will not happen is a logo appearing on this page before the application exists.
Playback of an already-authorised session continues from your edge. Sign-in and catalogue browsing degrade, because those are control-plane operations by design — the split is deliberate and it is tested.
Tell us the device mix you see today and we will tell you what is shipping, what is in development, and what would have to be built.