Why this matters

For a media or entertainment service chasing a U.S. audience, the living room is won on three devices — Roku, Fire TV, and Apple TV — and the two covered here, Apple TV and Fire TV, are the ones that overlap most with the mobile apps a team has often already built. A founder, product manager, or streaming CTO who assumes "we have iOS and Android, so the TV apps are basically free" will be partly right and partly, expensively, wrong: tvOS reuses much of the Apple toolchain and Fire OS reuses much of Android, but the remote-driven interface, the app-store rules, the device certification, and — as of late 2025 — Amazon's new Vega OS each add real work. This article maps what carries over and what does not, so you can scope two TV builds, judge a vendor's estimate, and price the store commission into the business model from day one. It is the streaming-box companion to the OTT client matrix, which maps every screen you must cover, and a sibling to iOS and Android playback, Roku development, and smart TV apps: Tizen and webOS.

Two living rooms, two ecosystems

Lead with the reach, because reach is why both devices are on your list. After Roku — the U.S. leader at roughly 38% of connected-TV device share in early 2025 — come the two platforms in this article. Independent measurement (Pixalate, Q1 2025, U.S.) put Amazon Fire TV at about 18% and Apple TV at about 13% of connected-TV device share, ahead of Samsung (~12%) and LG (~5%). Amazon has said it has shipped more than 250 million Fire TV devices worldwide as of November 2024, the bulk of them inexpensive streaming sticks. Apple does not break out Apple TV unit sales, but the box reaches a smaller, higher-spending audience and plugs into an ecosystem of 2.3-billion-plus active Apple devices. Between them, the two platforms cover a large share of every U.S. living room that is not already on Roku.

Now the part that decides your budget. Unlike Roku — which is its own closed world with a proprietary language — Apple TV and Fire TV each sit close to an ecosystem your mobile team may already know. A tvOS app is built with the same language and frameworks as an iPhone app. A Fire TV app, on the older operating system, is an Android app. That overlap is real and it saves money — but "close to" is not "the same as," and the gaps are exactly where teams under-budget.

Apple TV and Fire TV as the #2 and #3 U.S. living-room platforms, each close to a mobile ecosystem the team may already know. Figure 1. The two living-room targets after Roku. tvOS rhymes with iOS; Fire OS is Android; the new Vega OS is neither. Device-share figures: Pixalate, U.S., Q1 2025.

Apple TV: tvOS is the iOS stack on the big screen

Start with Apple TV, because it is the more predictable of the two. Apple's TV operating system, tvOS, shares its foundations with iOS. You build the app in Swift, lay out the interface in SwiftUI (Apple's modern user-interface framework and, since tvOS 18, the recommended toolkit for TV apps) or the older UIKit, and play video through AVKit and AVPlayer — the same media engine an iPhone app uses. A senior iOS engineer is already most of the way to a tvOS engineer. The business logic, the networking, the data models, and the playback code can be shared with the iPhone and iPad apps to a degree that simply is not possible on Roku.

What does not carry over is the interface paradigm. A TV has no touchscreen; the viewer drives everything with a remote from across the room. tvOS apps are built around a focus engine — the system that moves a highlight from tile to tile as the viewer swipes and clicks — and around the "10-foot user interface," where text and tap targets are sized for a couch, not a hand. You also design a Top Shelf, the wide banner that Apple shows above your icon on the home screen. None of that exists on iPhone, so the user-interface layer is a genuine rebuild even when the engine underneath is shared.

One historical shortcut is closing. Apple used to offer TVMLKit — a lightweight way to build a media app from Apple-hosted templates described in XML and driven by JavaScript, so a simple catalogue app needed very little native code. Apple is now deprecating TVMLKit and, at its 2024 developer conference, told teams to migrate those template apps to SwiftUI. Treat TVMLKit as legacy: new tvOS apps should be native. Apple also tightened the toolchain — since April 2025, App Store Connect requires tvOS apps to be built with the tvOS 18 software-development-kit (SDK) and Xcode 16 or later — so plan around current tools.

Distribution and money follow the rest of Apple's platforms. A tvOS app ships through the App Store via App Store Connect, passes the same App Review process as an iPhone app, and — when it sells digital goods such as subscriptions — must use Apple's In-App Purchase system. We return to what that costs below.

FairPlay, HLS, and the cbcs rule on Apple TV

Premium content needs a lock that stops a paying viewer's device from copying it, called digital rights management (DRM). On Apple TV that lock is Apple's own system, FairPlay Streaming, and the way it is wired has two hard constraints worth knowing before you package a single file.

First, Apple devices play only HTTP Live Streaming (HLS) — the Apple-created delivery format standardized as IETF RFC 8216. AVPlayer does not natively play MPEG-DASH (the ISO delivery format, ISO/IEC 23009-1) that much of the rest of the industry uses. So whatever else your platform delivers, it must produce an HLS version for Apple TV. Second, FairPlay accepts only one of the two encryption "schemes" defined by Common Encryption (ISO/IEC 23001-7): the cbcs scheme (AES in cipher-block-chaining mode with a pattern), never the older cenc (AES counter mode) scheme. A common listicle error is to write "FairPlay uses Common Encryption" without naming the scheme; the precise statement is "FairPlay requires the cbcs scheme of Common Encryption." Your app requests the decryption keys at runtime through Apple's AVContentKeySession and your license server hands them back — there is no DASH path and no cenc path to FairPlay. The full mechanics of the two schemes are in CENC, CTR, and CBCS: common encryption explained, and the three DRM systems in Widevine, PlayReady, FairPlay.

The happy consequence, which we develop in the DRM table below, is that the modern "cbcs everywhere" convergence makes Apple TV cooperate with the other platforms rather than forcing a separate encode — you encrypt once and serve FairPlay over HLS to the Apple devices.

Fire TV is now two different computers

Here is the development that breaks every "how to build a Fire TV app" guide written before 2025: Fire TV now runs on two different operating systems, and which one a device uses changes the entire build.

For more than a decade, Fire OS has been Amazon's TV operating system, and it is a customized version of Android (built on the Android Open Source Project). The practical effect is the headline reuse story of this article: a Fire OS app is an Android app. You build it with the Android SDK in Kotlin or Java, play video with ExoPlayer / Media3 (Amazon maintains its own port of ExoPlayer tuned for Fire TV), and protect it with Google's Widevine DRM through Android's native media system — Fire TV supports Widevine L1, the hardware-backed security level studios require for high-definition content, on capable devices. A team that already ships an Android phone app or an Android TV app reuses a large share of it on Fire OS. FairPlay never appears: like on Roku and the smart TVs, FairPlay is confined to Apple hardware.

Then, in late 2025, Amazon began shipping Fire TV devices on an entirely new operating system called Vega OS. Vega OS is Linux-based, not Android. Apps are written in React Native (running on the Hermes JavaScript engine) or as web apps, using Amazon's Vega Developer Tools (the SDK formerly code-named "Kepler"). The first device on it was the Fire TV Stick 4K Select, followed by the Fire TV Stick HD; Amazon describes itself as a "multi-OS company," so Fire OS continues on many devices while new low-end sticks move to Vega. Two consequences matter for a streaming team. First, Vega OS blocks sideloading and locks installation to the Amazon Appstore, so the loose "just sideload the APK" testing habit from Fire OS is gone. Second, and more surprising, Vega OS does not use Android's media APIs at all — it plays video through the W3C web media stack: HTMLMediaElement, Media Source Extensions (MSE) for adaptive streaming, and Encrypted Media Extensions (EME) for DRM. Through EME, Vega OS supports Widevine (L1) and PlayReady (SL3000) by setting a drm_scheme and a license-server URL — the same browser-style wiring used on the web and on smart TVs, not the Android MediaDrm wiring used on Fire OS.

So the Android-code reuse that makes Fire OS cheap does not transfer to Vega OS. A Vega app is closer to your web player than to your Fire OS app. For now, treat Fire TV as two targets and check your device matrix: a 250-million-device installed base is overwhelmingly Fire OS today, but new entry-level hardware is Vega, and the split will grow. This is exactly the kind of dated, vendor-specific change — like the PlayReady-on-Samsung 2026 migration on the smart-TV side — that has to be re-verified against the vendor's docs before each build.

Fire TV split into Fire OS (Android, ExoPlayer, Widevine) and the new Vega OS (Linux, React Native, W3C MSE and EME). Figure 2. Fire TV is now two computers. Fire OS is Android and reuses your Android app; Vega OS is Linux with React Native and the W3C EME stack — closer to your web player.

The DRM wiring differs on every stack

Put the three stacks side by side and a pattern appears that is more useful than any single platform fact: the DRM system and the way it is wired are different on all three, even though the underlying standards are shared. The table below is the one to keep.

Platform OS base App stack Player engine DRM system DRM wiring Delivery format
Apple TV (tvOS) Apple tvOS Swift / SwiftUI AVKit / AVPlayer FairPlay (✅) AVContentKeySession (native) HLS only
Fire TV — Fire OS Android (AOSP) Kotlin / Java ExoPlayer / Media3 Widevine L1 (✅), PlayReady (some) Android MediaDrm (native) HLS or DASH
Fire TV — Vega OS Linux React Native / web W3C HTMLMediaElement + MSE Widevine L1 (✅), PlayReady SL3000 (✅) W3C EME (browser-style) HLS or DASH (via MSE)

Read the "DRM wiring" column carefully, because it is where teams lose time. Apple wants keys requested through AVContentKeySession; Fire OS wants them through Android's MediaDrm; Vega OS wants them through W3C EME — the same standard your website uses. Three platforms, three integration surfaces, even where the DRM system (Widevine) is literally the same on two of them.

Now the unifying move that keeps this from becoming three separate encodes. Because FairPlay requires cbcs and modern Widevine and PlayReady both accept cbcs, you can encrypt the content once with the cbcs scheme of Common Encryption (ISO/IEC 23001-7), package it once as CMAF (the common media format), and then signal it in HLS for the Apple devices and in HLS or DASH for the rest. One set of encrypted files, three DRM licenses issued from it. That is the "encrypt once, license many" pattern, and it is the whole reason a multi-platform catalogue does not need a separate master per device. The end-to-end version of this is the anchor article multi-DRM: one workflow, every device, and the packaging step itself is in packaging: CMAF, HLS, and DASH from one mezzanine. One layer still sits outside the software on both platforms: High-bandwidth Digital Content Protection (HDCP) guards the video on the HDMI cable to the panel, and studios require HDCP 2.2 for 4K — DRM protects the stream and the keys, HDCP protects the last hop, and neither stops a camera pointed at the screen.

Comparison of DRM wiring across tvOS, Fire OS, and Vega OS, with the encrypt-once-with-cbcs packaging conclusion. Figure 3. Same standards, three integration surfaces. FairPlay on HLS via AVContentKeySession; Widevine on Fire OS via MediaDrm; Widevine/PlayReady on Vega via W3C EME. Encrypt once with cbcs, signal HLS and DASH.

The store tax: Apple's IAP versus Amazon's IAP

Both platforms make you sell through their billing system and both take a cut, so the store commission belongs in your pricing model before the first sprint — not as a surprise at launch. The systems are similar in shape and different in the numbers.

On Apple TV, digital goods such as subscriptions must use Apple In-App Purchase. The standard commission is 30%, but Apple's Small Business Program drops it to 15% for developers who earned under $1 million in proceeds in the prior calendar year — which covers most startups. Outside that program, auto-renewing subscriptions are charged 30% in the first year and 15% from the second year onward for a subscriber who stays continuously subscribed.

On Fire TV, digital goods use Amazon In-App Purchasing. The standard cut is also 30%, and Amazon's Small Business Accelerator Program lowers it to 20% for developers under $1 million in prior-year Appstore revenue — and adds AWS promotional credits worth 10% of your app revenue on top, which offset cloud bills rather than landing as cash.

Walk the arithmetic out loud on a $9.99 monthly subscription, because the gap is real money at scale. Under Apple's Small Business Program at 15%, Apple keeps $9.99 × 0.15 = $1.50, leaving you $8.49. Under Amazon's program at 20%, Amazon keeps $9.99 × 0.20 = $2.00 in cash, leaving you $7.99, plus about $1.00 in AWS credits you can spend on infrastructure. Now scale to 100,000 paying subscribers: gross is $999,000 a month. Apple's 15% is about $150,000 a month (~$1.8M a year); Amazon's 20% is about $200,000 a month in cash (~$2.4M a year), softened by roughly $100,000 a month in AWS credits. The platforms are within a few points of each other, but at scale a few points is millions — model both, per platform, in your subscriber economics. How this fits the wider revenue picture is in subscription billing and entitlement and the OTT monetization map.

Store-commission comparison: Apple In-App Purchase at 15–30% versus Amazon at 20–30% plus 10% AWS credits, on a $9.99 sub. Figure 4. The store tax on a $9.99 subscription. Apple 15% under the Small Business Program; Amazon 20% plus 10% AWS credits under its Small Business Accelerator. Both forbid an outside paywall for digital goods.

Common mistake — the five that blow a TV-app budget. First, treating both TV apps as "free" because you have iOS and Android; the engines reuse, but the 10-foot interface, store rules, and certification do not. Second, assuming "Fire TV = Android"; new Vega OS devices are Linux with React Native and the W3C EME stack, so the Android reuse does not transfer. Third, packaging only DASH and forgetting Apple TV plays HLS only — you need an HLS rendition with cbcs FairPlay. Fourth, leaving the store commission out of the model; Apple takes 15–30% and Amazon 20–30% before you see revenue. Fifth, planning to sideload for Vega OS testing or to route payments to your own web checkout for digital goods — Vega blocks sideloading and both stores require their own In-App Purchase.

Where Fora Soft fits in

Covering the U.S. living room is not one screen but several, and the scale problem on Apple TV and Fire TV is keeping the reuse without tripping over the gaps: a shared player core where tvOS rhymes with iOS and Fire OS rhymes with Android, a separate 10-foot interface and certification path for each, three different DRM integration surfaces, and now Amazon's new Vega OS that throws out the Android reuse entirely. Fora Soft has built video streaming, OTT/Internet TV, e-learning, and telemedicine applications since 2005 — 625+ projects for 400+ clients across 20+ years — so these realities (FairPlay-over-HLS on tvOS, Widevine-over-DASH on Fire OS, the W3C EME stack on Vega, and "encrypt once with cbcs" so one packaging serves them all) are the day-to-day of our streaming work. We are vendor-neutral: we translate each platform's rules into a build rather than reselling a single SDK, and we scope the device matrix so Apple TV and Fire TV earn their place beside the web, mobile, and Roku apps instead of doubling maintenance by surprise.

What to read next

Call to action

References

  1. HTTP Live Streaming (HLS) — IETF RFC 8216. IETF, 2017. The Apple-created delivery format that is the only protocol Apple devices play; the controlling source for HLS. Tier 1. https://www.rfc-editor.org/rfc/rfc8216
  2. Common Encryption (CENC) — ISO/IEC 23001-7 (3rd edition, 2023). ISO/IEC. Defines the cenc (AES-CTR) and cbcs (AES-CBC pattern) schemes; FairPlay requires cbcs. The basis of the "encrypt once" packaging decision. Tier 1. https://www.iso.org/standard/84637.html
  3. Dynamic adaptive streaming over HTTP (MPEG-DASH) — ISO/IEC 23009-1. ISO/IEC. The ISO delivery format Apple devices do not natively play, but Fire OS and Vega OS do. Tier 1. https://www.iso.org/standard/83314.html
  4. Encrypted Media Extensions (EME). W3C Recommendation, 18 September 2017. The browser DRM standard used by Vega OS (and the web/smart TVs) — and notably how Vega wires Widevine/PlayReady, unlike Fire OS's native MediaDrm. Tier 1. https://www.w3.org/TR/encrypted-media/
  5. Media Source Extensions (MSE). W3C Recommendation, 17 November 2016. The adaptive-streaming API underlying Vega OS playback. Tier 1. https://www.w3.org/TR/media-source/
  6. tvOS — Apple Developer. Apple. The tvOS frameworks (Swift, SwiftUI, UIKit, AVKit/AVPlayer), the focus engine, and Top Shelf; SwiftUI as the recommended toolkit for tvOS 18. Tier 3 (first-party), fetched 2026-06-17. https://developer.apple.com/tvos/
  7. Migrate your TVML app to SwiftUI — WWDC24, Apple Developer. Apple, 2024. The deprecation of TVMLKit and the guidance to migrate template apps to SwiftUI. Tier 3 (first-party). https://developer.apple.com/videos/play/wwdc2024/10207/
  8. App Store Small Business Program — Apple Developer. Apple. The 15% reduced commission for developers under $1M in prior-year proceeds, and the standard 30% / second-year 15% subscription rates. Tier 3 (first-party), fetched 2026-06-17. https://developer.apple.com/app-store/small-business-program/
  9. Media Player and W3C Media API — Vega Developer Docs (v0.22). Amazon. Vega OS playback via HTMLMediaElement, MSE, and EME; the drm_scheme values for Widevine (L1) and PlayReady (SL3000); React Native/Hermes app model. Tier 3 (first-party), fetched 2026-06-17. https://developer.amazon.com/docs/vega/0.22/media-player.html
  10. Fire TV developer FAQ and ExoPlayer port — Amazon Developer Docs. Amazon. Fire OS as Android-based, the Amazon port of ExoPlayer, and Widevine (incl. L1) support on Fire TV. Tier 3 (first-party), fetched 2026-06-17. https://developer.amazon.com/docs/fire-tv/faq-general.html
  11. Amazon Appstore Small Business Accelerator Program — Amazon Developer Docs. Amazon. The 80/20 revenue share plus 10% AWS promotional credits for developers under $1M in prior-year Appstore revenue. Tier 3 (first-party). https://developer.amazon.com/docs/reports-promo/small-business-accelerator.html
  12. Amazon launches Vega OS for Fire TV. Dolby OptiView (orientation) and Amazon developer blog. The late-2025 Vega OS launch (Fire TV Stick 4K Select, then Stick HD), Linux base, React Native, no sideloading, "multi-OS" stance. Tier 5 (industry / vendor PR) — re-verify against Amazon docs. https://optiview.dolby.com/resources/blog/playback/amazon-launches-vega-os-for-fire-tv/
  13. Pixalate Q1 2025 Connected TV (CTV) Device Market Share Report (U.S.). Pixalate. U.S. device share: Roku 38%, Fire TV 18%, Apple TV 13%, Samsung 12%, LG 5%. Orientation figures; re-baseline per review. Tier 5 (industry). https://www.pixalate.com/blog/q1-2025-connected-tv-ctv-device-market-share-report
  14. Amazon passes 250 million Fire TV devices shipped. TV Tech / TVNewsCheck, November 2024. The 250M+ shipped milestone. Tier 5 (industry / vendor PR). https://www.tvtechnology.com/news/amazon-passes-250-million-fire-devices-sold-expands-fire-tv-lineup

Where sources disagreed, the official spec or first-party doc was followed. The widespread listicle claim that "Fire TV is an Android platform" was overridden by Amazon's own Vega developer docs, which describe a Linux-based, React Native, W3C-EME stack on new devices — so Fire TV is now two platforms, not one. The common shorthand "FairPlay uses Common Encryption" was sharpened to "FairPlay requires the cbcs scheme of Common Encryption (ISO/IEC 23001-7)," and the claim that AVPlayer plays DASH was overridden by Apple's HLS-only reality.