I think we can't just yet, but given Swift 5 now h...

# kotlin-native

[louiscad]

I think we can't just yet, but given Swift 5 now has a stable ABI (which was probably required for SwiftUI), and the fact that SwiftUI seems to be already designed further than Compose (I didn't hear them mention preview), it's very likely Kotlin/Native interop with Swift will see its priority be increased.

[basher]

You'll need Swift 5.1 for stable module ABI (out soon)

[kpgalligan]

Not sure how much this will raise priority. Maybe some, but at this point my guess is most devs aren’t going to construct their UI’s with Kotlin interop. I haven’t looked at this at all (got pulled into a meeting while announcement happened), but I would also guess there’s a lot of tooling magic to round-trip the previews. I think simply having structs will move the needle dramatically more than supporting SwiftUI from Kotlin.

[kpgalligan]

Those conversations were all pre SwiftUI. I think the concern is more general. It will be difficult to sell what’s seen as “more Objective-C” to teams working towards a more Swift-like way of coding. It’s not a yes or no. There will be adoption, but it’ll be lees for reasons mentioned.

[kpgalligan]

As for shared UI, I conceptually like some kind of merge between Compose and SwiftUI, and I really want it, but I would not agree with “a lot closer”. Ironically, Android and iOS getting a new UI means anybody who was planning some crazy new UI generator for multiplatform will probably be waiting to see how things play out (IE, we might actually be less close). Having said that, I’ve played with neither. My guess is using compose to create shared views that get integrated into the view hierarchy on iOS is more likely than some king of “bridge” between Compose and SwiftUI, but again, that’s a highly uninformed opinion. If Compose and SwiftUI really improve the dev experience, it also brings down the urgency of creating shared UI, to some degree. It’ll be an interesting year, at least.

[russhwolf]

Was about to snark and then you edited. Compost is a nice little Freudian slip there 🙃

[kpgalligan]

Dude, with you

[kpgalligan]

Ready made nickname. Like Klutter

[kpgalligan]

But worse

[sksk]

agree about struct, waiting for Valhalla is the worst idea ever, just do like you did with concurrency and move forward

[oleksandr.stepanov]

@kpgalligan, what is the main issue to convert structs in Swift to data classes in Kotlin and vice versa? I was thinking that they are conceptually the same. I suppose it may be in the features around them like extensions, support for protocols (interfaces), generics etc. But even with some limitations such interop will be already something, which is better then nothing.

[kpgalligan]

They are conceptually similar, but definitely not the “same”. Once you get into “Kotlin” they’re reference objects, first of all, so when calling from Swift to Kotlin you need to convert them somehow. You cannot have inheritance in structs. I haven’t even really thought about protocols and generics. The “plan” for now is to define an annotation that you can apply to data classes that will generate Swift code with equivalent structs, and extension methods to copy back/forth. I’m working on a POC to flush out a fuller list of compromises to see if there’s value in building something now.

[sksk]

why hacks ? the most obvious and simpler solution is to implement structs directly in kotlin native

[kpgalligan]

How would you approach that?

[basher]

Swift `struct`s require a lot of Swift compiler help to work (codegen, copy-on-write, etc.)

[sksk]

i'm not compiler guy, isn't that already supported out of the box with llvm bitcode ?

[kpgalligan]

I would contest that implementing structs in KN then with Objc interop somehow talking to Swift would be “obvious and simpler”. There’s a lot going on.

[oleksandr.stepanov]

I see … I was under impression that data classes in Kotlin are value-type as well, but they are reference-type in fact.

[sksk]

lot of stuff in kotlin could benefit from struct, if only Oracle wasn't so fking slow at releasing Valhalla...... waiting for it is a real pain

[sksk]

i'm pretty sure swift will get windows/android support before valhalla see the light of the day

[kpgalligan]

“swift will get windows/android support” What do you mean?

[sksk]

there is work being done for supporting windows / android target

[sksk]

once that happens, it'll be huge, at least for me, one native codebase for everything

[kpgalligan]

People have been shipping Swift/Android

[kpgalligan]

You’ll have to talk to Swift through JNI, and the runtime is huge

[kpgalligan]

Kotlin’s interop story is far better

[sksk]

yeah but there is lot of annoying bits (compilation and lack of struct)

[basher]

Agree. Any story that involves JNI is somewhat doomed, IMO. unless, you have an extremely patient dev team

[kpgalligan]

Swift compiles?

[russhwolf]

There's "annoying bits" and compromises any time you're trying to make two different languages talk to each other. It's all about finding the pragmatic middle ground.

[basher]

There are efforts for Swift for Android and Windows. The main issue though is that, at least from my understanding, those are mostly community efforts. Until Apple is willing to adopt them in a public way (i.e. in their marketing materials), it feels hard to invest in that direction. Kotlin however has mpp as part of their reference materials and a framework in place to support many platforms

[sksk]

Yeah but making kotlin rely on Java design choice, and waiting for them to implement new features that affect performance is a bit annoying and scary

[sksk]

i regained interest in kotlin when they announced kotlin native

[basher]

Closest thing to non-Apple Swift currently well-supported is Swift on the server. There's a work group with some companies committed, but I'm not even sure if any updates were given at WWDC this year. So again, feels hard to want to commit that side of Swift to a serious project (albeit Vapor looks super cool)

[kpgalligan]

Kotlin is not entirely relying on JVM. Concurrency, for example. I know what you’re saying, but thinking Swift for android will take off because Kotlin doesn’t currently support structs is a bit of a reach

[russhwolf]

If you really want a single-language native codebase you could take all the swift out of your iOS project and write the viewcontroller layer in Kotlin. It interacts less naturally with the native iOS tooling but you remove the swift/kotlin wrinkles if that's really a dealbreaker for you

[sksk]

i'm making a game, so i'm not interested in all the libraries/ui stuff, only GL/Vulkan/Metal, and yes struct is important when you need performance, knowing that for loop allocates garbage, and autobox everything hurts a lot

[basher]

I think the community would appreciate specific performance feedback. If you have certain loops that are slow, filing a ticket would allow K/N folks to comment on alternative approaches or make optimizations

[basher]

The tools won't magically improve otherwise, and people using the tools is great motivation:
- Recent example fix: https://github.com/Kotlin/kotlinx.coroutines/pull/1228
- See recent comment for the issue filed that led to the fix: https://github.com/Kotlin/kotlinx.coroutines/issues/1225

[sksk]

the solution for the performance issues i have is known already, struct and generic specialization so i don't get hidden and useless extra heap allocations

[sksk]

and let's not talk about math operations..

[basher]

It still might be worth filing specific issues with sample code, so that it can maybe be optimized

[sksk]

there is no point, they said already they are waiting for Valhalla to come to the JVM before commiting to anything

[sksk]

i can understand since Kotlin was built originally for the JVM, but for Kotlin Native, they could have done like they did with concurency

[basher]

Do you have an issue link or something like that?

[sksk]

https://kotlinlang.slack.com/archives/C3SGXARS6/p1553772881007400?thread_ts=1553738838.503800&cid=C3SGXARS6

[basher]

Value types in Kotlin would be great. I think coming up with a solution for bridging `data class`es to `struct`s in Swift is different. One is a K/N interop issue. That (your link) is a "`struct`s in JVM/Kotlin issue" as first class citizen. @kpgalligan's PR for generics is a good example. It's not perfect, but it improves the generics situation when using from Obj-C/Swift a lot. K/N could add a method for `data class`es called asStruct() (speculating) that gets you a struct for Swift, and then have ways to get that back into a data class easily for Kotlin (i.e. help out Swift users without promising anything from the Kotlin side).

[basher]

Anyway, my point is that I believe there are compromises that fit into Kotlin and K/N worldview

[sksk]

i don't think data class is meant to be a value type, the closest would be inline class, but it is limited to only 1 member