Compose will eventually arrive for ios, right? If ...

# compose

[mcpiroman]

Compose will eventually arrive for ios, right? If so, will it run on native or jvm?

[CLOVIS]

Currently we don't know if it will arrive on iOS. JetBrains is experimenting to know if it's possible, etc, but they haven't confirmed anything.

If it does arrive though, it will be native (iOS can't run the JVM / it would be a performance problem).

If you want MacOS, then Compose Desktop already works there through the JVM

[gildor]

You cannot run java bytecode on iOS, it restricted, you must use AOT compilation

[gildor]

also everyone who asked about Compose for iOS expects UI framework, not just backend part of compose, and how this UI part may look like (use Compose to manage Swift UI/Uikit views, or have custom rendering) is a huge question

[CLOVIS]

I was assuming UI as well, to my knowledge the backend is already running on iOS

[mcpiroman]

The thing is whether graalvm or another aot can be used so that it is still JVM.

[CLOVIS]

Compose UI needs Skia etc, you won't be able to just run the desktop version there

[gildor]

Compose UI needs Skia

There is no generic Compose UI which works on Skia, Android version using Android Canvas API, not Skia API directly, js don’t use skia at all, desktop for now uses JVM bindings for Skia and even when those be removed and replaced with direct usage of MPP skia, it’s still a JVM project

I don’t want to say that ti will not be there, but it’s more complicated

[gildor]

The thing is whether graalvm or another aot can be used so that it is still JVM.

It’s not enough to run Compose Desktop which uses Swing for all window code and doesn’t provide any iOS bindings

[gildor]

I think attempt to use JVM on iOS is dead end from the beginning, especially for UI

[gildor]

and if/when Compose will arrive on iOS I think it will have own implementation based on Skia with custom rendering or in Swift UI/Uikit, but I wouldn’t expect it very soon, but maybe we will see some experiments in this direction

[darkmoon_uk]

Even though I am heavily invested in KMM for iOS and Android, and a big fan of Compose, I think that wanting Compose for iOS is the wrong path. The strength of KMM is the flexibility of being able to apply 'best of breed' at each layer of the software stack, and for iOS View that's SwiftUI.

Besides, given that SwiftUI and Compose are both declarative and intended to bind with reactive data; it's really quite compatible to make a single smart presentation layer and then very thin View layers for each platform. I have build and released a commercial App which achieves this, it was overall a good experience - if slightly marred by the Memory Model of iOS.

It takes a little more work, but if we were looking for an easier ride, surely we'd pick Flutter.

[Michael Paus]

@darkmoon_uk Your approach will only work for applications with a really thin UI layer. If you have to write a graphics intensive application you will fail because you would need a common graphics abstraction layer which we do not have for iOS as long as the Canvas part of Compose has not been ported to it. But as soon as you have that, what would stop you from doing the final step then too? For me KMM is not an option anyway because I have far too many dependencies on Java libraries in my project which I cannot easily replace by anything else. So doing what JavaFX does with GraalVM/native-image (which runs on desktop and Android/iOS) sounds interesting to me because it solves both problems.

[adjpd]

From going off what I read here, Google have got Compose working on iOS. But only the core of Compose, i.e. not all the material design etc stuff. I think it's used to make a tree of UIKit components. I'm not sure where they are going with this. But undoubtedly Jetbrains want their UI toolkit to work in as many places as possible. How exactly that will materialise on iOS is unknown currently. And if Compose, in some form, works on Android, iOS, the web and desktop it's heading straight into Flutter's territory.