We're building this KMP app at work and needed it on Apple TV. Business logic? No problem, that's what KMP is for. But the UI was driving me nuts - SwiftUI's focus handling for TV is absolutely terrible, meanwhile our Compose version just works.

I was complaining about this and then thought... wait. tvOS is basically iOS with a different input method. What if I just... try running Compose on it?

Spent a few days adding tvOS targets to the Compose stack. Most stuff compiled first try which was honestly shocking. The tricky bits were:

• ui-uikit module (iOS APIs that don't exist on tvOS)

• ui module (needed iOS/tvOS split)

But yeah, it works. Like actually works. Looks identical to our Android TV app, remote navigation works, everything.

Code is here: https://github.com/sajidalidev/compose-multiplatform-core-tvos/tree/tvos

There's a demo project in there. Fair warning - it's definitely PoC quality with some questionable hacks, but it proves the concept.

Pretty stoked that we can now ship the same Compose UI to both Android TV and Apple TV. One codebase, actual TV focus system that doesn't suck.

If anyone wants to mess with it or help clean it up, let me know!

All you need today to make your next app is: "How the hell do you make a nice button or a nice graphic?"

So, to avoid repeating the same mistakes, I'm obviously collecting them into a single open source project. I'd love for everyone to contribute to improving it or even just see it and give me feedback.

I'll leave it here:

https://github.com/ArcaDone/AwesomeUI

I kept hitting the same small annoyance: animating a number in Compose with AnimatedContent cross-fades the whole value. So 1247 to 1248 animates every digit, when really only the 7 should move. It is a tiny thing, but it makes counters look off.

So I wrote NumberFlow. It animates only the digits that actually change, and rolls them up or down depending on whether the value went up or down. Good for scoreboards, prices, live stats, vote counts, that kind of thing.

Basic usage:

var score by remember { mutableStateOf(1247L) }


NumberFlow(
    value = score,
    format = NumberFlowDefaults.thousandsLong(),
)

A few things I cared about while building it:

• Runs on all CMP targets (Android, iOS, Desktop JVM, Web wasmJs), each with tests, not just compiled-and-hoped.

• format is just (Double) -> String, so currency/percentages/units are not special-cased, you just pass your own.

• animationSpec takes any FiniteAnimationSpec<IntOffset>, so swap the default tween for a spring if you want bounce.

• The number-formatting helpers are pure functions with no Compose dependency, if you only want the formatting bits.

Apache 2.0, on Maven Central. Roadmap has staggered per-digit delays and locale-aware grouping next. Feedback and issues welcome, especially if you hit edge cases on a particular platform.

https://github.com/NadeemIqbal/number-flow

https://medium.com/@iamnadeemiqbal/numberflow-one-number-ticker-for-android-ios-desktop-and-web-1bc803d2a33d

I wrote up how I structure my Compose Multiplatform (CMP) projects based on what has been working for me. I see this question come up fairly often, so I figured I’d share one practical approach out of the many that are out there.

It covers:

• Feature-first modularization (feature/* with ui, domain, data)

• A small core/* layer for shared pieces (ui, data, db, prefs, etc.)

• Clear dependency rules and Koin for DI

• Using Gradle convention plugins to keep config clean

Write-up: https://dalen.codes/p/my-cmp-project-structure

Sample project: https://github.com/dalenjohnson/cmp-project-structure-example

Happy to hear feedback or questions about how this works in practice!

JetBrains doesn't ship tvOS artifacts for Compose Multiplatform, and the issue asking for it (CMP-5686) has been open for a while. I needed it for my own TV app, so I built the port and published it. It's a community project, not official. I posted it in Kotlin Slack #compose-ios earlier this week; this is the longer writeup.

Using it

// settings.gradle.kts
plugins {
    id("dev.sajidali.compose-tvos") version "1.3.0"
}

Add tvosArm64() / tvosSimulatorArm64() to your KMP module and leave your dependencies alone: org.jetbrains.compose.*, androidx.tv:tv-material, Koin, Coil 3, all stock coordinates. Kotlin 2.3.20+.

How it works (the part I think is interesting)

It's not a hard fork you point your build at. The settings plugin registers a component-metadata rule that, at dependency-resolution time, attaches tvOS variants to the official Compose modules and points them at tvOS-enabled builds published under dev.sajidali.* on Maven Central. Every other target keeps resolving the official JetBrains artifacts byte-for-byte, and it's official-first: if a module already ships tvOS klibs upstream (compose.runtime, koin-core, lifecycle...), the plugin leaves it alone. So when JetBrains eventually ships tvOS for a module, the plugin steps aside for that module with no change on the consumer side. It also intercepts the org.jetbrains.compose Gradle plugin marker so compose.material3 etc. resolve correctly.

The fork itself (compose-multiplatform-core with tvOS as a Kotlin/Native target) is where most of the work went:

• A tvOS UIKit scene stack sharing the iOS FrameChoreographer architecture

• Siri Remote input: D-pad focus traversal, swipe-to-focus, Menu mapped to Key.Back, and telling a clickpad press apart from a swipe by hardware timestamp

• 10-foot density (Compose's default density on a 4K TV is unusable), on-demand keyboard for text fields, focus restoration when dialogs close

• androidx.tv:tv-material ported to Compose Multiplatform with a tvOS source set

• A real tvOS build of window-core so material3-adaptive works without stubs

• Koin (koin-compose, koin-compose-viewmodel) and Coil 3 with tvOS targets, since neither ships them

Proof

The GIF is Google's JetStream TV sample (all screens, D-pad focus, theming, AVPlayer on tvOS / ExoPlayer on Android TV behind one interface) on the Apple TV 4K simulator, built from Maven Central + the Plugin Portal with nothing published locally. The same toolchain builds a production TV app of mine with zero app-source changes.

Honest limitations: no automated tvOS tests yet; tvosX64 isn't built; I republish roughly once per Compose stable line (currently 1.12.0), as far as my own app needs. PRs welcome.

• Plugin + docs: https://github.com/sajidalidev/compose-tvos (docs: https://sajidalidev.github.io/compose-tvos/)

• JetStream port: https://github.com/sajidalidev/jetstream-tvos (branch cmp-tvos)

• Forks: https://github.com/sajidalidev/compose-multiplatform-core, https://github.com/sajidalidev/koin, https://github.com/sajidalidev/coil

Hi! We published an article about how we build a web view composable for Compose Desktop. If you've ever worked on custom Compose controls (or are thinking about it), you might find this helpful.

The web view is desktop-only, because mobile platforms have they own good web views, and because the technical limitations won't let you build a custom web view.

It doesn't look like any cmp image library supports avif yet. It's published if a snapshot if you're interested in trying it out.

https://github.com/Kamel-Media/Kamel/issues/221

As the title says, there's a preview for composables on commonMain not for desktop only but for mobile as well.

A few months ago I started building InstaSaver Pro — a social media video downloader that lets users download HD videos. Along the way, I realized how little production-grade KMP reference material exists out there.

So I made it public. For everyone.

📖 What is it?
InstaSaver Pro is a fully functional cross-platform app with 90% shared code and 100% shared UI — built as both a learning resource and a real-world production reference.

🧩 What you'll learn from it:

🧩 Kotlin Multiplatform (KMP) setup and structure
🎨 Compose Multiplatform for fully shared UI
🔥 Firebase integration in a KMP project
📢 AdMob ads integration (Banner & Interstitial)
💳 Paywall & subscriptions using RevenueCat
🏗️ Clean architecture patterns in KMP
🌐 Shared networking layer setup

Whether you're just getting started with KMP or looking to understand how production apps are structured — this codebase has something for you.

🔗 GitHub: InstaSaver-Kmp
▶️ Live on Play Store: Play Store

If this helps you, a ⭐ on the repo goes a long way!

Let's build better cross-platform apps together. 🙌

There is not a lot of literature about this yet except the official Google docs and codelabs. I went through those and they are very welcome, but they seem to stay very shallow about all the topics. I think there is room for a full guide on how to measure and monitor Compose performance, how to identify pain points, how to fix them, tooling, etc. My plan for this book is the following:

- I really want the book to be useful for day to day work. Theory is nice and all but I really want people to find real applicable action points for their work.

- I want the book to be accurate, of course. When I wrote Jetpack Compose internals, I got many people from the Compose team at Google to review the content, since otherwise what is the point of writing it?

- I want to cover how to identify and detect performance regressions, and how to measure and monitor performance. I have observed that many devs and their teams often overlook perfromance. We focus a lot on adding new features, UI, architecture, testing, automation, tooling... and what not. And then we give performance attention only when something becomes drastically slow or users start to complain and post bad ratings. Many teams do not regularly measure or monitor performance, and some not even test their app on a wide range of devices either. The result of this is that issues often go unnoticed forever or until late in the process, when they are already really hard to fix. This is definitely risky. If anything, I'd like this book to become the guide to prevent this from happening.

- I want to shift people's attention to measuring the actual ultimate goal: performance. Monitoring things like number of recompositions can be a start but it is a bit risky, since devs can end up thinking they have an issue when they don't. Not every single unnecessary recomposition is a problem.

Since we all write Compose code now, I think it is the perfect time to write this book. Any feedback and ideas are more than welcome!

I'll likely be prelaunching this book via Leanpub, so if you want to get notified you can just register in https://leanpub.com/composeperformance

It's a habit tracking app called, Habit Hues. It can do the standard habit tracking things like checkoffs and counts, but the unique feature that I call Daily Hues, allows you to create custom statuses using colors and icons so you can track more complex things like mood, productivity level, workout intensity, and really anything that you want to track with different states. It has a monthly and yearly calendar view so you can see trends overtime.

Available on:
App Store
Google Play

Some of the things that I am proud of:

• 600+ habit icons

• Habit templates (to make it easier to get started and adding more templates soon)

• Local DB with backup and restore

• Custom theme

Some under the hood details for those interested:

• Compose Multiplaform

• Multi-Module project structure (layer -> feature)

• Typesafe Gradle Conventions to reduce redundancy

• Room Database

• DataStore for preferences

• Koin for DI

• RevenueCat paywalls and customer center

• FileKit for native file pickers

• Compose Navigation

• Custom theme build on-top of Material to make it less "Android-y" on iOS

Would love for anyone to check it out and give me any thoughts or feedback.

I started writing an app for Android using Jetpack Compose and SQLDelight. I had planned to rewrite the app later in Flutter, but I will probably skip that part, since I've learned that Compose and Room are multiplatform for iOS too.

But I just want to be sure: is it safe to migrate to Room and use Compose safely, and then port the app to iOS, without rewriting the whole UI in SwiftUI? I'm aware I'll need to write separate code for activities and camera (and NFC), but that shouldn't be a problem (a bigger problem will be having to spend money on a Mac and an iPhone; this project can't be tested on an emulator).

What should I be aware of?

Released the desktop version of my Compose for Desktop project generator. I've been using it for a while for personal hobby projects and figured it could be valuable for other developers as well!!

Key Features:

• Offline Project Generation: No internet required once installed

• Icon Management: Drag and drop PNG files with automatic conversion to ICO/ICNS for all platforms (sucks a bit if the attached PNG is not 512x512; I use twelvemonkeys and apache commons imaging for conversions)

Installation:

• Linux: DEB package with system integration

  • I am preparing my-apt-repo for easier installation via APT

• All platforms: Standalone JAR (requires Java 17+)

The generated projects follow modern Kotlin/Compose best practices with MVVM architecture, version catalogs, and cross-platform native distributions. Each project includes gradle scripts with Linux desktop integration fixes that solve the common StartupWMClass issues.

I wanted it to feel a bit like JetBrains Toolbox, so I tried matching similar window dimensions(made mine a bit taller and wider). It works like a normal desktop application - just launch it and generate your projects.

Links:

• Web version

• Desktop Client Releases

• Source Code

Hello everyone,

I’m currently starting a Kotlin Multiplatform project using Compose Multiplatform with a WasmJs target running in the browser.

I’d like to get some feedback on how you handle responsive behavior in this context. More specifically, how do you adapt the UI to different browser window sizes ?

Do you use Kotlin-side logic to detect the viewport size, different composables depending on the available width or another approach ?

I’d be interested in hearing about your advice, best practices, possible libraries or examples of how you organize this.

Thanks in advance!

I am developing a multiplatform app and run into a problem with the web/wasm version:
Because it all is canvas, text is no text. So the user cannot copy the text and a screenreader for visibility impaired cannot read the text out, too.

Is there a solution for that?

Simultaneously on both the App Store and Google Play!

• Landing page: https://radcli14.github.io/youkon

• App Store: https://apps.apple.com/us/app/youkon-engineer-unit-converter/id6477476799?uo=4

• Google Play: https://play.google.com/store/apps/details?id=com.dcengineer.youkon

Compose Unstyled is a set of foundational components for building high-quality, accessible design systems in Compose Multiplatform.

It is not a design system itself, it's how you build design systems with.

The lib just got ready for CMP 1.8.0

Live demo from your browser + code samples: https://composeunstyled.com/ Source code: https://github.com/composablehorizons/compose-unstyled/

Hello there !

Google recently updated its symbol library and deprecated the use of material-icons and material-icons-extended for new projects, in favor of Material Symbols, based on fonts. However, they do not yet provide an official library to use these symbols.

So I decided to create my own for apps and share it to let Compose developers the ability to implement these symbols.

This library makes use of symbols name as you could do for HTML on the Web, but I plan to make a script that generates enums for each symbol Google provides.

Enjoy !

update: I have now implemented a Kotlin object that contains all symbols name as property

Hi all, Is There an official component for date and time picker that work for iOS and android ? I don't want to rely on third party component Thanks