SKIE looks great for consuming Kotlin from Swift -...

# touchlab-tools

[darkmoon_uk]

SKIE looks great for consuming Kotlin from Swift - awesome if you're going for the 'gold standard' of a SwiftUI View layer driven by shared Kotlin logic.

As I look to K Compose Multiplatform for newer projects though; the only interop problem that remains for me are consuming Swift ABI SDK's from Kotlin. Swift Import, in other words - not export. Does TouchLab have, or plan to make, anything that helps generate ObjC wrappers for Swift API's? These aren't usually complex to make, but it's getting tiresome now.

I've needed to do the ObjC Wrapper thing for some Swift API on _every KMP project I've built so far_; making me question Jetbrains' prioritisation of direct export over import.

[Filip Dolník]

Hi! We do have some plans to improve Swift import with SKIE. We already have some improvement for this in the form of the Swift code bundling feature, which could simplify the process of interacting with the Swift code because that bundled Swift code is part of the same Kotlin module and compiled together.
We don’t have documentation for this use case yet, though. As I said, we are aware of this and want to improve it.

I’ve needed to do the ObjC Wrapper thing for some Swift API on _every KMP project I’ve built so far_; making me question Jetbrains’ prioritisation of direct export over import

Yeah, we’ve been saying the same thing since they announced the plan for Swift export (which was after SKIE existed). In my experience using SKIE in real projects, I never had a real problem with the current Kotlin->Swift interop. But I constantly run into issues in the opposite direction, as you mentioned.

[kpgalligan]

You are correct that Compose has no serious need for improved interop calling into Kotlin from Swift. I think Swift export is needed for the long term, but there's little practical benefit now. By "now" I mean when it is ready for production, with comparable interop to what's available now, which would make "now" unknown. Not soon. But, if using Compose, it doesn't matter.
Import has complications that export does not have. The obvious example is structs. Swift export won't deal with structs. It can't. It is possible to translate data classes to structs, at least in the happy-path cases, but any POC into that has usually stopped because it was kind of pointless. Swift devs would probably prefer structs, but the API would actually be classes. Using classes might not be preferred, but they're not foreign to Swift developers, and you're not dumbing down the Kotlin API with classes. Sealed classes, on the other hand, are just "classes" to Swift, so without interventions, like SKIE, you're losing something important.
A tool to automatically wrap any valid Swift could be rather difficult to build, obviously around the features of Swift that are semantically different from what Kotlin offers. Again, obvious examples: structs (value types in general), enums with associated values. I'm sure it's a much longer list, but that's without thinking too hard about it. OTOH, generics would probably be much easier than what Swift export will need to figure out (Kotlin generics from Swift are going to interesting).
Just sort of thinking out loud, something that may be more near-term feasible and help with a lot of the manual work would be more of an IDE tool, or a manually run CLI/Gradle tool to do a "best efforts" Swift Swift/Objc wrapper and Kotlin interface generation, that would need dev checking and completion. So, say the Swift code was doing something complex with enums/values that ran well past the happy path. The wrapper and Kotlin-side generation would need completion, but you'd be 90%+ of the way there overall.
Assuming a tool that would handle all Swift would be a large effort, part of our prioritization, besides the fact that we aren't JB, is the eventuality of JB needing to build it. iOS Swift libraries that don't support ObjC are obviously going to be common, and more so as time goes on.
Anyway, again, just thinking out loud. To discuss.