https://kotlinlang.org logo
Join Slack
Powered by
Are there any plans to add the ability to have Swi...
# ios
a
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?
r
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.
👍 1
s
Apple doesn't even do that. When one mixes ObjC and Swift in the same project, it creates separate modules.
😐 1
👀 1
a
@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
@Sam we're definitely spoiled by Kotlin 😅
r
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.
K 2
p
You can implement Kotlin interfaces in Swift and use them within Kotlin code via dependency injection if that helps?
👍 1
r
That's an interesting idea. I hadn't thought of that.
p
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.
👍 2
But you could do it for anything really, not just wrapping SDKs
r
Oh, nice! Definitely gonna take a look at that.
s
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.
r
I haven't used Koin yet, I use Kodein. But I suppose that would probably work as well.
p
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
👍 1
r
Yeah, Kodein has the same flaw. It's the only thing I don't like about it.
p
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!
I've elected to write a few slightly nasty iOS implementations of interfaces in ObjC-ey Kotlin rather than bother to do it in Swift with the approach described above just to avoid needing to open Xcode. Spoiled with Android Studio.
And that's coming from someone who would describe themselves as mainly an iOS developer!
r
Yeah, I understand. I try to do as much of my KMP code as possible in Kotlin, for the same reasons.
p
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.
l
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.
In terms of Kotlin-Swift compatibility, Swift itself only recently stabilized most of the ABI. They're working with C++ compilers to get experimental Swift-C++ compatibility, so it may become possible for the Kotlin team to implement compatibility in the near future, but it's still a massive task that could take time, and I don't know where this lies in terms of priority.
r
Or you can just drop Swift altogether. Kotlin is enough. Kotlin is great. Join Us.
j
FYI @Patrick Cavanagh Koin is getting compile time checking, currently in experimental state 🙂
K 1
👍 1
j
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?
p
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.
j
AHHHHH okay that makes a ton of sense.
p
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
FWIW, the DI stuff I was describing above in my case is only really used within Kotlin code - it's just that we've got swift implementations of some things which are being passed into the shared code on app initialisation to be made available through the DI framework.
j
Ahh, I can see how that is helpful.
a
@Patrick Cavanagh how can i provides the implementation of the class ?
p
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.
a
@Pablichjenkov im using koin
any sample to look through ?
p
3 Views
Open in Slack
PreviousNext
Powered by