am curious about people's opinion about this <http...

# multiplatform

[John O'Reilly]

am curious about people's opinion about this https://twitter.com/joreilly/status/1685385738223767554?s=20

[jw]

Neither, really. The options are extremely limited as choices.

Also Twitter is terrible! Don't give them your engagement

[jw]

KMP is a technology. It does not dictate the type of code you share.

I didn't realize people weren't using KMM anymore I'm so glad to see that die

[John O'Reilly]

It was seemingly announced by @hhariri at his Droidcon Berlin talk...but not sure if anything official communicated about it yet.

[John O'Reilly]

KMP is a technology. It does not dictate the type of code you share.

So, I guess related question then is whether there is (or needs to be) some way to refer specifically to sharing of non-UI code (as I at least originally understood KMP to imply).

[John O'Reilly]

We also btw have overloading of "Multiplatform" and "Crossplatform" just to confuse matters 😃

[jw]

I don't think there's really a thing as non-UI code

[jw]

There's just layers of abstraction and arbitrary lines where we say "share before this line" and "native after this line"

[jw]

Even the classic definition of sharing UI still bottoms out in platform specific code, we've simply moved the line a bit as compared to, say, emitting a shared view models and mapping that to "native" UI

[John O'Reilly]

I think there's still one specific scenario where distinction used might be meaningful.....and that's in terms of adoption within iOS teams still using Swift/SwiftUI for the "UI" code

[jw]

We can have a term for that, but it should have nothing to do with Kotlin. What do you call React Native apps that share JS? Or people like 1Password who share Rust? Choosing to share only non-UI code is almost never a technical limitation of the language you are writing the shared code in.

[jw]

I am very opposed to a Kotlin-specific term because I find it pigeon-holes the language in conversations. "Oh Kotlin multiplatform is only for sharing business logic." Well, it can be used to share business logic, or it can be used to share low-level utilities, or rendering layer, or some combination of those, or even something completely different. The language imposes no restrictions itself.

[jw]

I can find many quotes like that on Reddit, this Slack, our work slack, Tw*tter

[John O'Reilly]

makes sense....as ever naming things is hard!

[John O'Reilly]

there's also non-technical/"softer" aspects to all this where some kind of way to refer to these things is important (again back to the scenario of adoption with iOS teams)

[jw]

I usually just separate the topics. "Kotlin multiplatform is a way of sharing code on many platforms." Then I can talk about Java bytecode, JS, LLVM if the context is technical enough. Then, "The most common type of code that is shared is business logic since that has the highest business need to be shared." And then maybe append, "regardless of language" to hammer that it's a separate point

[hhariri]

We’re making a public written announcement soon. And yeah agree @jw. I was against it from the very start, but it is what it is. Glad it’s going away.

[hhariri]

@John O'Reilly Interesting you bring that up cause just this Friday we were discussing this, and the suggestion is to stop making this distinction of “share application logic”. It’s all just about sharing code. Whether or not you want to use Compose. And that’s the direction we’re moving forward with.

[Tadeas Kriz]

I have to agree with John here, that the perception from the iOS and possibly management side is important and they need to see it's not "just another React Native/Flutter" that sits on top of the platform, but a thing that instead integrates with the existing platform, offering boundless choices of what code to share. I kinda like "shared code" instead of "multiplatform" or "cross-platform" as I personally see the distinction between "multiplatform/cross-platform" being a one thing that runs everywhere, whereas "shared code" describes the logic and then builds to each platform separately.

[Tadeas Kriz]

And I'm not saying we should have some Kotlin-only terminology to describe this. But I do believe the messaging about this will be super important. Because all of us here know how KMP works, what it offers and what its limitations are. But newcomers don't and when Android folks get excited about the possibility of sharing code with iOS, they may do more harm than good if they don't have talking points ready (as I've seen talking to a bunch of folks at meetups/conferences).