Massive congratulations to the team for getting this into alpha! What's the difference between and...

# compose-ios

[Anthony Martin]

Massive congratulations to the team for getting this into alpha!

What's the difference between android compose & jetpack compose?

Assume I have a project in android right now fully in android compose and not anything multi platform. Can I convert this code easily to multi platform or do I need to rewrite all of the UI code again?

[Stefan Oltmann]

Basically you change the dependencies to the compose-multiplatform ones.

id("org.jetbrains.compose")

[andrew]

Anything that's pure compose, and multi-platform supported in AndroidX should be a breeze, but anything that depends on Android framework specifically, you'll need to port to iOS

[andrew]

Multi platform compose I should say

[Alejandro Rios]

BTW: there's no android compose , just Jetpack Compose or Compose Multiplatform

[Casey Brooks]

“Jetpack Compose” is basically the name for Android-specific compose, but because of Compose’s famously-bad naming, you will sometimes see folks use it interchangeably with Compose Multiplatform, or Compose Runtime, or anything else Compose. You may also see some folks call “Jetpack Compose” just “Jetpack”, which is wrong because “Jetpack” is the umbrella term for all the modern Android tooling, libraries, and patterns, of which Compose is one part. And this is not to be confused with Jetpack for Wordpress, which is an entirely different, unrelated thing.

Naming is hard, yall.

[andrew]

I forgot about jetpack for WordPress until you mentioned it 🤣

[Casey Brooks]

But to the difference between “Jetpack Compose” (the Android-specific version, set up with buildFeatures { compose = true }) and “Compose Multiplatform”, there is functionally no difference. JB maintains a fork of the Androidx repo with their “Compose Multiplatform” changes in it from which JB releases their artifacts for all Compose targets. Those changes eventually get upstreamed to Google’s Androidx repo, but I believe Google only publishes Android-specific artifacts.

Compose, from the beginning, was created using only common Kotlin code, and anything Android-specific is going to be the same in both Google’s and Android’s artifacts (to the best of my knowledge. please correct me if this is wrong), or relegated to the Accompanist libraries.

But in the end, the larger goal of Compose is a collaboration between Google and JB. Google focuses more on the Compose Compiler, Runtime, and Material UI libraries, while JB focuses on bringing those over to non-Android targets.

[Pablichjenkov]

You certainly can but you need to have the system platform's API usage well abstracted. Also no jetpack navigation lol, but there are similar solutions to this one.

[Pablichjenkov]

In other words is not easy

[Casey Brooks]

Yes, there are lots of additional features available for Android apps when considering the larger ecosystem of libraries, but those ultimately fall under the “Jetpack” and “Androidx” umbrellas, and are usualy kept out of the Material or other core Compose libraries

[Michael Paus]

And don’t forget all the Java dependencies. Desktop and Android are more or less Java platforms but iOS is not. So you will have to replace everything that directly or indirectly has a Java dependency. Even many features of the so called Kotlin standard library are not available on iOS. These many holes that show up when you remove Java are one of the big pain points for me at the moment.

[Landry Norris]

There's usually equivalents for things you'll need. Between sqldelight, ktor, okio, etc. I've been able to do most anything needed.

[andrew]

You could also use compose for just UI, and keep all your business logic native too

[andrew]

Either or

[andrew]

I don't see the point in that, but if it becomes too problematic, that's always a solution too

[Michael Paus]

In my project I am using sqldelight, ktor and okio but even then it is just wishful thinking to believe that this alone would allow you to run all your code on iOS too. Just one of many possible examples: If your design is, e.g., built around a ZIP filesystem you are out of luck. Even okio only supports that on the JVM. But I do not want to start a lengthy discussion here which is fruitless anyway if you are sitting in the fan curve 😉. I like Kotlin and I like Compose. I am just not convinced that the current multiplatform approach is the right way to go.

[Stefan Oltmann]

I’m convinced it is. If something is missing in a library another one will sooner or later show up and solve it. I also see quite a way to go, but the direction this is heading looks good to me.

[Stefan Oltmann]

But as you said I clearly sit in the fan curve, so we don’t need to discuss. I just wanted to add my opinion. 🙂

[Michael Paus]

Time will tell how long it will take to have all wheels re-invented 😉.

[Stefan Oltmann]

At this conference I learned that my much-beloved and missed Retrofit is back as https://github.com/Foso/Ktorfit 😄