Hi everyone! I have a question about the experimen...

# compose-ios

[Meet]

Hi everyone! I have a question about the experimental macOS target and native macOS integration.
I’m currently exploring whether a macOS-only application could combine Compose Multiplatform/Kotlin with a native Swift/Xcode macOS application.
I tried the experimental macOS target and, in a small POC, I was able to import the generated Kotlin framework into a native macOS Swift app and call a Kotlin function that creates a Compose Window from macosMain.
This made me curious about the intended use and current direction of this approach.
Is this experimental macOS target intended to support a native Swift/Xcode macOS application working together with macosMain Compose/Kotlin code, similar in concept to the native iOS/Xcode integration?
I’m particularly interested in whether this could be a reasonable approach for a Mac-only application where native Swift/AppKit APIs are needed for some platform-specific functionality, while Compose/Kotlin is used for the UI and shared application code.
I understand that this is experimental, so I’m not assuming that this is currently production-ready or the recommended architecture. I’d mainly appreciate any clarification about its current status, intended use, and known limitations.
Thanks!

[Meet]

Additional context: I originally asked about this in #compose-desktop, and there was a longer discussion around the possible architecture and native macOS integration.
I’m sharing that thread here for context rather than repeating the whole discussion:
https://kotlinlang.slack.com/archives/C01D6HTPATV/p1790575914718089?thread_ts=1790521500.988169&cid=C01D6HTPATV
The POC mentioned above is based on that discussion. I’ve also attached the current setup/screenshot for reference.

[Andrei Salavei]

Sure you can use Kotlin to build native MacOS apps with Compose Multiplatform. As you highlighted - it is in experimental phase. It means, we're not actively investing in this target, its feature completeness and bug fixes (same as TvOs). Use it on your own risk.

[Sargun Vohra]

I recently ported MapLibre Compose to macosMain target just to try it out. It works okay, I noticed some bugs here and there but no deal breaker. The app "feels" better than an AWT app

But for a complex app I'd recommend Nucleus over that. You get the native window toolkit "feel", more desktop APIs, especially for input that the jvmMain AWT host and the macosMain target are both missing

[Sargun Vohra]

Though I'm curious, would JB accept PRs to improve the native macOS target? I'm thinking for stuff like fixing small bugs or wiring up some input or platform APIs, nothing major

I will soon be unemployed and have some more free time for the next few months 😅

[Meet]

Thanks @Andrei Salavei! That's really helpful to know.
I was mainly trying to understand whether this native macOS direction was technically possible, and my small POC seems to work as well.
I'll keep in mind that macosMain is currently experimental and not an actively invested target, especially before considering it for a production app. Thanks for clarifying!

[Meet]

Thanks @Sargun Vohra for sharing your experience! It's really helpful to hear from someone who has actually used macosMain in a real project.
The native macOS feel was one of the reasons I was interested in this approach. My main concern is also the deeper desktop APIs and platform-specific functionality, so your point about the missing input/desktop APIs is particularly useful.
I'll definitely take a closer look at Nucleus as well. Thanks for the recommendation!

[Sargun Vohra]

Yeah, depending on what you need from the platform, Nucleus covers a lot. Where even nucleus is missing something, it's not too hard to call ObjC APIs from the JVM
• Example: github.com/maplibre/maplibre-compose/blob/…/BearingHapticFeedback.kt#…
• Via github.com/maplibre/maplibre-compose/blob/…/ObjectiveC.kt
• Via LWJGL's macOS bindings
It's more code than cinterop, but not difficult

[Meet]

Thanks @Sargun Vohra ! I checked the MapLibre example and the ObjectiveC bridge that's really interesting.
I hadn't considered calling Objective-C APIs directly from the JVM like this. The fact that you're using LWJGL's macOS bindings to reach the Objective-C runtime makes the approach much clearer.
I'll take a closer look at Nucleus as well. My main goal is to understand how far I can take a JVM Compose app with native macOS integration before needing to move to the experimental macosMain target.
Thanks for sharing the concrete example!

[Meet]

Thanks! I understand the general approach now.
I was actually looking for a simple example or article that explains how to call an Objective-C/macOS API directly from Kotlin/JVM, rather than just a project-specific implementation.
I searched for this, but I couldn't find a straightforward tutorial showing the basic setup step by step for example, calling a simple AppKit API from a Compose Desktop/JVM application using this approach.
Do you know of any documentation or minimal example that demonstrates this?
Even a small example showing something like:
Kotlin/JVM → Objective-C runtime → AppKit API
would be really helpful.

[Andrei Salavei]

Kotlin already includes pre-built API for some standard MacOS/iOS libraries, but not all of them. So, some API can be accessible directly from Kotlin. Check NSWindow, for instance.
Unfortunately, not every API method is available - usually it's related to Swift-only API and methods that declared not in classes, but in class extensions in Swift/Obj-C. Here we're using dedicated Obj-C framework to provide to Kotlin the exact API that is needed. And it can be included into the Kotlin project using cinterop. Here we're building the Kotlin module with obj-c framework that can be used in other modules.

[Meet]

it that correct?

[Andrei Salavei]

Amm.. does it work? 🙂
As I mentioned - we're not supporting this platform and therefore no recommended way of embedding it in the app. If it works - great! If doesn't - check how it's done in the demo app here: github.com/JetBrains/compose-multiplatform-core/blob/…/Main.macos.kt#… - most likely you need to ask the AI to re-write old NSApplication entry point to the new SwiftUI style.

[Meet]

yes it prefect works. i know it no recommend but i just tryout. currently i also do jvm and macosapp both so i experiment

Screen Recording 2026-10-01 at 4.15.07 PM.mov

[Meet]

Thanks for advised