Adapting Compose Multiplatform for tvOS: Build System Challenges
How build targets and source sets enable Kotlin Multiplatform on Apple TV
1The tvOS fork challenge
Porting Compose Multiplatform to tvOS required fundamental build system changes. Unlike simple feature flags, Kotlin Multiplatform targets determine source set compilation, dependency resolution, and binary publishing. The initial work involved enabling tvosArm64 targets across modules, with each commit addressing missing components revealed by the compiler. This foundational step preceded any UI code implementation.
2Source set architecture
The solution involved creating uiKitCommonMain as a shared parent for iOS and tvOS source sets, since both platforms use UIKit. iOS-specific files remained in uikitMain while tvOS-specific ones moved to tvosMain. This structure minimized duplication but introduced synchronization challenges with upstream changes. Early prototypes used symlinks and file overrides as temporary solutions until establishing a stable branching strategy aligned with JetBrains' repository changes.
3Current source hierarchy
The mature architecture positions uiKitMain between nativeMain and platform-specific sets (iosMain/tvosMain). Shared UIKit implementations reside in uiKitCommonMain, while platform-exclusive features like iOS hover/touch or tvOS focus engine/Siri Remote support live in their respective sets. This design ensures upstream fixes to shared code automatically benefit tvOS without manual backporting, significantly reducing maintenance overhead as the codebase evolves.
4Upstream platform support
Surprisingly, Compose Multiplatform's core already included tvOS in its ComposePlatforms enum and Darwin platform group before the fork began. Over 40 modules like compose/runtime, navigation, and testing utilities already supported tvos() targets. However, UI modules were excluded due to SKIKO_SUPPORT not including TV_OS, preventing Skiko-backed components from building despite Skiko already publishing tvOS binaries.
5Critical build modifications
The fork's essential changes were remarkably minimal: adding TV_OS to SKIKO_SUPPORT to enable Skiko binary expectations, and including ComposePlatforms.TV_OS in JetBrainsPublication.kt's supported platforms list. These two lines allowed UI modules to publish tvOS artifacts instead of discarding them. Most other work involved adding tvos() declarations alongside existing ios() calls in module build files.
6buildSrc evolution
Build logic modifications initially went into buildSrc/, until upstream split the configuration in June 2026. The new buildSrc-fork/ became the active configuration source, with buildSrc/ serving AOSP mode. This architectural change required mirroring tvOS-related edits across both locations. The naming convention proved counterintuitive, as buildSrc-fork contains the primary build logic rather than being a secondary copy.
7Maintenance considerations
The design prioritizes minimizing tvosMain's size since maintenance costs scale with platform-specific code volume. Shared UIKit implementations in uiKitCommonMain automatically propagate to tvOS, while tvosMain only contains essential tvOS-exclusive components like Siri Remote integration. This approach balances functionality with long-term sustainability as the codebase evolves alongside upstream changes.
8Publication pipeline
The fork leverages Compose Multiplatform's existing publication infrastructure. With TV_OS added to supported platforms, modules now properly publish klibs for tvOS targets instead of building and discarding them. This works because Skiko (Compose's graphics layer) already included tvOS binary support, requiring only build system recognition of this capability through the SKIKO_SUPPORT modification.
9Module compatibility
While core modules like runtime and navigation supported tvOS targets from the outset, UI modules required specific enablement. The fork systematically added tvos() declarations to compose/ui, foundation, and material modules. Each addition followed the pattern of existing ios() declarations, ensuring consistent behavior across the multiplatform codebase while unlocking tvOS-specific functionality where needed.
10Cross-platform implications
This tvOS adaptation demonstrates Kotlin Multiplatform's flexibility when extending to new targets. The solution maintains architectural consistency with existing platforms while addressing tvOS-specific requirements. The approach provides a template for future platform expansions, emphasizing shared code organization, build system integration, and sustainable maintenance strategies in complex multiplatform projects.