Talk to us about your OTT platform project.
Tell us your target platforms, content model, and monetisation structure. We'll scope the build and give you a fixed cost.
Launching a streaming service on web and mobile but your content isn't on the living room TV where your audience actually wants to watch it?
Building connected TV apps but finding that each platform (Roku, Apple TV, Fire TV, Android TV) has completely different development requirements, SDKs, and certification processes?
Your content on the living room TV -- connected TV apps for Roku, Apple TV, Fire TV, and Android TV, backed by the subscription management, DRM, and video delivery infrastructure that a media business actually needs.
We build custom OTT platforms for media companies and content networks that need a first-class TV presence, not a workaround built on a third-party platform.
Native apps for Roku, Apple TV, Fire TV, and Android TV
DRM content protection across all platforms
SVOD, AVOD, and TVOD monetisation models
Video ingest, transcoding, and CDN delivery
An OTT platform gives media companies a direct presence on the living room TV -- Roku, Apple TV, Amazon Fire TV, Android TV, Samsung Tizen, and LG webOS -- with subscription management, DRM content protection, and ad-supported monetisation built in. RaftLabs builds custom OTT apps and the backend infrastructure that powers them, including video ingest, HLS/DASH delivery, and viewership analytics. Most OTT platform development builds deliver in 14 to 20 weeks at a fixed cost.
Web and mobile streaming are table stakes. Connected TV is where viewing hours are concentrated, and it is a fundamentally different engineering target. Roku uses BrightScript and SceneGraph. Apple TV runs tvOS with SwiftUI. Fire TV is Android under the hood but ships its own store and certification process. Android TV uses the Leanback library with Google's own submission requirements. Each platform has its own UI conventions, remote control navigation model, subscription API, and app store review team.
A media business that ignores connected TV is handing audience time to competitors who are already there. But treating OTT development as a single project -- rather than four separate platform engineering tracks with a shared backend -- is how budgets overrun and timelines slip.
We scope OTT builds as a platform engineering program: shared backend for video delivery, subscription management, and rights enforcement, with native apps built to the specification of each connected TV platform. The result is a TV presence that passes certification on the first or second submission and performs consistently across all four major platforms.
Roku SceneGraph and BrightScript development for channels that require custom UI beyond what Roku Direct Publisher offers -- content-heavy streaming services, live sports channels, and platforms with subscriber-authenticated catalogues that the Direct Publisher MRSS feed format cannot model. Grid and row layouts, detail pages with cast and episode data, full-text search with predictive results, and deep-link support for content marketing URLs are all built to Roku's 10-foot interface conventions and tested against the Roku channel certification checklist before submission.
HLS delivery is the standard streaming format for Roku -- content is transcoded to HLS with multiple bitrate renditions using AWS MediaConvert or an equivalent managed transcoding service, ensuring adaptive bitrate switching works correctly across Roku's range of hardware from lower-powered Roku Express to Roku Ultra. Roku Pay integration covers subscription billing, pay-per-view purchases, and trial periods with upgrade prompts at paywalled content points. Custom authentication flows handle platforms with existing subscriber accounts that do not use Roku's native in-channel purchase flow. Widevine is not available on Roku; content protection on Roku uses AES-128 HLS encryption, which is handled at the origin/CDN level. Submission to the Roku Channel Store includes certification guidance to avoid the most common rejection reasons: deep link failures, incorrect remote button handling, and missing closed caption support.
Native tvOS app built with SwiftUI for tvOS 16 and above targets, or UIKit for codebases that need to maintain compatibility with earlier OS versions. SwiftUI brings declarative navigation patterns that map cleanly to the Siri remote's directional swipe and click model, and its focus system integrates with tvOS's UIFocusEngine to handle focus state correctly across complex grid layouts -- the focus engine implementation is the most frequent source of App Store rejection for tvOS apps submitted to us after a first-submission failure.
FairPlay Streaming (FPS) DRM protects content on tvOS and all Apple platforms. CPIX key exchange between the content packager and the Apple FairPlay licence server is configured during the backend setup phase. Content is delivered via HLS with HEVC (H.265) as the preferred codec for tvOS, which supports HEVC natively for 4K HDR content at lower bitrates than H.264 at equivalent quality. Top shelf extension surfaces featured and recently watched content in the Apple TV home screen banner position when your app is selected -- a significant discovery surface that most third-party OTT apps do not implement. Apple TV+ subscription management uses StoreKit 2 so iOS and tvOS users share subscription entitlement without a separate login or re-purchase. Offline download with DRM licence expiry is available for tvOS where the device has sufficient storage, using FairPlay persistent licence grants. App Store submission and TestFlight distribution are managed by our team through the full review cycle.
Android-based development for both Fire TV and Android TV/Google TV using the Leanback library for TV-optimised navigation. Fire TV runs a forked Android OS and has its own Appstore submission process -- separate from Google Play -- with a Fire TV-specific certification checklist covering D-pad navigation, voice remote integration, and home screen launcher integration. Android TV/Google TV submits through Google Play's dedicated TV app review track, which applies different UI requirements from the standard Android phone review process. Both platforms can share the same core codebase with platform-specific configuration for the Appstore submission targets, reducing duplicate maintenance.
Widevine L1 or L3 DRM protects content on both platforms -- L1 for hardware-backed content protection where the SoC supports it, L3 for software-backed protection as fallback. Content is delivered via MPEG-DASH with HEVC or H.264 codec options, with AV1 available for platforms and devices that support AV1 hardware decoding. AWS Elemental MediaConvert transcodes source content to all required renditions and packages for DASH and HLS delivery with CPIX key exchange to the Widevine licence server. In-app purchases use Amazon In-App Purchasing API on Fire TV and Google Play Billing Library on Android TV. Alexa voice search on Fire TV and Google Assistant on Android TV make catalogue content discoverable by title and genre via voice command, not just remote navigation -- an important discovery channel for content-heavy libraries. Parental controls with PIN enforcement are built into the account settings flow on both platforms.
Multi-DRM implementation covers the three major DRM systems: Widevine for Android-based platforms (Fire TV, Android TV, Chrome browser), FairPlay Streaming for Apple platforms (tvOS, iOS, Safari on macOS), and PlayReady for Windows and Xbox applications. A single content asset is packaged once -- encrypted using the Common Encryption (CENC) standard with CPIX key exchange -- and delivered to all platforms, eliminating the need for separate content preparation pipelines per DRM system.
Multi-DRM licence server integration is handled through Axinom, Pallycon, or BuyDRM (all support CPIX and standard licence request/response formats). Token-based licence authentication verifies active subscription status before issuing a DRM licence -- a user whose subscription has lapsed or whose account is suspended receives a licence denial rather than being able to play protected content. The licence token is issued by the backend at the point of playback session initiation and carries a configurable expiry, so a long-running licence from a month ago cannot be reused. Offline download with DRM persistent licence grants and configurable licence expiry (typically 30 days from download, with a 48-hour playback window once started) is available for premium subscription tiers on mobile and tvOS where offline viewing is part of the product proposition. Geo-restriction is enforced at two points: the CDN edge using IP geolocation, and the licence server using the token claim, so geo-restricted content is blocked even if a user bypasses the CDN restriction. Content metadata uses schema.org VideoObject structured data markup so search engines and AI systems can index the catalogue correctly.
Subscription billing (SVOD) uses Stripe subscription management with configurable trial periods, plan tiers, and upgrade or downgrade logic. Plan changes take effect at the next billing cycle or immediately depending on your configured proration model. Stripe handles dunning for failed payments automatically, and subscription status is synced to the DRM licence token so access is revoked in near-real time when a subscription lapses rather than waiting for the next entitlement check.
Ad-supported free tier (AVOD) uses server-side ad insertion (SSAI) via VAST and VMAP ad tags. SSAI stitches ads into the video stream at the origin server before the manifest reaches the player, which means the player sees a single uninterrupted HLS or DASH stream and client-side ad blockers cannot distinguish ad segments from content segments. AWS MediaTailor handles personalised ad insertion at scale, pulling ads from your ad server using VAST 4.x ad tags and VMAP playlist templates for mid-roll break scheduling. Transactional purchase flows (TVOD) cover pay-per-view events and rental windows with configurable viewing periods (24-hour, 48-hour, 30-day) enforced by the DRM licence expiry. Chromecast support uses the Cast SDK so users can throw content from a mobile or web session to a Chromecast or Chromecast built-in TV. Samsung Tizen and LG webOS apps are available as additional platform targets using React TV development patterns, extending coverage to smart TVs that do not run Android TV. Content metadata structured with schema.org VideoObject markup makes catalogue titles indexable by search engines and AI assistants for SEO and AEO discovery.
Content ingest pipeline accepts uploads from your media asset management system, direct S3 transfer, or a CMS upload interface. AWS Elemental MediaConvert handles cloud transcoding to both HLS and MPEG-DASH output formats, with codec profiles selected per platform target: H.264 (AVC) as the universal baseline, HEVC (H.265) for 4K HDR delivery on Apple TV and high-end Android TV devices, and AV1 for platforms that support hardware AV1 decoding to reduce CDN bandwidth cost at equivalent quality. Multiple quality renditions (240p through 4K where source resolution permits) enable adaptive bitrate (ABR) streaming so the player selects the highest quality the connection can sustain in real time.
Thumbnail sprite generation creates the preview strip that appears when a viewer scrubs through a video timeline -- a standard expectation for premium streaming services that requires explicit pipeline configuration rather than being automatic in most transcoding services. CDN delivery uses Cloudflare or Fastly with origin shield configuration so the transcoded assets are cached at the CDN edge closest to each viewer. Origin shield reduces origin egress cost by serving cache hits from a regional PoP rather than pulling from S3 on every cache miss in a new geography. Fastly's configurable cache control and instant purge capability is used for content that needs to be removed from CDN caches immediately (rights expiry, take-down requests). Viewership analytics via Mux Data captures play starts, buffering ratio, bitrate switches, and watch-through rate at the segment level per episode, per platform, and per geographic region -- the data the content and engineering teams need to understand both performance issues and audience engagement patterns.
Frequently asked questions
Roku, Apple TV (tvOS), Amazon Fire TV, and Android TV/Google TV are the four platforms that cover the majority of connected TV viewers in North America and Europe. Each requires a separate native app because they run different operating systems, use different SDKs and DRM systems, and have separate app stores with their own certification processes and review teams. There is no cross-platform framework that produces production-quality apps for all four from a single codebase -- attempts to use React Native or Flutter for connected TV typically fail certification or produce UX that does not meet the platform's 10-foot interface requirements.
Samsung Tizen and LG webOS add smart TV coverage for households that use the TV's built-in operating system rather than an HDMI-connected streaming device. These platforms use web-based development (Tizen uses a web app model; webOS uses React TV patterns) and have their own store submission processes. Chromecast support via the Cast SDK allows mobile and web users to cast to any Chromecast or Chromecast built-in TV without a separate app submission. A practical approach for most launches is to ship Roku, Fire TV, and Apple TV in the first phase -- those three platforms cover approximately 70 to 80 percent of connected TV device households in the US market -- and add Android TV, Samsung Tizen, and LG webOS in a subsequent phase. The shared backend (transcoding, DRM, subscription management) is built once and reused across all phases, so adding a platform later is a front-end engineering project rather than a full rebuild.
DRM (Digital Rights Management) is the content protection layer that prevents unauthorised copying or redistribution of protected video streams. The three major DRM systems are Widevine (Google, used on Android-based platforms including Fire TV, Android TV, and Chrome browser), FairPlay Streaming (Apple, used on tvOS, iOS, and Safari), and PlayReady (Microsoft, used on Windows and Xbox). Each platform supports its own DRM system and will not accept another -- you cannot use Widevine on tvOS or FairPlay on Fire TV.
Whether DRM is required depends on your content rights. Licensed content from studios, sports rights holders, or distributors almost always carries a contractual requirement for DRM as a condition of the licence. Original content you own outright does not have a contractual DRM obligation, but DRM is still worth implementing if you are selling subscriptions or TVOD purchases -- without it, someone can capture the stream and redistribute it, which directly undermines the content you are monetising. DRM also enables offline download with licence expiry, which is a feature expectation for premium subscription tiers.
A multi-DRM implementation using CPIX key exchange packages a single content asset once and delivers it across all platforms without maintaining separate encrypted asset files per DRM system. The licence server (Axinom, Pallycon, or BuyDRM) handles licence issuance per platform. The incremental engineering cost of multi-DRM over single-DRM is small and is almost always worth doing if you are building for more than one platform.
A three-platform OTT launch targeting Roku, Apple TV, and Fire TV, with a shared backend for video delivery, subscription management, and DRM, typically delivers in 14 to 20 weeks. The timeline depends on the complexity of your subscription model, whether live streaming is included, and how much of the backend infrastructure already exists. Each platform has its own certification timeline after submission -- Roku typically takes 1 to 2 weeks, Apple App Store review is 1 to 3 days, and Amazon Appstore is 3 to 5 days. We build certification preparation into the project timeline so these review windows do not come as a surprise at the end of development.
OTT platform development cost depends on the number of platforms targeted, the complexity of the subscription and monetisation model, whether live streaming is included, and how much backend infrastructure exists. A three-platform build (Roku, Apple TV, Fire TV) with a shared backend, subscription billing, and DRM is typically scoped as a fixed-cost project. We provide a detailed breakdown after a scoping call where we understand your content model, audience size, and monetisation structure. Visit our pricing page or contact us to start a scoping conversation.
What clients say
Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.

I was pleased with RaftLabs team quality, consistency and execution.
01 / 02
Tell us your target platforms, content model, and monetisation structure. We'll scope the build and give you a fixed cost.