Will swift export alleviate the need for SKIE when...

# swift-export

[ursus]

Will swift export alleviate the need for SKIE when exposing Flow<T>?

[Artem Olkov]

There are multiple recommended options for the end user, when they encounter the need for exposing kotlinx.coroutines.flow.Flow through the Objective-C Export, and one of them indeed is SKIE by Touchlab:
https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-upgrade-app.html#choose-a-library-to-consume-flows-from-ios

Neither of those tools will work out of the box with the first release of Swift Export.
The first release of Swift Export, marked for 2.2.20, will not have a direct support for kotlinx.coroutines. We do understand the importance of this library and we will start working on this support as soon as the first release is done. We do not have a public timeframe on "how long will it take to support kotlinx.coroutines in Swift Export".

For those projects that need the support for kotlinx.coroutines it is recommended to continue using Objective-C Export until Swift Export releases a support for this library.

[Guilherme Delgado]

https://github.com/rickclephas/KMP-NativeCoroutines is another great alternative, works perfectly 👌

[Guilherme Delgado]

(as shown in docs)

[Guilherme Delgado]

@ursus ^

[ursus]

thank you !

[ursus]

@Artem Olkov soo we'll get generics first (the issue with current kotlin native); --but then we have to wait for coroutine support, right?

[Artem Olkov]

> we'll get generics first
Depends on what are you meaning by that. Long story short - with the first release all the generics from kotlin are type-erased onto upper bound.

> the issue with current kotlin native
As far as I know, Objective-C export does provide support for generics out of the box. The main limitation - the inability of the Objective-C language to express a generic on the protocols - can be easily overcomed by an introduction of (Abstract) Class. As it is done at one of our examples - https://github.com/Kotlin/kmp-production-sample/blob/68d69616283a016ef50c5085dfebffb6a1dccf58/README.md?plain=1#L81

It is also a recommended approach as was demonstrated on the KotlinConf 2024 - http://kotl.in/kmp-swift-gold (chapter 6: Typed Interface, timestampt 18:37)

[ursus]

I'm mostly asking whether your plan is that sharing Flow<T> will be available without additional tools..eventually -- or will such 3rd party processors needed always by design

[Artem Olkov]

will such 3rd party processors needed always by design

For swift export we are aiming to reduce the need for third party solutions. That said, sometimes the design of languages are not compatible and we cannot provide a general solution for a particular problem. Third party helpers can improve on such places, as they have more corners to cut, in order to provide a solution.

We do not have a final design for coroutines support yet and therefor I cannot publicly promise the support you desire. The best I can say - we are aiming at eventually providing a solution that will work good enough out of the box.