I recently established a good pattern for calling Swift library code within my Multiplatform app using interfaces and Koin. It's been helpful so far, especially with the fact that I can worry less about 3rd party libraries getting outdated with time when they're not maintained. However, it seems like the Kotlin Multiplatform team doesn't really recommend this, particularly with respect to scalability. Does this suggest that the first approach to consider when calling Swift packages like GoogleSignIn-iOS or firebase-ios-sdk in my Multiplatform projects would be to consider a KMP library? Or perhaps use the native cocoapods (objc) or some other KMP library (which probably uses cocoapods and cinterops underneath). My goal is to ensure long-term maintainability and scalability. Any insights or recommendations on the best approach to integrate Swift libraries in Kotlin Multiplatform projects would be greatly appreciated. Thank you.

Basically they are saying that your kotlin module is not self sufficient in the sense that it needs external code to work. In other words, if you are developing a library, you will have to distribute the KMP library plus a swift library/framework. Your client will have to import your kotlin library and also import the swift side of it. But aside from that distribution problem, I think this technique is ok. I really wish the docs would have provided what is the scalability point they talk about. I think is what I described above but could be something else.

Thanks for your response @Pablichjenkov . I'll make the assumption that this mostly applies to libraries right now since it does make sense that client projects calling our library code should not be required to import additional libraries. As for a standard KMP project (not a library), from my experience with other multiplatform technologies in the past, calling platform specific implementation via interfaces isn't necessarily discouraged and I personally haven't hit what would seem like a "_scalability threshold_" by utilising platform-specific implementations. I'll continue this way and keep an eye out for future opinions.

💯% with you