Are there any plans to add the ability to have Swift files in the same source set as Kotlin files similar to Java in the future?

As it stands right now, Swift isn't supported at all by Kotlin Native. It compiles to Objective-C, not Swift. So we would need a K/N-Swift bridge before something like that could be considered, and I'm not sure what the timeline is for that.

Apple doesn't even do that. When one mixes ObjC and Swift in the same project, it creates separate modules.

@Russell Stewart Interesting, it's definitely not a deal-breaker, but I think it'd make it easier for ios devs to ease-into kmp

I would love for K/N to directly support Swift; I hope that's going to happen someday. It would really open up all kinds of interesting possibilities for KMM.

You can implement Kotlin interfaces in Swift and use them within Kotlin code via dependency injection if that helps?

That's an interesting idea. I hadn't thought of that.

I'm using that strategy to wrap a host of iOS (and Android) SDKs that aren't directly compatible with KMP so that they're callable within shared code. E.g. Wrapping Firebase Analytics so the underlying analytics calls in our app all route via shared code but end up back in the platform specific implementations. Am using Koin for DI to achieve a chunk of that.

Oh, nice! Definitely gonna take a look at that.

Works great for 3rd party libraries. Just make an interface that has thin shims to call to the native 3rd party lib and you're good to go.

I haven't used Koin yet, I use Kodein. But I suppose that would probably work as well.

Koin is decent but I'm not necessarily a huge fan of the lack of compile time safety. Have been meaning to look into this but not quite had the chance yet https://github.com/evant/kotlin-inject

Yeah, Kodein has the same flaw. It's the only thing I don't like about it.

Am a fan of that strategy but I'm not sure it does anything to help iOS devs really though because the main purpose of wrapping SDKs (even if it is done in Swift) is to make it so they're more easily accessible in the Kotlin shared code 😄 Minimal platform specific code and more shared code is the KMP mantra!

Yeah, I understand. I try to do as much of my KMP code as possible in Kotlin, for the same reasons.

As Sam mentioned make the interface and Swift implementation a

thin shims

. Basically map the 3rd party sdk functions to the interface functions and do the rest in kotlin land. That way most of the code remains common in kotlin side.

It is possible to call into Swift code that is marked with the objc annotation (but not all Swift code can be marked with objc). It's useful to wrap Swift in cases where a Swift library could be objc, but the devs did not mark it so, or cases where to objc-like Kotlin approach is too messy. It would be nice to be able to create a Swift file in my kotlin project, and have it automatically recognize any objc-marked methods/classes.

Or you can just drop Swift altogether. Kotlin is enough. Kotlin is great. Join Us.

FYI @Patrick Cavanagh Koin is getting compile time checking, currently in experimental state 🙂

What is the benefit of using DI frameworks with your iOS code? I have been of the mind that you should just use SwiftUI or whatever patterns the platform gives you for your DI. Personally, I don’t really get why DI is so important in the Android world — the language gives you constructors after all. Why would you want to make dependencies more indirect?

The main reason it's super important in Android is because you just can't do constructor injection into anything touching the UI because it can and will all be killed and recreated at the drop of a hat. Isn't like iOS where you can be sure that passing an object into a view controller/ swiftUI view and be sure that i'll still be there at a later date.

AHHHHH okay that makes a ton of sense.

You can not use dependency injection and just have singletons all over the shop but isn't a very nice testable approach. Have enjoyed using this library in pure Swift projects in the past https://github.com/hmlongco/Factory

Ahh, I can see how that is helpful.

@Patrick Cavanagh how can i provides the implementation of the class ?

Angga, perhaps a more detailed answer depends specifically on what DI library you are using, but in general is as simple as instantiating the implementation class in swift side and passing it to kotlin land through any kotlin binding function.

@Pablichjenkov im using koin

Check this link, that Bindings.kt file has some examples of interoperability. https://github.com/pablichjenkov/kmp-amadeus-api/blob/main/shared/src/iosMain/kotlin/com/pablichj/incubator/amadeus/demo/Bindings.kt#L60