DEV Community: Sajid Ali

Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork

Sajid Ali — Thu, 17 Sep 2026 13:46:13 +0000

This series: Compose Multiplatform on tvOS

My Journey Making Compose Multiplatform Work on tvOS, and What I Learned
Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork (this post)
Rendering (coming soon)
Siri Remote input (coming soon)
Siri Remote trackpad (coming soon)
Screen density and text input (coming soon)
Porting tv-material (coming soon)
The Gradle plugin and third-party libraries (coming soon)
Maintaining the fork (coming soon)
Building a real app on it (coming soon)

Part 1 was why this fork exists. This one is the build layer, and it comes before any Compose code, because in Kotlin Multiplatform a target is not a flag you flip at the end. It decides which source sets compile, which dependencies resolve, which klibs get published, which linker flags get passed. Until the build knows about tvosArm64, nothing tells you what is missing.

So the first commits were build files. Once the targets were on, the compiler listed what was missing, module by module, and I worked through that list.

Source set layout on the tvos branch

I started on a branch called tvos, based on upstream. Back then JetBrains called iOS "uikit" in this repository and the source set was uikitMain. Because tvOS is also UIKit underneath, it made sense to have a common source parent for both iOS and tvOS. But iOS was already being called uikit, so I chose uiKitCommonMain as the source set name and moved all the UIKit files there, keeping only the iOS specific files in uikitMain and putting the tvOS specific files in a new source set, tvosMain.

The problem with this approach was how to keep up with upstream. I tried a symlink to the uikit source set, and then overriding the tvOS files in a separate target. The override worked but complicated the process. At that time my goal was to make it runnable on tvOS however possible, so we would have a proof of concept. So I did a lot of hacks in the tvos branch to make it runnable, and after about a week it ran on an Apple TV.

It was only after JetBrains renamed uikit to ios that I created a new main branch, tvos-main, to track upstream jb-main. The rename came in two commits: on 5 December 2025 the Uikit* targets were removed in favour of Ios* (602b39cc, #2545), and six days later uikitMain became iosMain and every shared file got the .ios.kt suffix (9fe1485e, #2639). On tvos-main I renamed uiKitCommonMain to uiKitMain, as the name was now available (4b6896f2). tvosMain had come in a few days earlier with the Siri Remote input work (e57f35df).

The uiKitMain layer on tvos-main

This is the layout on tvos-main today. There is no central declaration of it anywhere, each relevant module creates it in its own build file:

// compose/ui/ui/build-fork.gradle
uiKitMain {
    dependsOn(nativeMain)
    dependencies {
        implementation(project(":compose:ui:ui-uikit"))
    }
}

iosMain {
    dependsOn(uiKitMain)
}

tvosMain {
    dependsOn(uiKitMain)
}

uiKitMain sits between nativeMain and the two platform source sets. Anything that is plain UIKit lives there once and both platforms get it. iosMain keeps what only iOS has: hover, drag and drop, the inline keyboard, the text loupe. tvosMain keeps what only tvOS has: the Siri Remote, the focus engine bridge, the full screen keyboard, the density rule. compose/foundation/foundation/build-fork.gradle has the same shape.

The alternative was a tvosMain that copies the iOS implementation. That builds just as well on day one, but every upstream fix to the iOS rendering path would then have to be applied twice, by hand, forever. With uiKitMain, an upstream change to shared UIKit code lands once and tvOS gets it too. Maintenance cost scales with how much code sits in tvosMain, so keeping that source set small is the main design constraint.

This has already paid off on a rebase. On 25 August 2026, 91ff7dde, upstream's later UIKit* to Ios* class and file renames came through as a three way merge over the 20 renamed files the fork shares through uiKitMain, and needed no further work.

What upstream already had

compose-multiplatform-core is AndroidX with JetBrains' multiplatform work on top, and it has its own idea of a platform, separate from Kotlin's. A ComposePlatforms enum drives policy: which platforms get Skiko, which get published together, which count as Darwin.

tvOS was already in there, and it had been for years. Nikolai Rykunov added the TvosArm64, TvosX64 and TvosSimulatorArm64 entries on 18 April 2023 in d4b2366b. Ivan Matkov grouped them into the TV_OS set on 18 April 2024 in 98eb0146:

// buildSrc-fork/public/src/main/kotlin/org/jetbrains/androidx/build/ComposePlatforms.kt
TvosArm64("TvOs"),
TvosSimulatorArm64("TvOs"),
...
val TV_OS = EnumSet.of(TvosArm64, TvosSimulatorArm64)
...
val DARWIN = IOS + WATCH_OS + TV_OS + MACOS_NATIVE

DARWIN already included TV_OS, so tvOS already counted as an Apple platform. The tvos(), tvosArm64() and tvosSimulatorArm64() DSL functions, the ones a module calls to register its targets, came down from AndroidX in June 2024, 01549107. All of that predates the fork.

Around forty leaf modules already call tvos() upstream: annotation, collection, kruth, the compose/runtime group, every lifecycle module, navigation, navigation3, navigationevent, room3, savedstate, window/window-core, the testutils modules. graphics/graphics-shapes spells out tvosArm64() and tvosSimulatorArm64() instead of the shorthand. Those klibs were being built and published for tvOS before I touched anything.

No UI module declared a tvOS target, and none could have, because upstream's SKIKO_SUPPORT reads EnumSet.of(KotlinMultiplatform) + JVM_BASED + IOS + MACOS_NATIVE + WEB, with no TV_OS in it. That omission is what kept ui, foundation, material and every other Skiko backed module off tvOS.

So the fork's change in the build logic is one line: SKIKO_SUPPORT gets + TV_OS, so the build expects Skiko binaries for tvOS, which only works because Skiko already publishes them. A second line in JetBrainsPublication.kt puts ComposePlatforms.TV_OS next to iOS in the supported platform list for ui-uikit, so the artifacts get published instead of built and thrown away. Everything else is tvos() calls in each module's build file, sitting next to ios().

buildSrc and buildSrc-fork

I got the targets wired up in April 2026 and put those build logic edits in buildSrc/, because that was the only copy of the build logic in the repository at the time.

On 29 June 2026, a702a011, upstream split it. buildSrc-fork/ appears as a copy of buildSrc/, and buildSrc/settings.gradle now redirects :private, :public, :plugins and :tests over there whenever PROJECT_MODE is not AOSP, which is the default. So buildSrc-fork is the copy that actually compiles, and buildSrc is what you get in AOSP mode. The naming points the wrong way.

I wired the tvOS targets into the build-fork.gradle files on 1 July, f8281d7b, and mirrored the publishing edits into buildSrc-fork/ on 16 July, 93d12136. One change did not get mirrored: the isIOS to isUIKit widening in AndroidXForkTargetsExtensions.kt, which adds the UIKit linker frameworks for tvOS targets. It has been dead code in the default build ever since. Nothing broke, because those are library targets with no final binaries to link, so the flags have nothing to attach to yet. The repository keeps two copies of its build logic, so every edit there is two edits, and a missed mirror does not fail the build.

build-fork.gradle

The file name in the snippets above is build-fork.gradle, not build.gradle. That mechanism was already in the repository. The checkout builds in one of two modes, fork mode is the default, and in fork mode every included project picks its build file from a priority list:

// settings-fork.gradle
project.buildFileName = ["build-fork.gradle.kts", "build-fork.gradle", "build.gradle.kts", "build.gradle"]
        .find {
            new File(project.projectDir, it).isFile()
        }

If a module has a build-fork.gradle, Gradle uses it and ignores build.gradle entirely. If it does not, nothing changes. There are 67 of these in the repository now, across compose/*, lifecycle/*, navigation/*, tv/tv-material, window/window-core and others.

This matters for a fork that has to rebase. The upstream build.gradle files stay byte identical to what AOSP and JetBrains ship. When upstream changes a build file, the rebase applies it with no conflict, because I never touched that file, and my changes are in a sibling file that does not exist upstream. Most of the tvos() calls and all of the uiKitMain wiring live in files that structurally cannot conflict.

Three modules are the exception. They register their tvOS targets straight into the plain build.gradle with no fork sibling to hide in: compose/ui/ui-uikit, compose/ui/ui-backhandler and compose/ui/ui-skiko. In ui-uikit that is unavoidable, the Xcode wiring is in that file and there is nowhere else to put it. Those three are the files I check on every rebase, because they are where upstream and I edit the same lines.

ui-uikit: SDKs, destinations and the generated .def

compose:ui:ui-uikit is the small Objective-C and Swift helper library I described at the end of Part 1, the one Compose calls through cinterop. Its build file is the main place where Gradle talks to Xcode directly, and it was written assuming iPhone.

Everything routes through one private configure function, so adding tvOS meant giving it a platform parameter with a default and passing it from the two new targets:

// compose/ui/ui-uikit/build.gradle
tvosArm64("tvosArm64") {
    configure(it, true, "arm64", null /*"tvosArm64Test"*/, "tvOS")
}
tvosSimulatorArm64("tvosSimulatorArm64") {
    configure(it, false, "arm64", "tvosSimulatorArm64Test", "tvOS")
}

Inside, that platform string picks the SDK name prefix and the xcodebuild destination:

// compose/ui/ui-uikit/build.gradle
private def configure(target, isDevice, architecture, testTarget, platform = "iOS") {
    if (!isMacHost()) return
    def sdkPrefix = (platform == "tvOS") ? "appletv" : "iphone"
    def sdkName = isDevice ? "${sdkPrefix}os" : "${sdkPrefix}simulator"
    def destination = isDevice ? "generic/platform=${platform}" : "generic/platform=${platform} Simulator"

That gives you appletvos, appletvsimulator and generic/platform=tvOS Simulator. One more place hardcoded iPhone, the device name pattern the test task matches when it lists simulators, so that becomes Apple TV on tvOS and stays iPhone 1[567] otherwise.

Those configure calls pass the test target name as the fourth argument. The simulator target passes one, and the device target passes null /*"tvosArm64Test"*/, which follows the pattern iOS already had, null /*"iosArm64Test"*/. Device tests are not wired up for either platform in this module. Simulator tests run, device builds compile and link, and that is how far verification goes here.

The linker options at the end of the file needed the same kind of parameterization. Kotlin's cinterop lets you pass linker options, but it only keeps them if they arrive from a .def file, and options passed any other way never reach the link step. Swift compatibility libraries live under the selected Xcode toolchain in a directory named after the SDK, so the path differs between appletvos and appletvsimulator. The build generates a .def per target:

// compose/ui/ui-uikit/build.gradle
def swiftToolchainLibPath = new File(swiftToolchainDir, "usr/lib/swift/${sdkName}")
def swiftLinkerOpts = [
        "-ObjC",
        "-L${swiftToolchainLibPath}",

This needed no tvOS specific code. It is keyed off sdkName, which was already a variable, so parameterizing the SDK name at the top of the file was enough.

The pbxproj

The helper library is a real Xcode project, so it has a project.pbxproj, and two settings in there decide whether tvOS is buildable at all. SUPPORTED_PLATFORMS has to list the tvOS SDKs, and TARGETED_DEVICE_FAMILY has to include 3, which is Apple TV, next to 1 and 2 for iPhone and iPad:

// compose/ui/ui-uikit/src/iosMain/objc/CMPUIKitUtils/CMPUIKitUtils.xcodeproj/project.pbxproj
SUPPORTED_PLATFORMS = "appletvos appletvsimulator iphoneos iphonesimulator";
TARGETED_DEVICE_FAMILY = "1,2,3";

These settings are per build configuration. There are ten configurations in that file, across four targets plus the project itself. I set SUPPORTED_PLATFORMS on the two project level ones so everything inherits the tvOS SDKs. I set TARGETED_DEVICE_FAMILY = "1,2,3" on six configurations. Two still read "1,2": the Debug and Release pair for the CMPUIKitSwiftUtils target.

That target is on the tvOS build path. configureSwiftUtils runs for every configure() call, tvOS included, so both tvOS targets archive it with xcodebuild -sdk appletvos or appletvsimulator. It builds because SUPPORTED_PLATFORMS is inherited from the project and does list the tvOS SDKs, and because the product is a static library archived with MACH_O_TYPE=staticlib, which is not something you install on a device, so nothing ever checks the device family. It is still wrong and it is an open item on my list. If Apple tightens that check, or if the target stops being a static library, it breaks.

Xcode's UI does not show when a setting is present on some configurations and not others, and pbxproj is not a format you read carefully by eye. I checked these by grepping for the setting name and comparing the number of hits against the number of configurations.

Resources: decoding the SDK name

The second repository is compose-multiplatform, home of the Compose Gradle plugin. For tvOS it needed one thing: resources.

When an Apple app builds, a Gradle task runs as an Xcode build phase and copies the Compose resources into the app bundle. It has to know which Kotlin target it is packaging for, and all it gets is Xcode's environment: a platform name and a list of architectures. So the plugin decodes them:

// gradle-plugins/compose/src/main/kotlin/org/jetbrains/compose/resources/IosResourcesTasks.kt
platform.startsWith("appletvos") -> {
    targets.addAll(archs.map { arch ->
        when (arch) {
            "arm64", "arm64e" -> KonanTarget.TVOS_ARM64
            else -> error("Unknown tvOS device arch: '$arch'")
        }
    })
}

The same branch handles appletvsimulator. The predicate that decides whether a target is one the plugin handles at all also had to widen: isIosOrMacTarget now ends with || isTvosTarget(). This is the same pattern as the linker flags, where the condition was already there and only needed to know about one more Apple platform.

Only arm64

This fork has two tvOS targets: tvosArm64 for the device and tvosSimulatorArm64 for the simulator. There is no tvosX64, even though Kotlin/Native does have a TVOS_X64 entry and it shows up in a grep, including in the resource decoder above, where the simulator branch maps x86_64 to it. That branch is copy paste from the iOS decode and is dead in practice, because the only machine that would produce an x86_64 Apple TV simulator is an Intel Mac.

TvosX64 was in ComposePlatforms and in the TV_OS set long before I touched anything. Upstream took it out in January 2026 in a commit called "remove apple x64 targets", which dropped MacosX64, IosX64, TvosX64 and WatchosX64 together with the api dumps that referenced them. So I inherited a tree with no Apple x64 anywhere, and I did not re-add it, because it would mean one more klib to build, publish and rebase for a shrinking set of users. The only place the name still came up is in the plugin repository, where an integration test referenced tvosX64 and now points at tvosSimulatorArm64.

What's next

With the build layer in place the targets compile, and the compiler starts reporting what is actually missing. Most of that lives in rendering, which is Part 3: how Compose hosts itself inside a UIViewController on tvOS, ComposeSceneMediator and the hosting view, layers, Skiko and Metal, frame scheduling, and why these particular files are the ones that fight back on every upstream rebase.

Previous: Part 1, My Journey Making Compose Multiplatform Work on tvOS. Next: Part 3, Rendering (coming soon).

My Journey Making Compose Multiplatform Work on tvOS, and What I Learned

Sajid Ali — Sat, 05 Sep 2026 07:43:02 +0000

Part 1 of a series. This post is the high-level overview. The next posts go into each module in detail.

I am an Android and Android TV developer with about ten years of experience. For the last few years I have been leading a streaming app at Devolic that has to run on Android mobile, Android TV, desktop, iOS and tvOS. This series is about how that requirement ended with me maintaining a fork of Compose Multiplatform with tvOS support, and what I learned along the way.

How we got here

The app did not start out multiplatform. It went through the same three phases as a lot of Android codebases.

Android Views. The first version was classic Views and XML, one codebase for phone and TV with a lot of if (isTv) checks.

Jetpack Compose. When Compose became stable we rewrote the UI in it. The TV side got a lot better because focus handling in Compose is explicit, and androidx.tv:tv-material gave us proper TV components.

Compose Multiplatform. Then desktop, iOS and tvOS were added to the roadmap. We are a small team. Building and maintaining four or five separate UI layers was never realistic, and even with more people, keeping feature parity between them is where small teams lose the most time. Compose Multiplatform was the obvious choice: same UI code, same design system, same navigation on every platform.

Except for one platform.

Why not Kotlin Multiplatform with SwiftUI on the TV?

The first plan for Apple TV was the usual one: share the business logic with Kotlin Multiplatform and write the tvOS UI natively in SwiftUI.

We tried it, and SwiftUI's focus management was the deal breaker. On a TV, focus is the whole user interface. You need to decide exactly where focus goes on every D-pad press, restore it when the user comes back to a screen, keep it inside a dialog, move it into a row and remember which item was focused last time. Compose gives you FocusRequester, focusProperties, focusRestorer and the ability to intercept key events anywhere in the tree. SwiftUI gives you a handful of modifiers and a focus engine that mostly does what it wants. We spent a lot of time fighting it and still could not match the behaviour we already had on Android TV.

So the question became: how hard would it be to make Compose Multiplatform itself run on tvOS?

What tvOS actually is

Once I started researching, the picture was more encouraging than I expected.

tvOS is iOS with a different input model and some frameworks removed. Same kernel, same Objective-C runtime, same UIKit at the core, same Metal. The differences that matter for a UI toolkit are:

No touch screen. Input comes from the Siri Remote as UIPress events plus indirect touches from the trackpad.
Focus is driven by UIKit's focus engine, and every view is expected to take part in it.
A long list of iOS APIs simply do not exist: drag and drop, hover gestures, the text loupe, edit menus, screen edge pan gestures, window scene orientation APIs, and so on.
A different SDK name (appletvos / appletvsimulator) and different Kotlin/Native targets (tvosArm64, tvosSimulatorArm64).

That last point is the real cost. In Kotlin Multiplatform, a target is a target. It does not matter how similar tvOS is to iOS: every library in the dependency graph has to publish a tvosArm64 variant or the build fails during dependency resolution. Compose Multiplatform is a deep stack of modules, so that meant going through the entire stack.

The one thing that could have stopped the idea before it started was Skiko, the Skia binding that Compose Multiplatform uses for rendering. If Skiko had no tvOS build, I would have had to build Skia for tvOS myself. It turned out that Skiko already published tvOS targets. That was a major relief, and the moment the project went from "maybe" to "let's do it".

Deciding how to do it

There were two repositories to change.

The Gradle plugin (compose-multiplatform repository). This is where the Compose Gradle plugin decides which Kotlin targets it knows how to configure, mostly for resources. Kotlin Multiplatform already supported tvOS, so this was a matter of telling the plugin that a tvOS target is an Apple target that needs the same resource handling as iOS:

private fun KotlinNativeTarget.isTvosSimulatorTarget(): Boolean =
    konanTarget === KonanTarget.TVOS_X64 || konanTarget === KonanTarget.TVOS_SIMULATOR_ARM64

private fun KotlinNativeTarget.isTvosDeviceTarget(): Boolean =
    konanTarget === KonanTarget.TVOS_ARM64

private fun KotlinNativeTarget.isTvosTarget(): Boolean =
    isTvosSimulatorTarget() || isTvosDeviceTarget()

private fun KotlinNativeTarget.isIosOrMacTarget(): Boolean =
    isIosTarget() || isMacTarget() || isTvosTarget()

The runtime (compose-multiplatform-core repository). This is the actual androidx.compose.* code with JetBrains' iOS, desktop and web implementations. Every module with a UIKit-specific implementation needed a tvOS one. The build setup already had a TV_OS platform enum that was not used anywhere. Enabling it was a one-line change in ComposePlatforms.kt:

val SKIKO_SUPPORT = EnumSet.of(KotlinMultiplatform) + JVM_BASED + IOS + TV_OS + MACOS_NATIVE + WEB

Plus registering the two targets in the shared target configuration with the same UIKit linker flags that iOS uses:

val uikitFlags = listOf("-linker-option", "-framework", "-linker-option", "UIKit")

project.multiplatformExtension!!.run {
    iosArm64 { configureFreeCompilerArgs() }
    iosSimulatorArm64 { configureFreeCompilerArgs() }
    tvosArm64 { configureFreeCompilerArgs() }
    tvosSimulatorArm64 { configureFreeCompilerArgs() }
}

With the targets enabled, the build immediately showed what was missing: dozens of expect declarations without a tvOS actual, and a handful of Objective-C files that did not compile against the tvOS SDK. That is where the real work started, and I needed an order to do it in.

Going through the modules in dependency order

The approach I settled on was simple. Start with the module that does not depend on any other Compose module, make it build for tvOS, then move to the modules that only depend on modules that are already done. Never touch a module before its dependencies compile.

The order ended up like this:

compose:ui:ui-uikit          <- Objective-C / cinterop layer, no Compose dependencies. Start here.
   └─ compose:ui:ui-util
       └─ compose:ui:ui-text
           └─ compose:ui:ui       <- ComposeUIViewController, rendering, input, focus, density
               ├─ compose:ui:ui-test
               └─ compose:foundation:foundation
                   ├─ compose:material3 (+ adaptive, ripple)
                   ├─ navigation-compose / navigation3-ui / window-core
                   └─ tv:tv-material   <- ported from the Android-only androidx.tv library

One decision made this much easier. Instead of a separate tvosMain copy of everything, I added a shared uiKitMain source set that both iosMain and tvosMain depend on. Anything that is plain UIKit code lives there once. Only the parts that are actually different get a tvOS-specific file.

uiKitMain {
    dependsOn(nativeMain)
    dependencies { implementation(project(":compose:ui:ui-uikit")) }
}
iosMain  { dependsOn(uiKitMain) }
tvosMain { dependsOn(uiKitMain) }

The first module: ui-uikit

ui-uikit is the thin Objective-C and Swift layer that Compose's Kotlin code calls through cinterop. It is an Xcode project (CMPUIKitUtils) that Gradle builds with xcodebuild and exposes to Kotlin through a generated .def file. Because it has no Kotlin dependencies on the rest of Compose, it was the natural first step. It was also the smallest step in the whole port: around 110 lines across 20 files, in a single commit.

Three kinds of changes were needed.

1. Build the Xcode project for the tvOS SDKs. The Gradle code that runs xcodebuild assumed iPhone SDK names, so it had to learn about appletvos and appletvsimulator and the matching build destinations. The Xcode project itself needed the tvOS platforms and the Apple TV device family added. I will cover the whole build setup, including a cinterop quirk around linker options, in the next post.

2. Exclude UIKit APIs that do not exist on tvOS. This was most of the diff. Every file that used an iOS-only class got a TARGET_OS_TV check. For example, the accessibility element uses UIFocusHaloEffect, which tvOS does not have:

#if !TARGET_OS_TV
- (UIFocusEffect *)focusEffect {
    return [UIFocusHaloEffect effectWithRect:[self focusEffectRect]];
}
#endif

Whole classes were excluded the same way: CMPDragInteractionProxy and CMPDropInteractionProxy (no drag and drop on tvOS), CMPHoverGestureRecognizer (no pointer hover), CMPScreenEdgePanGestureRecognizer, CMPTextLoupeSession and the UIWindowScene orientation extensions.

3. Add empty implementations for classes that cinterop still references. Excluding a header is not always enough. CMPEditMenuView is declared in a header that the shared cinterop definition still includes, so the Kotlin side references the class and the linker needs the symbol. On tvOS it gets an empty implementation:

#if TARGET_OS_TV
// tvOS stub: CMPEditMenuView is iOS-only. This empty implementation satisfies
// the linker when the interface is included via the shared cinterop headers.
@implementation CMPEditMenuView
@end
#else // !TARGET_OS_TV
... real implementation ...
#endif

Once ui-uikit produced a framework for both tvOS targets, I could move on to the rest of the modules.

Which module needed the most effort

By a wide margin, compose:ui:ui. Roughly 4,400 lines changed across 25 commits, compared to about 110 lines in ui-uikit and under 300 in foundation. It is the module where tvOS stops being "iOS with some APIs missing" and becomes a genuinely different platform:

Rendering and hosting. ComposeSceneMediator, ComposeContainer, the hosting view and the view controller all have tvOS versions. These files own the UIKit view hierarchy, rendering through Skiko, and the interop with native views. They are also the files JetBrains refactors most often, so keeping them in sync with upstream is the main ongoing maintenance cost of this fork.
Siri Remote input. UIPress and UIPressesEvent have to be converted into Compose KeyEvents. D-pad navigation, swipe-to-focus on the trackpad, key repeat, treating the Menu button as Key.Back, and telling a trackpad click apart from a swipe (which needed hardware timestamps, because the trackpad is itself a button).
Focus. UIKit's focus engine and Compose's focus system have to agree on which one owns focus, which happens through didUpdateFocusInContext.
Screen density. UIKit reports an Apple TV at the same scale as a phone, which gives a 1080p screen a 1920x1080 dp canvas. That is far too dense for a TV UI viewed from the couch. Android TV treats 1080p as density 2.0, a 960x540 dp canvas, and squaring the UIKit scale reproduces exactly that. The original scale is kept for insets and accessibility.
Text input. tvOS has a full-screen keyboard instead of the inline one on iOS, so it has its own text input service.
No-op implementations. Drag and drop, haptics and clipboard get empty implementations.

Foundation mostly needed the move to the shared uiKitMain source set plus tvOS implementations for things like text selection handles and the magnifier that do not exist on a TV. Material3 was almost entirely build configuration. And tv-material, the component library that makes a TV app look like a TV app, had to be moved from an Android-only AndroidX module into commonMain with expect/actual pairs for the Android and tvOS specifics.

Lessons learned

Check the critical dependency first. Skiko having tvOS support was the deciding factor. Confirm that kind of thing before writing any code.
Port modules in dependency order. Every failed build then points at exactly one module, and you never chase errors caused by a dependency you have not ported yet.
Share as much as possible between iOS and tvOS. The uiKitMain source set kept the tvOS-specific code small enough for one person to maintain.
The hard part is not the missing APIs, it is input. Excluding UIHoverGestureRecognizer takes a minute. Making the Siri Remote feel right takes weeks.
Expect constant upstream changes. A fork of a fast-moving toolkit needs regular rebasing. The rendering and hosting files had to be adapted to upstream refactors many times.

Try it

Everything is published and usable today as a community project. It is not official JetBrains work.

Gradle plugin and docs: github.com/sajidalidev/compose-tvos and sajidalidev.github.io/compose-tvos
Compose runtime fork: github.com/sajidalidev/compose-multiplatform-core (branch tvos-main)
Gradle plugin fork: github.com/sajidalidev/compose-multiplatform (branch tvos-main)
A full sample app, Google's JetStream ported to tvOS: github.com/sajidalidev/jetstream-tvos
tvOS-enabled forks of Koin and Coil: github.com/sajidalidev/koin, github.com/sajidalidev/coil
The upstream feature request, if you want to add your vote: CMP-5686

Adding it to an existing Compose Multiplatform project is one plugin:

plugins {
    id("dev.sajidali.compose-tvos") version "1.4.2"
}

kotlin {
    tvosArm64()
    tvosSimulatorArm64()
}

Keep your normal org.jetbrains.compose.*, androidx.tv:tv-material, Koin and Coil dependencies. The plugin redirects them to tvOS-capable builds of the exact same versions. Kotlin 2.3.20 or newer is required.

What is next in this series

This post stayed deliberately high level. Over the coming weeks I will go through each part in detail:

Overview. This post.
Build setup. Kotlin targets, the shared uiKitMain source set, the fork's separate build files, the ui-uikit Xcode and cinterop build, and tvOS resources in the Gradle plugin.
Rendering. How Compose draws inside a UIViewController on tvOS: ComposeSceneMediator, the hosting view, layers, Skiko and Metal, frame scheduling, and why these files change the most on every upstream rebase.
Siri Remote input. Converting UIPress to KeyEvent, D-pad navigation, connecting UIKit focus with Compose focus, and the Menu button as Back.
Siri Remote trackpad. Swipe-to-focus, telling a click from a swipe with hardware timestamps, phantom swipes, key repeat and long press.
Screen density and text input. Why the density is the square of the screen scale, and building a text input service around the full-screen tvOS keyboard.
Porting tv-material. Surface, Carousel, SurfaceGlow, accessibility, and a null Skia pointer that took a while to find.
The Gradle plugin and third-party libraries. Why one plugin instead of new Maven coordinates, Koin and Coil, libraries that publish no tvOS variant, and the Kotlin version requirement.
Maintaining the fork. Rebasing onto upstream, the release process, compile-verified versus test-verified, and what I would do differently.

If you have a Compose app and a TV target on your roadmap, I would love to hear what breaks when you try it.