I'm pleased to share the latest developments in th...

# swift-export

[sergey.bogolepov]

I'm pleased to share the latest developments in the Swift export project as we wrap up 2024!

The Most Significant Changes in the Last Two Months
• Implemented basic support for enum and sealed classes, which means all types of classes are covered except tricky value ones :D
• Added support for simple method overrides. Not-so-basic covariant and fake overrides will come later after we implement support for interfaces.
• Rolled out initial support for the @Throws annotation by translating it to an untyped throws.
Current Focus Areas
• Interfaces. Even though we excluded cross-language inheritance from the initial scope, interfaces remain very challenging to implement.
• Functional types (aka closures/lambdas). Recently, we merged support for the () -> Unit type and are now expanding support for the rest of the possible signatures. We also need to ensure that throwing works properly, along with overrides. Oh man.
Glimpse into the future
For now, we are continuing to use a type system that is more or less the same as in Objective-C export (KotlinBase as the root of the class hierarchy). However, we see limitations of this approach and a potentially better option that promises to be much more flexible: KotlinBridgeable protocol. We will not switch to it before the first public release, but it is clearly something we want to explore as soon as possible.

Thank you for following our progress—see you in the new year! 👋

[Anonymike]

Just want to say thank you very much for this. With the multiplatform improvements this year we've been able to do much more. You are specifically working on the weakest point for us because we constantly run into limitations on implementing protocols and inheriting objective-c classes (not being able to implement interfaces, abstract classes cannot be used because we must inherit from NSObject, etc.). Please share gratitude with the team doing this work.

[Javier]

This is really nice!

Is this published in some dev version? 2.1.20 Beta1 does not include sealed support

[sergey.bogolepov]

Hey! Just checked: 2.1.20-Beta1 includes support for sealed classes. There might be bugs around non-trivial cases, though. Could you please share your sealed hierarchy?

[Alex Murphy]

Great work! I'm trying to mess around with the sealed class conversion using the export example project, but I'm seeing a type of Never on the swift side for my sealed class. Any suggestions?

Untitled

[Alex Murphy]

@sergey.bogolepov any thoughts on the sealed class export to swift question above? Thanks again!

[sergey.bogolepov]

Hey, try updating to 2.1.20-Beta2. Also, please remember that this is a wip, everything might blow up in random places, etc. :)

[Javier]

Sorry about not replying to this, I was not able to check it again but I think I get working sealed classes in a bootstrap version (I upgraded before you replied me).

I will check the last beta anyway.

Is there any public doc to check how Swift Export currently works with suspend and Flow APIs?

[sergey.bogolepov]

Is there any public doc to check how Swift Export currently works with suspend and Flow APIs?

There is no support for them as Swift export still WIP.

[Javier]

I would like to see more details/samples about how KotlinBridgeable protocol would work.

Sadly, I cannot use Swift Export a lot as I need support for coroutines. It was a total pain to implement this interface in Swift (I cannot implement it on Kotlin for iOS as it depends on some Swift codegen).

interface MessengerClient {

    val messages: Flow<List<Message>>

    suspend fun sendMessage(content: String): Either<MessageError, Message>

    suspend fun deleteAllMessages(): Either<MessageError.Unknown, Unit>
}

I would like to know how KotlinBridgeable can help to not wait for first party implementations from JetBrains or Google and I being able to create the bindings somehow.

I guess for suspend it would be necessary a first party implementation, but for Flow or any custom class, it should be possible with it to be created by anyone, right?

[sergey.bogolepov]

> I would like to see more details/samples about how KotlinBridgeable protocol would work.
Too early and it is not strictly relevant to your case. "Possibility for users to write custom type conversions" does not mean that anyone can alter translation of any type the way they want. Mostly, it might be an instrument for library authors to expose their types in some fancy way. Again, too early.
> I cannot implement it on Kotlin for iOS as it depends on some Swift codegen
Why? You can try to wrap these declarations into @objc and use them in Kotlin via cinterop.
> Sadly, I cannot use Swift Export a lot as I need support for coroutines.
Yeah, that's true. Also, Swift export won't support cross-language inheritance for some time :)
> I guess for suspend it would be necessary a first party implementation, but for Flow or any custom class, it should be possible with it to be created by anyone, right?
We will see. Flow is essentially a part of stdlib, so first-party support out of the box makes a lot of sense.