Curious to get a show of hands here; but in my 3 m...

# ios

[darkmoon_uk]

Curious to get a show of hands here; but in my 3 most recent Kotlin Multiplatform projects featuring iOS; the only Swift Interop challenge I face is Importing Swift-only API's to Kotlin, and not Exporting Kotlin to Swift, as was prioritised on the roadmap 🤔

While K Compose Multiplatform is certainly not the only way to use KMP, as a major part of the ecosystem it promotes minimising the amount of Swift in the whole project and maximising Kotlin - that would indicate import-first as priority.

❗ More critically, the new iOS API's are Swift only which means I've had to write a significant number of ObC/Swift wrappers to use the features I need in KMP. This is tolerable - but only just in some cases 🥴 - and does beg the question: Why did KMP team focus on Export over Import, where only Import has ever been an issue for me - is it a technically necessary first step? More achievable? Or is my 'import case' the unusual one (finding this hard to believe) alphabet white question

As a repeated Kotlin/iOS user, I'd like to understand if/when we can expect direct Swift *Import*; which seems far more valuable than Export to me.

To be specific: ProximityReader, FamilyControls and DeviceActivityMonitor have been the newer, Swift-only API's I've needed to wrap.

[Pablichjenkov]

💯 same feeling here.
BTW you can post here better #C073GUW6WN9

[darkmoon_uk]

Thanks @Pablichjenkov, reposted.

[darkmoon_uk]

I should ask - has anyone created an 'automatic wrapper generator' for iOS Swift API's that I might have missed?

[kpgalligan]

Jumping in to point out something that gets lost in the interop discussions:

I'd like to understand if/when we can expect direct Swift *Import*; which seems far more valuable than Export to me.

Export isn't "direct". I think there's an expectation building around export that it'll be more appealing to iOS devs who like Swift, but the interop issues aren't primarily caused by ObjC. ObjC just happens to be the common evolutionary ancestor of Kotlin and Swift, or if you wanted to stretch the metaphor, imagine Java and ObjC had an immediate common ancestor (that common ancestor was actually conceptual. Both were created in the period of time when people thought OOP was language design end-game. I'm exaggerating for comedic effect, but I'm not far off). Swift export has the same problems. I think Swift export is necessary for the long term. I'm just a bit concerned, judging from various conversations, that the nuance of what it'll actually be is lost.
That is, Swift export is a different form of interop to Kotlin, but it won't make Kotlin into Swift. Semantically speaking.
On import, just commented in the other channel thread (touchlab, not swift export). Import is increasingly important. Advocating for it is important, as JB has to deal with a lot of signals to sort out priority. Getting a clear view of the relative importance of features can be very difficult. I'd suggest having a link, or list of links, to youtrack issues and point people at them to vote or comment. Slack has a short memory, or at least our memory of what's in slack is short, and not easily quantifiable.

[Rene Gens]

How do you export the API’s is there somewhere documentation for this?

[kpgalligan]

How do you export the API’s is there somewhere documentation for this?

I'm not sure we're talking about the same thing, if this was in reply to my post. Which API?

[Rene Gens]

Any iOS API, I am interested in the process.

[kpgalligan]

I think we have terminology confusion. Right now, if you make an Xcode Framework from Kotlin, you get an ObjC interface. In this context, that's the "exported interface". You can also use cinterop to have an "import interface". Kotlin can call ObjC. "Swift export" will be another option for Xcode Frameworks, instead of ObjC. However, it is explicitly called "Swift export" because there won't be an equivalent to cinterop for Swift. You can't "import" Swift, unless that Swift supports being called from ObjC (which Kotlin currently supports).
So "Swift export" isn't exporting anything so much as saying you can create a Swift interface that can call Kotlin from Swift, but you cannot create a Kotlin interface that can call Swift from Kotlin.

[Rene Gens]

Now I got, thanks for the clarification.

[sergey.bogolepov]

Hey! I will be brief :)

Why did KMP team focus on Export over Import

Swift export is easier to implement than import, and use-cases are more clear.
Generic Swift import akin to existing Objective-C import is hard to achieve for several reasons:
• Swift is already much more rich language than Kotlin. For example, consider recent changes around ownership semantics.
• Unlike Objecitve-C, Swift will continue to evolve, introducing new features which are hard to map to Kotlin.
• If we decide to focus on some subset of the language, what cases should we cover?

I'd like to understand if/when we can expect direct Swift *Import*;

We will decide if we will work on Swift import not earlier Swift export is "done". We don't want to stretch team resources thin.

[darkmoon_uk]

Makes sense @sergey.bogolepov; thanks for explaining & for KMP tooling 🙂

[Pablichjenkov]

Somehow SKIP is doing something similar. Apparently you can consume Swift directly from Kotlin. Although they are closed source and paid too

[kpgalligan]

SKIP is a transpiler. I haven't spent much time looking at the Kotlin output, but I imagine it's pretty wild, and yeah, there's going to be a lot of update work going forward. I'm frankly amazed they're still working on it. I spent a few years doing a whole bunch of work on top of J2ObjC. Building tools and libraries. So, some relevant experience. Summary: I respect the attempt, and wish them well.