What is the state of Swift export You can check th...

# swift-export

[sergey.bogolepov]

What is the state of Swift export
You can check the list of supported declarations here.
When it is going to be released
When it is ready :)
What are we going to work next
We have 2 major focuses at the moment:
Multi-module export. This is the one of the major pain points in Objective-C export (YouTrack ticket) where all declarations are stored in a single header under a single namespace. Swift export will be able to produce multiple Swift modules. However, this topic is trickier than it looks.
Some Kotlin libraries like Ktor are split into multiple klibs. This is fine in Kotlin where notion of klibs and modules does not leak into source code and remain purely a compiler and build-tooling entity. However, it is not so in Swift where modules are a part of the language. So a naïve translation of klibs to Swift modules would result in something like:

import KtorClientCore
import KtorClientDarwin
import KtorClientSomeMore

Which is quite cumbersome compared to import KtorClient. So we need to provide a Gradle DSL for users to configure a beautiful Swift modules. Figuring out such DSL is tricky and we need a few deliver-gather feedback-update iterations to get this right.
Classes and interfaces. (YouTrack ticket). As stated in the ticket, it is important to support classes and interfaces early on, because they are the basis for other features.
One important feature of the Objective-C export is cross-language inheritance: one can inherit ObjC/Swift classes from Kotlin ones, or adopt Kotlin interfaces. This feature is much harder to implement in Swift export because unlike ObjC, Swift does not provide public stable API to read runtime class metadata. We have a few ideas on how to approach this problem, but we need some time to explore them properly. In a meantime, we plan to prohibit this feature, ship interfaces and open classes without cross-language inheritance, and lift this restriction later.
How to try
1. Kotlin Playground
2. Sample project
3. Raw artifacts

[Vincent Barthelemy]

Hi! Thanks a lot for sharing those early information on how to try that 🙂

I wanted to test on a KMP project I'm working on, but I keep running into NoClassDefFoundError . I tried to follow exactly what is explained in the "Raw artifacts" documentation you linked but without success.

I get java.lang.NoClassDefFoundError: org/jetbrains/kotlin/native/analysis/api/ReadKlibDeclarationAddressesKt when calling runSwiftExport. I thought it was an issue of compatibility between swiftExportVersion and kotlinVersion so I tried a couple of others, but without any luck for now.

Not sure if it's me that's doing something wrong, or if it's related to the "Versions of Swift export and Analysis API artifacts might not be the same" / "the not-yet-stable Analysis API".

Does anyone else have successfully to use the separate / raw artifacts? :)

[ursus]

May I ask.. so all of this will be transparent to us users? Just apply kmp gradle plugin of sufficient version and I'll get it?

[sergey.bogolepov]

@Vincent Barthelemy hey!
Regarding separate artifacts: they are not intended for end-user projects. Consider using KGP instead like we do in the sample project. But please note that Swift export is not yet ready for any non-trivial projects :)

[sergey.bogolepov]

Ofc, we will look in this particular problem anyway :)

[sergey.bogolepov]

@ursus, yep. UX would be more or less the same as in the existing Objective-C export.

[Vincent Barthelemy]

Thanks a lot for your answer 🙏!
I might have been a little bit to excited to try that out after reading "You can play with Swift export without KGP" my bad 🙇

Consider using KGP instead like we do in the sample project.

But please note that Swift export is not yet ready for any non-trivial projects 🙂

Duly noted 🫡
I will follow the progress on that topic closely 🙂
Good luck with all the work that needs to be done 💪