<@U0BFDUP0E> As per <https://jakewharton.com/multi...

# compose

[Mehdi Haghgoo]

@jw As per https://jakewharton.com/multiplatform-compose-and-gradle-module-metadata-abuse, have you written all your UI from scratch without any Compose UI compoent?

[jw]

We use existing Android Views and UIKit powered by Compose

[andrew]

So is there a compose applier for UIKit internally within your org?

[jw]

the applier and node tree is platform independent, although i did prototype a uikit-specific applier but that was like 2 years ago at this point

[andrew]

Interesting... and I'm guessing this isn't public either, wouldn't expect it given how hacky it seems to use. Very interesting though

[jw]

what is hacky? the original prototype for compose target the Android View tree. it was only like a year later that it was decided to build a new UI toolkit at the same time.

[andrew]

Using Compose for iOS in some way has floated across my mind at multiple points, as we are rewriting our app at work. Right now it is in Compose and SwiftUI, but I'd love to share code

[andrew]

I just mean the wrangling the dependency system

[andrew]

With juggling all the dup classes in the classpath due to the differing compose runtime dependencies, having to replace with placeholders in the internal dependency graph, etc. I'm sure the actual applier is pretty stable, and not hacky at all 😉

[andrew]

And the nifty things I've seen come out of the compose runtime, like generating powerpoints out of compose nodes using the applier system and runtime, etc; it goes to show how versatile it really is.