:rocket: Bridging Compose Multiplatform with Swift...
# feedl
Lucas Prioste
06/12/2025, 3:14 PM🚀 Bridging Compose Multiplatform with SwiftUI
Hey Kotlin Community! 👋
I just published a new post where I explore how to integrate SwiftUI into a Compose Multiplatform project. I also dive into making these components reactive in Swift—a challenging but essential part that involves managing uiState on the Swift side.
📄 Read it here: Bridging Compose Multiplatform with SwiftUI
If you're working with KMP or exploring cross-platform UI strategies between Kotlin and SwiftUI, this might be helpful!
I’d love to hear your thoughts, feedback, or experiences combining SwiftUI with Compose Multiplatform.
k
Konstantin Tskhovrebov
06/12/2025, 3:29 PMI guess you lost a good chance to get hype if you'd added some examples with liquid glass effects think smart
like here: https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1749591259399559
😅 1
l
Lucas Prioste
06/12/2025, 3:45 PMYeah, I think I missed that opportunity 😂 But honestly, who looks at these liquid glass effects and thinks, ‘Wow, that’s beautiful’? 😂
k
Konstantin Tskhovrebov
06/12/2025, 3:49 PMdoesn't matter. an article about UI with no UI samples is boring 😉
l
Lucas Prioste
06/12/2025, 3:59 PMI get what you mean, but my main goal was to demonstrate how to manage UI state in SwiftUI—not to create something visually impressive. I kept the example simple to focus on the reactive aspect in Swift and to keep the post from getting too long but thanks for your recommendation 👍
a
Arjan van Wieringen
06/12/2025, 4:57 PMLiquid Glass is impossible in Skia because the shader for every surface only has acces to its own pixels AFAIK, or the pixels directly under. For refraction and real blurring you need also the pixels outside of the direct surface bounds.
Although the example above looks great, that is the native on top of compose
m
Max
06/15/2025, 3:18 PM@Lucas Prioste cool, ready your article and it‘s very interesting! I am wondering, did you on purpose chose to be able to embed the native view onside Compose?
In my understanding we could also create a whole separate SwiftUi screen, obtain a ViewModel reference inside swift code and then observe the flow. That would reduce the complexity of providing an actual implementation for iOS views
Lmk wyt
l
Lucas Prioste
06/16/2025, 9:08 AMHi @Max, I’m glad you liked the post. Yes, that option is also interesting and possible — it would reduce boilerplate code, but you still always need a way to collect the flow emitted by the ViewModel. I usually don’t use that approach because when I need to implement something in SwiftUI, it’s usually just a single component, not the whole screen. In my opinion, it makes maintenance easier and more straightforward because you know all screens are built in Kotlin. By creating only the necessary component in Swift, we avoid having to go into the Swift code to change a simple TextView or a List — everything stays in Kotlin, and only that specific component needs to be modified in Swift.
2 Views