Last week, I wrote an <article about React Native>...

# feed

[Filip Wiesner]

Last week, I wrote an article about React Native. I know it’s not kotlin but kotlin colored, but it’s from the perspective of a primarily Android developer, and I think it’s really helpful to know about other technologies in the mobile space if you’re a mobile developer.
I think there are a lot of misconceptions about RN, and I myself got many things wrong before researching this article. I explain how RN works, why I don’t like it, and why it is still a really cool technology.

[Alex Styl]

Thanks for sharing. I enjoyed this read.

On topic and more related to Kotlin, why do you want this UI abstraction for KMP?

I like how CMP should produce the same result in all platforms and handles the rendering. But I do see people wanting the other way round a few times.

[Filip Wiesner]

why do you want this UI abstraction for KMP

Because it gives you the most freedom. Maybe an unpopular opinion (especially for product managers 😄 ) but I don't think the app should look and behave the same on every platform. I like CMP, don't get me wrong, but I just feel dirty using it after hating on Flutter my whole career, if that makes sense 😅

[Alex Styl]

it gives you the most freedom

Freedom in what sense? I'm not trying to argue what solution is better. I'm genuinely trying to understand what do you like about it.

ie from my pov, the fact that CMP does the rendering give me the freedom to build anything I have in my mind, instead of being tied to the platform. but it doesn't seem like thats what you have in mind

[Filip Wiesner]

In theory you could use CMP with this theoretical abstraction on some platforms and use something else on other platforms. For example I don't want to use CMP on web because it seems there are a lot of drawbacks.
RN enables this, you can write everything using RN, including the web, but on Desktop you would wrap all of that in Electron which is the custom renderer.

[Alex Styl]

did you ever have the need for this?

[Filip Wiesner]

“Need” is a bit strong, but I did build an app using CMP where I also needed a web version, and I burned out on the web app because I had to do a lot of stuff again.
And although you can combine SwiftUI and Compose, you either have to cut a hole into Skia or draw on top of it. And I remember reading about RenderNode and that Compose uses Views before Android 10 for graphical layers so maybe there could be something like that for other primitives on different platforms. But maybe I am understanding that totally wrong 😅 That's just a vague memory of an interesting fact about Compose

My whole argument basically boils down to "I think ReactNative is the right UI abstraction and I wish I could just use Kotlin instead of TypeScript" 😄

[Pablichjenkov]

Well, worth saying that even after all the improvements in the new RN arch using JSI, which puts it in the same level as Kotlin and Flutter(using modern platform channels ffi) but with the disadvantage that JS needs a full VM on RAM in order to be executed vs a small runtime in the case of Flutter and KMP. Kotlin is safer in the sense that KMP checks interop types at compilation time. In RN TurboModules(equivalent to Flutter Platform channels) you have to manually cast all your types out of a "MapString, Object". Not a terrible thing for a small project but in big enterprise App with many teams this is a remarkable advantage for KMP.
On the other hand it is possible to create a framework like react-native on top of compose.
You just need to create a bunch of components using the CMP to swiftui interop API(UiKitView/UiKitViewController). By a bunch I mean a full design system from text/button/toggle all the way to navigation components like drawer/bottom bar/topbar and such.
However, IMO this is one of the points KMP tooling has to improve. It is extremely boilerplated the current process to achieve CMP and swiftui interop.
There are a few articles online highlighting this inconvenience

[Yassine Abou]

Great article, @Filip Wiesner I have a question: I have explored some mobile reactive apps and I noticed that when an app is doing work and then goes into the background, the task stops, and the work seems tied to the main thread. Is this because of the framework or the developer’s code?

[Alex Styl]

> think ReactNative is the right UI abstraction and I wish I could just use Kotlin instead of TypeScript
You guys got me curious so I spiked it to see if this can work with Compose.

So here is Compose Runtime driving UiKit on iOS and as a result use "real" iOS components (Liquid Glass) without interop or having to fight the platform.

The code is all Kotlin with Compose, where Compose manages the state and leaves UiKit handle the rendering instead of Compose UI/Canvas

I guess this is how Compose HTML works under the hood as well.

ScreenRecording_08-19-2026 10-39-39_1.MP4ComponentCatalogue.kt

[Alex Styl]

So is this doable? Seems like it

The hard bit here is probably the mapping of modifiers (and potentially ton of other stuff that we take for granted on Compose UI) to "this"

[Pablichjenkov]

Doable yes, worth it - that's the real question. What's the problem here - Apple going full swing the swiftui direction.
What happens? - uikit interop is great, however, swiftui, not so much, you end up creating one UiHostingViewController per each component. Performance will just hurts when a regular screen instantiate so many ViewControllers 🤕
One of the long term risks of react-native is Apple moving away from uikit (same as Google just did with compose). Unfortunately the only way to interop with swiftui is through this hostingviewcontroller. And that is extremely inefficient.

[Pablichjenkov]

I just wish the wasm ecosystem finally takes over the planet as a whole. And every App becomes basically a WebView with native performance. And this crossplatform nightmare be over.

[Alex Styl]

I don't think you understood what I am showing above. The above is not using ui kit interop, because it is not Compose iOS.

Normal Compose iOS is the expect/actual implementation of Compose UI.

The above is a new layer ontop of Compose Runtime (instead of Compose UI). There is no Swift UI or any sort of interop involved

[Pablichjenkov]

Gotcha, yeah I missed that part. Actually I just noticed you also posted a code snippet.
But I think it kinda falls into the same problem I described. Can you do the same with swiftui without using UiHostingViewController?

[Alex Styl]

I don't get the question. The above doesn't use swift ui at all. The entirety of rendering is done by ui kit.

Can you have SwiftUI do the rendering instead of UiKit? I would imagine you can. whether you need UiHostingViewController or not depends on swiftui/uikit, not compose.

[Alex Styl]

is your concern about swiftui <> uikit performance?

[Pablichjenkov]

My concern is, building a crossplatform UI framework, on top of UiKit, has a high risk of Apple abandoning uikit at some point.
If you thought this won't happen, look at Google and compose and the classic toolkit.
Now, you might say: well, let's build it using swiftui instead. But then you face this technical challenge where you need UiHostingViewController to wrap each component. I honestly haven't heard of another API.
The fact that each small ui component will be contained in a UiHostingViewController, is not ideal. Probably not noticeable to the human eye, but definitely not ideal.

[Filip Wiesner]

I am this close to being nerd-sniped into trying that 🤏 SwiftUI view builder is just a syntactic sugar on top of statically typed tree of views. There has to be a way to do that. But I guess the problem is that it is closed source

[Pablichjenkov]

Proprietary code, unfortunately.